In the last article, we did some analysis of Google’s official todo-MVP base implementation, and today we continue our discussion of todo-MVP implementation based on Loader mechanism.

This section describes the main features of the Loader mechanism.

Loader mechanism used to load data asynchronously in activities or fragments. When the content of the data source changes, the Loader object can pass the new result, and when the configuration of the Activity that holds the object changes, the Loader object reconnects to the last CursorLoader, which can be used for background data loading when the Activity switches between horizontal and vertical screens.

Classes and methods commonly used in the Loader mechanism are:

LoaderManager: Manages one or more Loader instances, implemented internally in observer mode;

AsyncTaskLoader: Abstract Loader that provides an AsyncTask for asynchronous work;

CursorLoader: Used to request from ContentResover to return a Cursor.

LoaderManager. LoaderCallbacks: users interact with LoaderManager callback interface;

Loadermanager. initLoader: used for the initialization and activation of the Loader, which triggers the above callbacks;

LoaderManager. RestartLoader: restart the loader, the use of new data.

Compared with the basic implementation of Todo-MVP, the implementation of the asynchronous Loader mechanism is used, and the UML static structure diagram of the new/edit task submodule is as follows.





In addition to the TaskLoder class, Activity and Presenter implementations need to be modified, including the following.

1. Add TaskLoader

This class is derived from AsyncTaskLoader and implements the TasksRepositoryObserver interface, which holds a reference to the TasksRepository object through which specific data access tasks are processed.

2. Add TasksLoader

Similar to TaskLoader, this class is designed for multiple task data, for example, to display the saved task data in a list.

3. Modify activities, Presenter and other classes

First, you need to add the creation of a Loader object and its reference to the Activity, such as TaskLoader. This object is passed when Presenter is created.

. Second, the implementation in the Presenter LoaderManager LoaderCallbacks three callback interface, and Presenter need to hold TaskLoader, LoaderManager references, initialize the Loader in the right place.

In this implementation, TasksRepository, TasksDataSource and its derived classes (TasksLocalDataSource and TasksRemoteDataSource) are mainly involved.

For more detailed differences modification, see the mind map below.





Another alternative to using Loader in MVP architecture is to use a synchronous Loader (not AsyncTaskLoader) to store Presenter’s cache so that Presenter objects are not destroyed when the Activity configuration changes. This solution is suitable for more complex presenters, such as multiple threads running in the background at the same time, and its implementation is more complex.

To sum up, the above mentioned solution of using asynchronous Loader mechanism to realize MVP architecture mode, in brief, there are three key aspects:

1. In Model layer, add custom Loader derived class and use it to process asynchronous data access task;

2. In the Activity, create a custom Loader class and pass it to a Presenter object.

Presenter holds a reference to a custom Loader object and LoaderManager and implements its LoaderCallbacks callback interface.

If you have additional comments or additions to this implementation, feel free to comment at the end of this article.