MVP架构在Android平台上的实现分析（二）

在上篇文章里，我们对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的回调接口。

对于该实现，如果你有其他看法或者补充，欢迎在文末留言讨论，也可关注微信公众号“互联网微笔记”（iweibiji）进群交流。