概要
该例是其他衍生例子的基础。该例不使用Android framework而简单实现了 Model-View-Presenter 模式。本地和远程数据源仓库是通过手工依赖而注入的。异步任务通过操作回调
注意：
在MVP的上下文中，叫做"view"的应该重新解读：
1. "android.view.View"包下的类会被解读为View
2. 在MVP中一个从Presenter接受命令的View被简单的叫做“View”
Fragments
使用Fragments有两个原因：
1. Activity与Fragment的友好分离非常适合实现MVP：Activity对于创建、联系View和Presenter是总的控制器
2.平板的多View多屏幕利用的Fragment框架的优势来布局的
关键概念
app中有四个功能
1. Tasks
2. TaskDetail
3. AddEditTask
4. Statistics
每个功能都有：
1. View和Presenter之间具有协议（接口实现）
2. 一个负责创建Fragment和Presenter的Activity
3. 实现了View接口的Fragment
4.实现了Presenter接口的Presenter
一般来讲，业务逻辑是存在于Presenter中的，并且通过Android UI 来操作一些动作。View中几乎没有逻辑： 它接受Presenter的命令而使得UI发生变化，并且监听用户动作回馈给Presenter。View与Presenter之间的的协议通常是通过interface来定义的。
依赖
Android 原生库(com.android.support.*)
Android 测试库（Espresso, AndroidJUnitRunner…）
Mockito 测试库
Guava (null checking) 基于1.6的扩展类工具集合
特征
复杂性-可理解性
使用第三方框架/依赖/工具？ 没有
概念复杂性
低，因为它是Android上纯净的MVP实现
测试性
单元测试
高，Presenter 和 数据源都是独立单元
UI测试
高，允许fake数据注入到fake模型中 (fake 有点像模拟，伪造的意思)
代码量
相比于传统的工程
与没有架构的传统项目比，本例引入了额外的类、接口、Presenter、仓库等。因此，MVP架构中代码的行数和类数量会更多些。
可维护性
易于修改或添加功能
高
学习成本
低。功能很容易找到，责任明确。开发人员不需要熟悉任何外部依赖项来处理项目。
