原文地址：
https://blog.mindorks.com/essential-guide-for-designing-your-android-app-architecture-mvp-part-1-74efaf1cda40#.lkml1yggq
大多数人开始创建一个 Android APP 时会决定它的核心活动和能力以及如何去获取数据。代码会在一个又一个周期内发展，继而成为一系列不可重用的组件。我们开始打包这些组件，并在 Activity 中通过 api 来使用组件。我们觉得这种做法很优秀并开始将代码尽可能地打碎，直至我们沉浸在组件的海洋中才发现难以找到所需要的组件并使用。如果你有编写测试代码，我们稍后将介绍可测试的概念和如何更安全地回退代码。我们在 Android api 耦合性非常紧密的地方进行开发会感觉代码变得一团糟，这会防止我们去做 JVM 的测试和阻碍测试用例的简单设计。这就是 Activity 或 Fragment 作为控制器的经典 MVC 模式。
所以，我们制定了解决上述的绝大多数问题但是实现起来需要很小心的原则。这些原则，我们称之为MVP设计模式。
那么到底什么是MVP设计模式呢？
MVP设计模式是一套分离代码使其具有重用性和可测试性的指导方针。划分应用组件以此作为基线，称其关注点分离。
Model：负责控制应用内的数据
View：负责在屏幕上显示特殊数据的视图
Presenter：负责 Model 和 View 之间的连接，也可扮演 VIEW 的指导者
界面层唯一的职责就是在 Presenter 的指挥下绘制 UI。
View 代表所有传递给 Presenter 的用户操作。
View 层绝不直接与 Model 层沟通。
Presenter 层的职责是通过特殊事件将 View 层向 Model 发起请求和 Model 层通过行动指导 View 层工作。
Model 层负责取得来自服务器、数据库及文件系统的数据。
以上提到的原则有多种可以实现的方式。每一位开发者应该有自己对此的理解。概括来说，基本的螺母和螺栓在小改动中很常见。
Activity、Fragment和自定义控件在应用中应为 View 层的部分。
每一个 View 都有一个 Presenter 与其一对一的关系。
View 和它的 Presenter 通讯通过接口进行，反之亦然。
Model 层可分为多个部分：APIHelper、PreferenceHelper、DataBaseHelper和FileHelper。这些所有的Helper都属于DataManager（数据管理者），在本质上把所有的 Model 部分连接起来。
Presenter 与 DataManager 的通讯通过接口进行。
DataManager 只有在请求的时候才会执行。
Presenter 不会有任何 Android 的 api.
现在，这些信息可以明显地从任何博客或者MVP的安卓规范中找到。那么这篇文章的要点是什么？
这篇文字是为了解决一个MVP中重要的挑战而写的。如何在整个应用中真正地实行这些规范？
MVP展现一个简单的 Activity 例子时显得非常简单，但当我们尝试对应用中的所有组件绑定在一次的时候感到困惑。
首先我们简单描绘这种架构的蓝图。
架构是你实现任何软件第一件想到的事情。当一个精美的架构可以提供稳定和可扩展性，它将极大地减少在未来的重复工作。如今，大多数的项目都是以团队进行开发，因此在这个架构中，最重要的元素为代码的可读性和模块性。
我们非常依赖第三方库，并且由于用例、bug、辅助的原因，我们不断在可选方案之间切换。所以我们的架构应该被设计成即插即用。
这个安卓架构的蓝图画在包含所有MVP特性和MVP原则之上。
下面的内容在第一次阅读可能会感到被困惑淹没，但在你贯穿这篇文章整个下部分的例子，将会对这些概念豁然开朗。
那些渴求知识的人将得到它。
让我们先来明白每一个部分在架构中的作用。 View： 这个部分操控UI和接受来自用户的交互。由Activity，Fragment，自定义控件共同组成。 MVPView： 这是一个借口，它被View实现。它包括一些暴露给Presenter用于通讯的方法。 Presenter： 这是View层的决策者，它由纯Java类构成，没有任何Android 的 API 。它接受来自View传递过来的用户交互，同时它对最基本的业务逻辑起决策作用。最后指挥 View 去执行特殊的动作。它也和DataManager通讯，以获得处理业务逻辑所需要的数据。 MVPPresenter： 这是一个借口，它被Presenter所实现，它包含一些暴露给View的方法APPDBHelper： 数据库管理和所有关联到数据库的操作在这一部分实现。 DBHelper： 这是一个被APPDBHelper 实现的借口，包含暴露给Application组件的方法。这一层将任何特殊的实现分离，因此使APPDBHelper成为即插即用的单元。 AppPreferenceHelper ： 这是一个类似APPDBHelper 但它的工作是在android sp中读写数据。 PreferenceHelper： 接口层，类似DBHelper，但是被APPPreferenceHelper所实现。 APPAPIHelper： 负责管理网络层API调用和控制API数据。 APIHelper： 接口层，类似DBHelper 但被APPAPIHelper所实现。 DataManager： 这是一个接口，被APPDataManager所实现。它包含方法，暴露于所有管理数据操作的方法。理想地，它代理提供给所有Helper类的服务。DataManager借口扩展了DBHelper，PreferenceHelper 和 APIHelper借口。 AppDataManager： 这是一个涉及任何数据相关操作的接口。DBHelper，PreferenceHelper和APIHelper只为DataManager工作。它将所有特定的操作委托给每一个Helper。
现在，我们熟悉了所有的组件以及他们在Application中的角色。我们现在为各种不同组件规划沟通模式。 Application类的实例化APPDBHelper，APPPreferenceHelper，APPAPIHelper和APPDataManager，方法是向它传递DbHelper, PreferenceHelper 和Helper的引用。 View 组件的实例是Presenter通过MVPPresenter 的引用。 Presenter接受他的View组件和通过MVPView操控它，Presenter也接受DataManager。 DataManager是单例。
这是application 实现MVP的基本方针。
就像一个外科医生教授所有的外科程序，不会有任何用处，直至它真正执行和练习它。我们不能理解这些idea直至我们真正去使用它。
在下一个章节，我们将探索一个真实的APP例子和有希望去明白和很好地理解这些概念。
在第一个章节，我们介绍了MVP的概念和在Android应用架构中如何实现蓝图。如果你没有阅读第一章节，则这篇章节会有很多地方让你不明白。所以，在你继续阅读前请先移步第一章节。
我们将在第一章提到的蓝图为基础上，用MVP架构实现一个完整的Android应用。
这个项目的开发是为了提供适当的方法去构建一个Android APP。它包含大多数情况下APP所有必须的代码块。
这个项目一开始会让你觉得非常复杂，但只要你花费时间去探索，你将拨开它的迷雾。这个项目以Dagger2，RxJava，FastAndroidNetworking和PlaceHolderView 为基础。
通过这个项目来学习，研究它每一个代码，如果它们存在BUG或你能找到更加优秀的逻辑实现，请创建一个下拉请求。我们逐步地写测试，所以你空闲的时候也可以对其创建下拉请求来作贡献。
这个APP有一个登陆页和主页。登录页实现私有账号及谷歌和Facebook的第三登陆。第三方登录使用虚假的api来实现。登陆功能基于获取token，token用于后续访问api。主界面创建了卡片，有关于MVP的问题。这个库包含的代码是展示了作为骨架的绝大多数的应用组件是如何工作。
整个APP包结构应该分为五个部分：
data：包含所有数据获取及他们的组件。
di:依赖使用Dagger2提供的类。
ui：视图类和与他们通讯的Presenter
service：应用服务。
utils：公共类。
类被设计成尽可能最大化被复用。
这有许多有趣的部分，如果我尝试在开始就解释他们会导致一次性引入太多概念。所以我觉得最合适是对核心理念进行解释，读者可以通过项目来掌握这样的概念。我建议你在这个项目上至少花费一周时间来进行研究学习。
学习 build.gradle 和查看所有在使用的依赖。
探索数据包和实现Helper类。
ui基础包创建Activity Fragment SubView 和 Presenter的基本实现。所有其他引用组件应该被这个类派生出来。
di 包 应用内是提供依赖的类，明白依赖的注入，通过Dagger2的说明来了解。
资源文件：styles,fonts,drawable.
通过第三篇文章掌握MVP在Dialogs,ViewPager,RecyclerView 和Adapters 的用法。
如果你的项目有很多开发人员同时工作和项目内容非常巨大，则阅读这篇关于MVP延伸的文章。
非常高兴我们在这一系列文章的第一第二章节中构建起MVP架构非常受欢迎，项目库通过你的努力会更加完善。
在开发的过程中，你在这个架构中寻求很多关于基于View的实现的Dialog 和 Adapter。
在这个案例中，你不用阅读很早的资源，我非常推荐这些在你读这篇文章之前。这是他们的链接。
https://github.com/MindorksOpenSource/android-mvp-architecture
在这篇文章，我们将对这个架构的评级对话框和Activity进行延伸。
首先列下所有特性和用例。
这个对话框会显示五颗星来供用户选择他对APP的使用体验。
如果星星数量少于5，我们修改对话框，通过询问改进来反馈。
如果星星数量等于5，我们显示应用商店排名选项来供用户添加评论。
排名信息将会发送到APP后端服务器。
这个评分对话框是用户终端的非必须特性，但是对开发人员终端来说具有非常高价值。所以这款应用必须非常巧妙地执行这一功能。
我推荐使用大空间来间隔两个连续的编程方式评分对话框的显示。
