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 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).

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:

Content Providers and Content Resolvers are a common source of confusion for beginning Android developers. Further, online tutorials and sample code are not sufficient in describing how the two classes work together to provide access to the Android data model. This post hopes to fill in this gap by explaining their place in the android.content package. It concludes with a walk through the life of a simple query to the Content Resolver.

The following question has plagued StackOverflow ever since Ice Cream Sandwich’s initial release:

My application works fine on devices running Android 2.x, but force closes on devices running Honeycomb (3.x) and Ice Cream Sandwich (4.x). Why does this occur?

This is a great question; after all, newer versions of Android are released with the expectation that old apps will remain compatible with new devices. In my experience, there are a couple reasons why this might occur. Most of the time, however, the reason is simple: you are performing a potentially expensive operation on the UI thread.

This post introduces the concept of a utility class and gives a simple example of how you can use one to tidy up your code. As Android projects grow in size, it becomes increasingly important that your code remains organized and well-structured. Providing a utility class for commonly called methods can help tremendously in reducing the complexity of your project, allowing you to structure your code in a readable and easily understandable way.