转载

Android Architecture Blueprints 学习之 TODO-MVP（三）

在前两篇文章中，主要围绕围绕 MVP 的原理来进行分析，从本文开始，将主题转到实践上面来。

Android Architecture Blueprints 是 Android 官方推荐的架构示范，我们自己在开发的时候如何也能遵循示范中的结构呢？这就是本文开始解决的问题。

项目文件结构

下图是 TODO-MVP 程序的一个文件结构：

其中有以下包：

addedittask：添加修改界面
data：数据源
statistics：统计界面
taskdetail：Todo item 详情页见面
tasks：Todo 事件列表界面（主界面）
util：帮助工具类
BasePresenter、BaseView：P、V 接口基类

界面

在以上的包里面，可以看出 用一个包表示一个界面 ，addedittask、statistics、taskdetail、tasks 都是界面，它们的包的组成具有相似性：

＊Activity
＊Contract
＊Fragment
＊Presenter

四者间的关系在系列的第一篇中已有分析，这里不再赘述。

这里有一点要强调的是，在接口＊Contract 里面，包含有两个接口的定义，分别是 V 和 P，它们分别继承自 BaseView 和 BasePresenter 接口。

数据

下面再来看 data 包，它的内部包含有两个元素：

source 子包：数据源定义
Task 类：Todo list 整个 APP 都是围绕 Task 数据进行操作，它的 Model 定义在这里

MVP 中的 M 在 source 子包中进行定义。其中＊Datasource 与＊Repository 两者关系在本系列的第二篇中已有分析。

BasePresenter、BaseView

在工程的根目录是 P 和 V 接口的通用接口定义：

public interface BasePresenter {     void start(); }

其中，start 对应于 Fragment/Activity 生命周期的 onResume。

public interface BaseView<T> {     void setPresenter(T presenter); }

View 的创建过程在本系列的第一篇中已有分析，在这里要强调的一点是，View (Fragment) 在创建的时候并没有调用 setPresenter 指定 P，此时 P 尚未创建。指定发生在 P 创建的时候，在 P 的构造函数中，最后一句是 View.setPresenter(this) ，通过这一句把自身（P）添加到 V 中去。

在前两篇文章中，深入具体的类剖析了 MVP 之间的关系，相当于微观角度。在本篇中，从整个项目的结构上对 MVP 结构进行概括，相当于从宏观角度。相信有了这三篇文章，从一近一远两个角度来加以分析，就能够对 MVP 结构有一个较为清晰的理解。

原文 http://www.judymax.com/archives/1145

正文到此结束