Android Loader Detailed Explanation

1. Basic method of Android loader

Loaders were introduced in Android 3.0. They make it easy to asynchronously load data in an activity or fragment. Loaders have the following features:

• They are available for every Activity and Fragment.
• They provide the ability to load data asynchronously.
• They monitor data sources for activity and deliver new results when the contents change.
• When recreated due to a configuration change, they automatically reconnect to the previous loader's cursor, so there is no need to requery the data.

Loader API Overview

When using loaders, many classes and interfaces are involved. We summarize them in the following table:

Each activity or fragment has only one LoaderManager. But a LoaderManager can have multiple loaders. LoaderManager.LoaderCallbacks is a callback interface for clients to interact with LoaderManager. For example, you use the callback method onCreateLoader() to create a new loader.

Loader

An abstract class that performs asynchronous data loading. It is the base class for loaders. You can use the typical CursorLoader, but you can also implement your own subclasses. Once loaders are activated, they will monitor their data sources and send new results when the data changes. AsyncTaskLoader provides an abstract class that provides an AsyncTask to perform asynchronous loading work. A subclass of CursorLoaderAsyncTaskLoader that queries a ContentResolver and then returns a Cursor. This class implements the loader protocol in a standard way for querying a cursor. Its cursor query is performed in a background thread through AsyncTaskLoader so that it does not block the interface. Using this loader is the best way to load data asynchronously from a ContentProvider. In contrast, performing a managed query through the fragment or activity API will not work.

2. Start a loader

LoaderManager manages one or more loaders in an Activity or Fragment. But each activity or fragment has only one LoaderManager.

You usually initialize a loader in the onCreate() method of your activity or in the onActivityCreated() method of your fragment. You can create one as follows:

 // Prepare the loader. You can reconnect to an existing one or start a new one.
 getLoaderManager().initLoader(0, null , this);

The initLoader() method has the following parameters:

• A unique ID to identify the loader. In this example, the ID is 0.
• Optional parameter used when initializing the loader (null in this case).
• An implementation of LoaderManager.LoaderCallbacks. Called by the LoaderManager to report loader events. In this case, the class implements this interface, so it is passed itself: this.initLoader() ensures that a loader is initialized and activated. It has two possible results:
• If a loader pointed to by ID already exists, then that loader will be reused.
• If the loader does not exist, initLoader() triggers the onCreateLoader() method of LoaderManager.LoaderCallbacks. This is where you instantiate and return a new loader.

In both cases, the implementation of the passed LoaderManager.LoaderCallbacks is bound to the loader and will be called when the loader state changes. If the caller is in the starting state when calling this method, and the requested loader already exists and has generated data, the system will call onLoadFinished() immediately (that is, while initLoader() is still executing). So you must be prepared for this situation to happen.

Note that initLoader() returns the created loader, but you do not need to keep a reference to it. The LoaderManager automatically manages the life of the loader. The LoaderManager starts and stops loading operations when necessary, and maintains the state of the loader and its associated content. This means that you rarely interact with the loader directly. You usually use the methods of LoaderManager.LoaderCallbacks to intervene in the data loading process when certain events occur.

3. Restart the loader

When you use initLoader(), if a loader with the specified ID already exists, it uses that loader. If not, it creates a new one. But sometimes you want to discard the old one and start with a new one.

To discard old data, you should use restartLoader(). For example, the following implementation of SearchView.OnQueryTextListener restarts the loader when the user's query changes. The loader then needs to be restarted so that a new query can be made using the new search filter.

 public boolean onQueryTextChanged(String newText) {
 // Called when the search string in the action bar changes.
 // Update the search filter, then restart the load to use this new filter for new queries.
    mCurFilter = !TextUtils.isEmpty(newText) ? newText : null ;
    getLoaderManager().restartLoader(0, null , this);
 return   true ;
 }
 LoaderManager.LoaderCallbacks is a callback interface that allows clients to interact with LoaderManager.
 Loaders, usually CursorLoader, we want to keep data after it stops. This allows applications to keep data between onStop() and onStart() of an activity or fragment, so when the user returns to an application, they don't have to wait for data to load. You use the methods of LoaderManager.LoaderCallbacks to create new loaders when needed and tell the application when to stop using the loader's data.
 LoaderManager.LoaderCallbacks contains the following methods:
 onCreateLoader() —Initializes and returns a new loader based on the passed ID.
 onLoadFinished() —Called when a loader has completed its loading process.
 onLoaderReset() —Called when a loader is reset and its data is invalid. 
 
 When you try to operate a loader (for example, through initLoader()), it checks whether a loader with the specified ID already exists. If it does not exist, the LoaderManager.LoaderCallbacks method onCreateLoader() is triggered. This is where you create a new loader. Usually this loader is a CursorLoader, but you can also implement your own loader.

 String mCurFilter;
 ...
 public Loader< Cursor > onCreateLoader( int id, Bundle args) {
 // This is called when a new loader needs to be created.
 // We simply have a loader, so we don't need to worry about the ID.
 // First , pick the base URI to use depending on whether we are
 // currently filtering.
 Uri baseUri;
 if (mCurFilter != null ) {
 baseUri = Uri.withAppendedPath(Contacts.CONTENT_FILTER_URI,
 Uri.encode(mCurFilter));
 } else {
 baseUri = Contacts.CONTENT_URI;
 }
 // Now create   and   return a CursorLoader that will take care of  
 // creating a Cursor   for the data being displayed.
 String select = "((" + Contacts.DISPLAY_NAME + " NOTNULL) AND ("  
 + Contacts.HAS_PHONE_NUMBER + "=1) AND ("  
 + Contacts.DISPLAY_NAME + " != '' ))" ;
 return new CursorLoader(getActivity(), baseUri,
 CONTACTS_SUMMARY_PROJECTION, select , null ,
 Contacts.DISPLAY_NAME + " COLLATE LOCALIZED ASC" );
 }