In this Activity, you can :
Read below to learn more.
This Activity uses a simple Loader.
Nevertheless, Loaders are not very practical when it comes to Networking operations. We will demonstrate it in the last loader example, but first, let's see how loaders work.
Loaders don't have any memory issue.
Loaders provide a clear separation of "the asynchronous job to execute" (the Loaders) and "what has to be done when result is received" (LoaderCallbacks). Thus, it doesn't encourage using an inner class for loaders as there is no need to update the UI from within the loaders. Loaders are designed to be written as separate classes or static inner classes. If your loaders are provided as inner classes, you could have memory leak issues. But the loader framework prevents you from doing this, you will get a RuntimeException is you try to do so.
Although, we should note that role separation is not very clear in the LoaderManager.LoaderCallbacks interface : the interface defines both management of loader life cycle methods (onCreateLoader and onLoaderReset) and a listener for Loader's computation result (onLoaderFinished).
Generally, an activity will provide LoaderCallbacks either by using an inner class, or implementing the LoaderCallbacks interface by itself. These callbacks are removed from the loader when activity is destroyed and re-associated to the loader when a new instance of the activity is created (after rotation for instance).
In this demo, you will face a bug of the support library : after 2 rotations, you will receive an Exception : Called doRetain when not started: LoaderManager. This will be logged in adb but can't be observed via the UI.
On this demo activity, you have to wait for the Loader to finish its task, it will then update the UI. There is no progress indication provided by loaders out of the box. We propose a work around for this in our next example.
To cancel a loader is easy, you can ask the load manager to destroy the loader.