谷歌 Basic MVP architecture 基础MVP架构示例

我们先运行看一下，可以看出这个Demo主要实现了一个记事本的功能，添加需要做的事件，并且事件分类完成，未完成，全部等一些筛选功能，业务逻辑并不是太复杂。

那接下来我们开始看代码实现吧，首先打开项目的Manifest 看下，发现只有4个Activity（项目不大，很适合学习），启动类是 TaskActivity，那么，我们就从 TaskActivity 开始学习吧。

进入TaskActivity ，首先看下xml 布局：

整体是一个DrawerLayout 抽屉，实现侧滑效果，主体是利用CoordinatorLayout实现， 里面有个FramLayout,再回到 TaskActivity 的 onCreate（）里可以发现主要是利用 FramLayout 来承载Fragment实现。所以我们如果需要看具体业务实现，需要到 TaskFragment 中去。

由于我们是来看MVP 实现示例的，而MVP大家想必也了解，它主要是依靠 implements 接口来实现的，那我们就先来看下 TaskFragment 实现了哪个接口。

可以看到它是实现了View 接口，那么 MVP中的 V 我们就找到了。接下来就找 P 和 M，我这里是先找MVP 分别是 那几个类，之后再来看里面的具体实现。在 interface VIew 那个类中你发现了 interface Presenter，作者直接把 View 和 Present 接口都写在一个类中了，那我们就来找下谁实现这个Presenter接口。

可以发现是这个TasksPresent 类实现了Present接口。那么 P 也找到了，就剩下M了。

我们都知道 M 和 V 的交流都是通过 P来执行的，那么要寻找M的话还是需要到 P中去找，在TaskPresent中我们找到了 实例化的 TasksRepository,这个就是 M 了。

OK，经过上面的一番寻找，我们将 M，V ，P 三个都找到了，接下来我们就仔细的分析下这三个类，看下它们都做了什么工作，首先是 V 即 TasksFragment :

发现这个TasksFragment 很干净（我用了这个形容词，不知道恰不恰当，当然如果作者能够把adapter 分离出去不要写在一起就更干净了），基本上都是类似于上图的这种实现方法，里面都是一些控件填充数据的操作，而那些完成任务，取消任务的操作都是通过监听交由 Present 去操作：

既然操作都交给Present，点进去看看 Present 里面进行了什么操作：

以上面的三个点击事件举例，在TasksPresent 里面找到那三个方法，openTaskDetail 从名字看出是点击查看详情的，这个是个跳转，不用多看。completeTask 方法是完成任务操作，第一行，判空；第二步，调用 M 里面的 completeTask方法（应该是更改列表数据）;第三步，回调 V 显示，通知任务完成。
那么继续点入 TasksRepository 里面看 complete方法，可以看出这事操作数据，进行更改的操作.

以上就能进行一个操作的完成了，首先是 V 上进行事件触发，V响应并将事件和条件一起派发给 P， P通过V传递过来的条件进行逻辑判断，如果需要进行数据的操作则将 数据操作派发给 M，由M完成数据的操作，这个时候 P 再通知 V进行数据的更新显示。（图是网上找的，看图这样就比较直观了）

View ： 只负责数据的展示与事件的响应
Present ： 负责逻辑的运行 和 View 和 Model之间的沟通
Model ： 只负责数据的操作，比如网络获取数据

所以如果我们需要使用MVP的话，我们需要什么，
1. interface View ，在Activity 或者 Fragment中实现，其中要实例化 PresentTask ，进行操作
2. interface Present ，在 PresentTask 类中实现，其中要实例化 Model ，进行操作
3. Model 类， 主要实现数据的操作