The following is the first few sections of a chapter from The Busy Coder's Guide to Android Development, plus headings for the remaining major sections, to give you an idea about the content of the chapter.

The Loader Framework

One perpetual problem in Android development is getting work to run outside the main application thread. Every millisecond we spend on the main application thread is a millisecond that our UI is frozen and unresponsive. Disk I/O, in particular, is a common source of such slowdowns, particularly since this is one place where the emulator typically out-performs actual devices. While disk operations rarely get to the level of causing an “application not responding” (ANR) dialog to appear, they can make a UI “janky”.

Android 3.0 introduced a new framework to help deal with loading bulk data off of disk, called “loaders”. The hope is that developers can use loaders to move database queries and similar operations into the background and off the main application thread. That being said, loaders themselves have issues, not the least of which is the fact that it is new to Android 3.0 and therefore presents some surmountable challenges for use in older Android devices.

This chapter will outline the programming pattern loaders are designed to solve, how to use loaders (both built-in and third-party ones) in your activities, and how to create your own loaders for scenarios not already covered.


Understanding this chapter requires that you have read the chapters on:

Cursors: Issues with Management

Android had the concept of “managed cursors” in Android 1.x/2.x. A managed Cursor was one that an Activity… well… manages. More specifically:

  1. When the activity was stopped, the managed Cursor was deactivated, freeing up all of the memory associated with the result set, and thereby reducing the activity’s heap footprint while it was not in the foreground
  2. When the activity was restarted, the managed Cursor was requeried, to bring back the deactivated data, along the way incorporating any changes in that data that may have occurred while the activity was off-screen
  3. When the activity was destroyed, the managed Cursor was closed.

This is a delightful set of functionality. Cursor objects obtained from a ContentProvider via managedQuery() were automatically managed; a Cursor from SQLiteDatabase could be managed by startManagingCursor().

The problem is that the requery() operation that was performed when the activity is restarted is executed on the main application thread. As has been noted elsewhere in the book, you really do not want to do disk I/O on the main application thread, as it freezes the UI and causes jank. This is particularly true for database I/O, where you may not know in advance exactly how much data you will get back or how long the query will take.

Introducing the Loader Framework

The preview of this section was whisked away by a shark-infested tornado.

Choosing an Implementation

The preview of this section is sleeping in.

Using CursorLoader

The preview of this section was lost due to a rupture in the space-time continuum.

What Else Is Missing?

The preview of this section is being chased by zombies.

What Happens When…?

The preview of this section is en route to Mars.

Writing a Custom Loader

The preview of this section was fed to a gremlin, after midnight.