Material – Part 1

At the time of writing, the full Lollipop SDK has just been released including new versions of the support libraries which provide some backwards compatibility for implementing material design in to older apps. In this series we’ll take a look at how we can actually apply this to an app.

Many of the techniques that we’ll cover in this series are pretty generic – they apply to both Lollipop and older devices using the support library. That said, some do require Lollipop APIs but we’ll try to clearly identify these as we cover them.

The first thing that we need is an app to apply material design to. For this we’ll create simple RSS reader which will display the RSS feed from Styling Android. So before we dive in to thew material design stuff we’ll take a look at the basic app to understand certain things about it.

I will apologise at this point that the first article in a series on material design does not actually get to material design! It is definitely coming in part 2, but it is important to understand the app that we’re applying it to so that what we do later actually makes sense. I’m not going to cover every line of code in the app, but more give an overview of how it works, and the reason behind certain software design decisions.

The basic app consists of two Activities: FeedListActivity displays a list of articles within a ListView, and clicking on one of these launches FeedDetailActivity which shows the article details with the full article text being displayed within a WebView due to the actual content containing some basic HTML markup. This is all fairly standard stuff and I have deliberately avoided aFragment-based UI and a tablet-friendly implementation to keep the code simple and understandable.

The first thing worthy of comment is that I have used a headless, retained Fragment to perform the data loading away from my Activity. Lars Vogel has written about these so I won’t cover them in any great depth. The reason for using them is simply to move the data loading which involves a network transaction and may be relatively long-lasting away from my Activity and in to a separate object – in this case a headless Fragment (in other words a Fragment which does not have any UI associated with it). The motivation for this is for handling configuration changes, such as rotation of the device. If we start loading the data in a background task directly from the Activity, and the Activity gets destroyed and re-created due to an orientation change, then the background process isn’t going to be aware of the change. So the trick that we use is to create a Fragment which gets retained by the FragmentManager and on rotation, the Activity that created the Fragment gets destroyed and a new one is created. The new Activity instance gets the existing Fragment instance from the FragmentManager, and so our Fragment lifecycle straddles the two Activity instances. When the background task returns, the same instance of the Fragment will still exist even though we may have a new Activity, and everyone is happy.

So the loading of the data is performed within DataFragment. I decided to use Volley to manage the HTTP requests because, by initialising it with a cache, Volley will take responsibility for managing and maintaining a local cache of data honouring the content expiry headers being specified by the server. Volley really does an awful lot for very little set up.

The next part of the process is to parse the RSS feed data being retrieved by Volley. I have elected to use a ver simple and basic XmlPullParser-based approach as this is pretty lightweight and performs fairly well. It is by no means a full RSS parser – I merely extract the data that I’m interested in. The parser will return a Feed object (which represents the entire feed) which contains a List of Item objects (which represent the individual articles). Both Feed and Item domain objects are defined within the project, and contain only the fields that we’re interested in.

All that’s left is an Adapter to bind these domain objects to their UI components within the ListView in FeedListActivity.

For the sake of easy to understand code this app is far from production quality – it does not behave well if there is no network connectivity (although the Volley caching will certainly help, here), but it gives us a starting point to apply some material design which will begin looking at in the next article.

The source code for this article is available here.

© 2014, Mark Allison. All rights reserved.

Copyright © 2014 Styling Android. All Rights Reserved.
Information about how to reuse or republish this work may be available at http://blog.stylingandroid.com/license-information.