Google官方MVP示例之TODO-MVP

个人分析：

App架构在Android开发者中一直是讨论比较多的一个话题，目前讨论较多的有MVP、MVVM、Clean这三种。google官方对于架构的态度一直是非常开放的，让开发者自主选择组织和架构app的方式，期望能留给开发者更多的灵活性。

        由于没有一套权威的架构实现，现在很多App项目中在架构方面都有或多或少的问题。第一种常见问题是没有架构，需求中的一个页面对应项目中的一个activity或一个fragment，所有的界面响应代码、业务逻辑代码、数据请求代码等等都集中在其中。第二种常见的问题是架构实现的不断变化，不断在各种架构间摇摆，一直找不到一个适合自己的架构。

        就在近日，google在官方示例中给出了一系列不同架构的app实现，这对于一直困惑于到底该用何种架构的android开发者来说确实是福音，开发者只要根据自己项目的情况，在不同的实现中选择一种即可，当然google也明确表示了这些示例只是用来做参考，而并不是要为了当做标准，下面先为大家简单介绍下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。

项目介绍

Google把这个项目命名为：Android架构蓝图。

项目地址为：https://github.com/googlesamples/android-architecture

下面的内容引用自项目说明：

项目目的是通过展示各种架构app的不同方式来帮助开发者解决架构问题。项目中通过不同的架构概念及方式实现了功能相同的app。你可以用示例来当做参考，或是干脆拿来当做创建app项目的基础。项目中，希望大家能把关注点集中到代码结构、整体架构、可测试性、可维护性这四个方面。当然实现app有很多种方式，千万不要把它当做定式。

项目中有哪些示例

目前已经完成的示例有

• todo-mvp（mvp基础架构示例）

• todo-mvp-loaders（基于mvp基础架构项目，获取数据部分使用了Loaders架构）

• todo-mvp-databinding（基于mvp基础架构项目，使用了数据绑定组件）

仍在进展中的示例有

• todo-mvp-contentproviders（基于mvp基础架构项目，使用了Content Providers）

• todo-mvp-clean（基于mvp基础架构项目，使用了clean架构的概念）

• todo-mvp-dagger（基于mvp基础架构项目，使用了dagger2进行依赖注入）

如何进行选择

这个还是需要开发者自己来做决定，每个项目的说明文件中都说明了该实现的特性。app规模、团队状况、维护工作量的大小、平板是否支持、代码简洁程度偏好，这些都会影响你的选择。

到了这里，想必大家都很想一探究竟了，到底官方示例是如何实现的呢？还是那句话，源码面前，了无秘密。为了能够更好的理解官方mvp架构实现，下面我们从源码的角度来分析todo-mvp（mvp基础架构示例）的实现。我们先从项目的整体组织方式开始，再看项目究竟使用了哪些组件，最后当然是最重要的具体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个属性

• Tasks
• TaskDetail
• AddEditTask
• Statistics

每个属性有：

• 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接口基类

BasePresenter中含有方法start(),该方法的作用是presenter开始获取数据并调用view中方法改变界面显示，其调用时机是在Fragment类的onResume方法中。

BasePresenter中含有方法start(),该方法的作用是presenter开始获取数据并调用view中方法改变界面显示，其调用时机是在Fragment类的onResume方法中。

我们发现关键概念里面讲的4个属性就是这里面的4个子包，并且这4个子包有很大的相似性，它们都有下面4个接口或者类

• Contract   契约类    加入了契约类来统一管理view 与presenter的所有接口，这种方式使得view与presenter中有哪些功能都一目了然，便于维护。
• Activity       activity在项目中是一个全局的控制者，负责创建view以及presenter实例，并将二者联系起来
  
• Fragment   
  
• Presenter

而这4个接口或者类都刚好对应了关键属性中”每个属性都有”下面的四个特点。

mvp的实现与组织

实例中将fragment作为view层的实现类，为什么是fragment呢？有两个原因，第一个原因是我们把activity作为一个全局控制类来创建对象，把fragment作为view，这样两者就能各司其职。第二个原因是因为fragment比较灵活，能够方便的处理界面适配的问题。

presenter构造函数中调用了view得setPresenter方法将自身实例传入，start方法中处理了数据加载与展示。如果需要界面做对应的变化，直接调用view层的方法即可，这样view层与presenter层就能够很好的被划分。

最后还剩下model层实现，项目中model层最大的特点是被赋予了数据获取的职责，与我们平常model层只定义实体对象截然不同，实例中，数据的获取、存储、数据状态变化都是model层的任务，presenter会根据需要调用该层的数据处理逻辑并在需要时将回调传入。这样model、presenter、view都只处理各自的任务，此种实现确实是单一职责最好的诠释。

入口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中的方法进行业务逻辑处理。