在上篇文章里，我们对Google官方的TODO-MVP基础实现做了一些分析，今天继续探讨基于Loader机制的TODO-MVP实现。
首先简单介绍Loader机制的主要特点。
Loader机制，主要用在Activity或Fragment中异步加载数据。当数据源内容改变时，Loader对象能够传递新的结果，并且当持有该对象的Activity配置发生改变后，该Loader对象会重新连接到最后一个CursorLoader，可用于Activity横竖屏切换时的后台数据加载等场景。
在Loader机制中，常用的类和方法有：
LoaderManager：管理一个或多个Loader实例，内部基于观察者模式实现；
AsyncTaskLoader：抽象Loader，提供一个AsyncTask进行异步工作；
CursorLoader：用于向ContentResover请求，返回一个Cursor。
LoaderManager.LoaderCallbacks：使用者与LoaderManager交互的回调接口；
LoaderManager.initLoader：用于loader的初始化和激活，该调用会触发上述回调；
LoaderManager.restartLoader：重启loader，使用新的数据。
相对于TODO-MVP的基础实现，使用了异步Loader机制的实现，其新建/编辑任务子模块的UML静态结构图如下。
从上图基本可以看出，在该子模块，除了新增TaskLoder类，Activity、Presenter相关实现也需要修改，具体包括下面几点。
1、新增TaskLoader
该类派生于AsyncTaskLoader并实现了TasksRepositoryObserver接口，它持有TasksRepository对象的引用，通过该对象处理具体的数据访问任务。
2、新增TasksLoader
与TaskLoader类似，只是该类是针对多条任务数据而设的，例如以列表方式显示用户保存的各项任务数据。
3、Activity、Presenter等类的修改
首先，需要在Activity中增加Loader对象的创建及其引用，例如TaskLoader。在创建Presenter时，将该对象传递过去。
其次，在Presenter中实现LoaderManager.LoaderCallbacks的3个回调接口，并且Presenter需要持有TaskLoader、LoaderManager的引用，在合适的地方初始化Loader。
再次，在Model层也需要对应修改，该实现中，主要涉及TasksRepository、TasksDataSource及其派生类（TasksLocalDataSource和TasksRemoteDataSource）。
更详细的差异性修改，可以参考下面的思维导图。
对于Loader机制在MVP架构中的应用，也有人提出了其他方案：使用同步Loader（不是AsyncTaskLoader）来保存Presenter的缓存，以避免Activity配置变化时，Presenter对象也一起被销毁。该方案适用较复杂的Presenter，例如同时有多个线程后台运行，其实现也更复杂些。
做个总结，上述使用异步Loader机制来实现MVP架构模式的方案，简单来说，重点有3方面：
1、在Model层，增加自定义Loader派生类并用其处理异步数据访问任务；
2、在Activity中，创建自定义的Loader类并传递给Presenter对象；
3、在Presenter中，持有自定义Loader对象与LoaderManager的引用并实现其LoaderCallbacks的回调接口。
对于该实现，如果你有其他看法或者补充，欢迎在文末留言讨论。
