Google官方MVP示例之TODO-MVP
Google官方MVP示例之TODO-MVP
个人分析：
什么是MVP？
MVP是Model, View和Presenter的简称。是非常有名的MVC模式的演化版。MVP模式把显示逻辑和从业务逻辑层中分离出来，理想状况下，MVP模式中，在替换不同的视图(View)的情况下，可以实现完全相同的业务逻辑。
Presenter代替了MVC中Controller，它比Controller担当更多的任务，也更加复杂。Presenter处理事件，执行相应的逻辑，这些逻辑映射到Model的Command以操作Model。那些处理UI如何工作的代码基本上都位于Presenter。Presenter如同一个乐队的指挥家，表现和协调整个Application，它负责创建和协调其它对象。
MVP与MVC有着一个重大的区别：在MVP中View并不直接使用Model，它们之间的通信是通过Presenter (MVC中的Controller)来进行的，所有的交互都发生在Presenter内部，而在MVC中View会从直接Model中读取数据而不是通过 Controller。
为什么使用MVP模式
因为在Android中，Activity严重耦合了界面和数据获取层。这样不仅导致了Activity的类越来越庞大，而且，如果修改数据获取层，可能也导致整个View都要重写。也非常不利于模块和自动化测试。
MVP使View独立于数据，把大量的逻辑从Activity中提取出来。把应用分层，每层都可以独立测试和变动。
MVP模式是如何工作的
MVP模式中的角色划分并没有标准的划分方法。大致的定义如下：
-
表示器(Presenter)
表示器也可以称为指挥器，它处在View和Model之间，负责从Model中获取数据，然后返回给View。同时决定视图上的交互的处理。 -
视图(View)
视图比较好理解，在Android中一般对应的是Activity，Fragment或者View。因为视图上的交互需要通知表示器，让它决定做什么事情。所以View中一般包含一个Presenter的引用。理想状况下，Presenter一般使用依赖注入的方式实现。 -
模型(Model)
模型是应用程序中的数据处理和业务逻辑部分。
MVP处理流程如下图所示：
注：图片引自http://www.360doc.com/content/10/0225/18/86732016805936.shtml_
用户的请求首先会到达View，View传递请求到特定的Presenter，Presenter从Model获取数据后，再把处理结果通过接口传递到View。
项目介绍
欢迎转载，转载请注明源地址：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 契约类 加入了契约类来统一管理view 与presenter的所有接口，这种方式使得view与presenter中有哪些功能都一目了然，便于维护。
- Activity
- Fragment
- Presenter
而这4个接口或者类都刚好对应了关键属性中”每个属性都有”下面的四个特点。
mvp的实现与组织
入口Activity分析
该示例的入口Activity是tasks包下面的TasksActivity。
我们来看一下该Activity的布局文件，它的结构是这样的
.support.v4.widget.DrawerLayout>
.support.design.widget.AppBarLayout>
.support.v7.widget.Toolbar/>
.support.design.widget.AppBarLayout>
.support.design.widget.CoordinatorLayout>
.support.design.widget.FloatingActionButton/>
.support.design.widget.CoordinatorLayout>
.support.design.widget.NavigationView/>
.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中的方法进行业务逻辑处理。