Google官方android架构todo-mvp(译)

todo-mvp架构项目地址

todo-mvp

这个app版本被称作todo-mvp，给这个工程的其他示例提供一个基础的架构展示。这个版本的目的在于：

• 在没有使用任何架构框架下，提供一个基础的Model-View-Presenter (MVP) 架构。
• 作为该项目中相比其他示例异同点的一个参考。

注意：在这个项目的所有库分支中使用了如下命名约定去区分View类和MVP views:

• "Android View"是指android.view.View类。
• 在mvp架构中从presenter中接受命令的视图是指"view"。

你需要什么####

在研究这个示例之前，先去熟悉以下内容对你将会很有帮助：

• 这个项目的README。
• MVP架构。

这个todo-mvp项目使用了以下依赖：

• Common Android support libraries - com.android.support.*包提供向后兼容以及其他功能。
• Android Testing Support Library - 一个使用Espresso和AndroidJUnitRunner做UI测试的框架。
• Mockito - 一个实现单元测试的模拟框架。
• Guava - 一套由google开发的用于android app的java库。

在这个版本的app和其他依赖于它的app里，都实现了以下的类和接口：

• 一个定义了view和presenter之间联系的协议类。
• 一个创建fragments和presenters的Activity。
• 一个实现了view接口的Fragment。
• 一个实现了相对应协议接口的presenter类。

一个presenter通常处理业务逻辑，相对应的view持有Android UI的工作。视图层是不包含逻辑的； 它将presenter的命令转换成UI动作，同时将监听到的用户的操作传递到presenter层。

实现app####

每一个使用不同的途径实现相同功能的app版本都去展示和对比很多架构设计。比如这个版本用如下途径去解决通用的实现问题：

• 这个示例使用product flavors去取代编译期的模块，提供假数据来做手动和自动测试。
• 这个版本使用回调来处理异步任务。

留心下面的插图，显示这个app版本使用fragments，这其中有两个原因：

• activities和fragments的使用允许更好的关系分离促成了MVP的实现。在这个app版本中，Activity是总控制器，来创建和关联views 和presenters。
• fragments 的使用支持平板电脑的布局，或者多视图的ui。
  ，
  这个app版本包含了很多覆盖presenters，repositories，data sources的单元测试，同时包含了依赖假数据的ui测试，方便的通过依赖注入提供假模块，想更多了解依赖注入来方便测试的，详情请看Leveraging product flavors in Android Studio for hermetic testing

维护app####

这个示例包含了类和接口，比如presenters和约定，这些相比于那些传统的没有使用特殊架构的项目来说，增加了很多代码量。

下面的表格统计了实现这个app版本的代码量，你可以使用它来和这个工程的其他示例做一个基础的比较。

</br>
</br>
自我学习，粗略翻译，仅供参考，不当之处烦请指出！