Android Design Patterns

This post introduces the LoaderManager class. This is the second 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

Note: Understanding the LoaderManager requires some general knowledge about how Loaders are work. Their implementation will be covered extensively in my next post. For now, you should think of Loaders as simple, self-contained objects that (1) load data on a separate thread, and (2) monitor the underlying data source for updates, re-querying when changes are detected. This is more than enough to get you through the contents of this post. All Loaders are assumed to be 100% correctly implemented in this post.

What is the LoaderManager?

Simply stated, the LoaderManager is responsible for managing one or more Loaders associated with an Activity or Fragment. Each Activity and each Fragment has exactly one LoaderManager instance that is in charge of starting, stopping, retaining, restarting, and destroying its Loaders. These events are sometimes initiated directly by the client, by calling initLoader(), restartLoader(), or destroyLoader(). Just as often, however, these events are triggered by major Activity/Fragment lifecycle events. For example, when an Activity is destroyed, the Activity instructs its LoaderManager to destroy and close its Loaders (as well as any resources associated with them, such as a Cursor).

The LoaderManager does not know how data is loaded, nor does it need to. Rather, the LoaderManager simply instructs its Loaders when to start/stop/reset their load, retaining their state across configuration changes and providing a simple interface for delivering results back to the client. In this way, the LoaderManager is a much more intelligent and generic implementation of the now-deprecated startManagingCursor method. While both manage data across the twists and turns of the Activity lifecycle, the LoaderManager is far superior for several reasons:

This post gives a brief introduction to Loaders and the LoaderManager. The first section describes how data was loaded prior to the release of Android 3.0, pointing out out some of the flaws of the pre-HoneyComb APIs. The second section defines the purpose of each class and summarizes their powerful ability in asynchronously loading data.

This is the first 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

If you know nothing about Loaders and the LoaderManager, I strongly recommend you read the documentation before continuing forward.

The Not-So-Distant Past

Before Android 3.0, many Android applications lacked in responsiveness. UI interactions glitched, transitions between activities lagged, and ANR (Application Not Responding) dialogs rendered apps totally useless. This lack of responsiveness stemmed mostly from the fact that developers were performing queries on the UI thread--a very poor choice for lengthy operations like loading data.

While the documentation has always stressed the importance of instant feedback, the pre-HoneyComb APIs simply did not encourage this behavior. Before Loaders, cursors were primarily managed and queried for with two (now deprecated) Activity methods:

• public void startManagingCursor(Cursor)

  Tells the activity to take care of managing the cursor's lifecycle based on the activity's lifecycle. The cursor will automatically be deactivated (deactivate()) when the activity is stopped, and will automatically be closed (close()) when the activity is destroyed. When the activity is stopped and then later restarted, the Cursor is re-queried (requery()) for the most up-to-date data.