Android Design Patterns

Hi all,

I've recently made this blog available on Google Currents! Install the application and subscribe by clicking the link below:

Follow this blog on Google Currents!

If you have never used Google Currents, I strongly recommend that you try it out. It's a really great way to keep up with the latest news, blogs, and your favorite Google+ streams, and it works seamlessly offline (which I've found is great for long plane rides). If you're a long time Flipboard user, I recommend you give it a try as well... in my opinion, Currents is easier to navigate and feels much more like a native Android application. That said, I do tend to be a bit biased towards the native Google apps. :P

As always, don't hesitate to leave a comment if you find a bug or have any suggestions on how I can improve the edition! I'm going to try really hard to keep it up-to-date for those of you who follow this blog and can't get enough of Google Currents!

Cheers,
Alex

This post introduces the Loader<D> class as well as custom Loader implementations. This is the third of a series of posts I will be writing on Loaders and the LoaderManager:

• Part 1: Life Before Loaders
• Part 2: Understanding the LoaderManager
• Part 3: Implementing Loaders
• Part 4: Tutorial: AppListLoader

First things first, if you haven’t read my previous two posts, I suggest you do so before continuing further. Here is a very brief summary of what this blog has covered so far. “Life Before Loaders” (part 1) described the flaws of the pre-Honeycomb 3.0 API and its tendency to perform lengthy queries on the main UI thread. These UI-unfriendly APIs resulted in unresponsive applications and were the primary motivation for introducing the Loader and the LoaderManager in Android 3.0. “Understanding the LoaderManager” (part 2) introduced the LoaderManager class and its role in delivering asynchronously loaded data to the client. The LoaderManager manages its Loaders across the Activity/Fragment lifecycle and can retain loaded data across trivial configuration changes.

Loader Basics

Loaders are responsible for performing queries on a separate thread, monitoring the data source for changes, and delivering new results to a registered listener (usually the LoaderManager) when changes are detected. These characteristics make Loaders a powerful addition to the Android SDK for several reasons:

1. They encapsulate the actual loading of data. The Activity/Fragment no longer needs to know how to load data. Instead, the Activity/Fragment delegates the task to the Loader, which carries out the request behind the scenes and has its results delivered back to the Activity/Fragment.

2. They abstract out the idea of threads from the client. The Activity/Fragment does not need to worry about offloading queries to a separate thread, as the Loader will do this automatically. This reduces code complexity and eliminates potential thread-related bugs.

3. They are entirely event-driven. Loaders monitor the underlying data source and automatically perform new loads for up-to-date results when changes are detected. This makes working with Loaders an absolute pleasure, as the client can simply trust that the Loader will auto-update its data on its own. All the Activity/Fragment has to do is initialize the Loader and respond to any results that might be delivered. Everything in between is done by the Loader.

Loaders are a somewhat advanced topic and may take some time getting used to. We begin by analyzing its four defining characteristics in the next section.

Here's a question that is worth thinking about:

Should I implement an "Exit application?" dialog in my app?

In my experience, the answer is almost always NO. Consider the official Flickr app, as an example. At the main screen, the user clicks the back button and is immediately prompted with a dialog, questioning whether or not the user wishes to exit the application:

(a) Back button pressed	(b) "Exit Flickr?"

So what went wrong? Well, pretty much everything, at least in my opinion. Here are the three major flaws I see in Flickr's decision to include the dialog:

1. It slows down the user experience. An additional click is required to leave the application. Sure, it doesn't seem like much... but zero clicks is always better than one. Including the dialog will piss off the occasional meticulous power user and will make it much more likely that people like me will write-up angry rants about it online. To make matters worse, Flickr's dialog incorrectly positions the "OK" and "Cancel" buttons, which as of Android 4.0, should be positioned on the right and left respectively. This is also not a huge deal, but it forces users to think more than they should need to, and the simple action of exiting the application is no longer seamless as a result.