Google官方MVP示例之TODO-MVP
Google官方MVP示例之TODO-MVP
欢迎转载，转载请注明源地址：http://blog.csdn.net/lavor_zl/article/details/51180537，谢谢
TODO-MVP介绍（翻译自官方文档）
摘要
这个示例是众多的变体示例的基础。它展示了一个没有使用架构框架的MVP模型的简单实现。它使用人工依赖注入为仓库提供本地和远程数据源。异步任务用回调处理。
注意：在一个MVP环境中，”View”项被重载。
- android.view.View这个类会被称为”Android View”
- 在MVP中从presenter接受命令的视图被简单的称为”view”
Fragments
这个示例使用Fragments有两个原因：
- Activity和Fragment的分离非常符合这个实现的MVP：Activity是全体的控制器，它创建并连接views和presenters
- 平板电脑布局或显示多个视图的屏幕利用Fragments框架
关键概念
这个程序有4个属性
TasksTaskDetailAddEditTaskStatistics
每个属性有：
- view和presenter定义一个合同
- Activity负责创建fragments和presenters
- Fragment实现view接口
- presenter实现presenter接口
一般来说，业务逻辑在presenter中，并且依赖view去做Android UI的工作。
view几乎不包含业务逻辑，它将presenter的命令转换为UI动作，并且监听用户动作传递给presenter。
合同接口用于定义views和presenters之间的联系。
TODO-MVP分析讲解
工程目录概观
我们发现在主包下面有6个子包和两个接口
- addedittask：添加修改界面
- data：数据源
- statistics：统计界面
- taskdetail：Todo item 详情页见面
- tasks：Todo 事件列表界面（主界面）
- util：帮助工具类
- BasePresenter、BaseView：presenter、view接口基类
我们发现关键概念里面讲的4个属性就是这里面的4个子包，并且这4个子包有很大的相似性，它们都有下面4个接口或者类
- Contract
- Activity
- Fragment
- Presenter
而这4个接口或者类都刚好对应了关键属性中”每个属性都有”下面的四个特点。
入口Activity分析
该示例的入口Activity是tasks包下面的TasksActivity。
我们来看一下该Activity的布局文件，它的结构是这样的
<android.support.v4.widget.DrawerLayout>
<LinearLayout>
<android.support.design.widget.AppBarLayout>
<android.support.v7.widget.Toolbar/>
</android.support.design.widget.AppBarLayout>
<android.support.design.widget.CoordinatorLayout>
<FrameLayout/>
<android.support.design.widget.FloatingActionButton/>
</android.support.design.widget.CoordinatorLayout>
</LinearLayout>
<android.support.design.widget.NavigationView/>
</android.support.v4.widget.DrawerLayout>这是Material Design主页面的标准设模式，不熟悉Material Design的同学们可以参考该Activity来做Material Design的主页面
我们来看一下TasksActivity的代码
该Activity有一个成员变量mTasksPresenter，它是一个P。
我们来看一下它的初始化
mTasksPresenter = new TasksPresenter(Injection.provideTasksRepository(getApplicationContext()), tasksFragment);来分析一下它调用的构造方法
public TasksPresenter(@NonNull TasksRepository tasksRepository, @NonNull TasksContract.View tasksView)该构造方法有两个参数，一个是tasksRepository，另一个是tasksView，很明显tasksRepository是一个M，tasksView是一个V，到此我们发现M，V，P已经凑齐了，并且它们是在P中凑齐的，也就是说P是关联M与V的纽带。
Injection.provideTasksRepository(getApplicationContext())以依赖注入的形式提供一个M
我们来看一下provideTasksRepository方法
public static TasksRepository provideTasksRepository(@NonNull Context context) {
checkNotNull(context);
return TasksRepository.getInstance(FakeTasksRemoteDataSource.getInstance(),
TasksLocalDataSource.getInstance(context));
}它是通过一个远程数据源实例与本地数据源实例来得到该M的实例的。那就代表在M中可以同时操作远程数据与本地数据。
tasksFragment是TasksFragment的一个实例，它显示的内容对应布局文件中的FrameLayout，TasksFragment实现了TasksContract.View这个接口，而TasksContract.View继承了BaseView这个接口，BaseView是MVP中V的顶级接口，所以tasksFragment是MVP中的一个V。
TasksFragment中有一个成员变量mPresenter，该成员变量就是一个P，它是通过下面的方法得到的
public void setPresenter(@NonNull TasksContract.Presenter presenter) {
mPresenter = checkNotNull(presenter);
}这个方法又是在TasksPresenter的构造方法中调用的：mTasksView.setPresenter(this);，这样就可以在V中操作P了，因为事件是在V中发生的，所以事件事件响应也在V中，而对应事件响应的业务逻辑处理就要在P中进行处理了，所以V中会有一个P，利用它来处理业务逻辑，需要处理什么样的业务逻辑就调用P中对应处理该业务逻辑的方法。在P中我们可以发现它没有直接对任何远程数据源和本地数据源的数据进行操作，如果要对数据进行操作，它都是通过调用M中对数据进行操作处理的方法来实现对数据的操作，但是P中可能会进行一些与数据源无关的对通过M得到的数据进行操作处理。这样一来对数据源的操作就全部在M中就行，对业务逻辑的处理就在P中进行，M则负责视图的显示及少量与数据源毫无关系的事件处理。
TasksContract是一个合同类，他下面有两个内部接口，一个是View，另一个是Presenter，他们分别继承MVP中V的顶级接口BaseView和MVP中P的顶级接口BasePresenter。
有人会提出疑问，该示例中的V仅仅只是一个Fragment，而该Fragment只是Activity中的一部分，那么还有其他的视图不在MVP中？
该入口Activity中的主要操作对象都在tasksFragment，其他次要的操作对象基本上不存在什么业务逻辑，只是一些简单的事件响应，不涉及MVP中的M，而这些如此简单的东西如果还放在MVP中的V中反而会降低程序的可读性。
至此，大体的思路我们就理清楚了，Activity负责创建Fragment（V）和Presenter（P），而Presenter（P）的创建需要用到Fragment（V）和Repository（M），Fragment（V）已经被Activity创建了，Repository（M）则通过依赖注入的形式创建，并且Repository（M）可以同时操作远程数据和本地数据，在Presenter（P）中将Presenter（P）传递给Fragment（V），这样就可以在事件响应时调用P中的方法进行业务逻辑处理。