Todo-mvp源码体验

你们好，我是苍王。

如下是我这个系列的相关文章，有兴趣能够参考一下，能够给个喜欢或者关注个人文章。

[Android]如何作一个崩溃率少于千分之三噶应用app--章节列表

或者你已经看过了google官方相关的MVP样例。

google官方样例

这系列的章节内容，将会带你们分析google官网这个架构的好东西。

适合Android入门一年半左右的同窗学习。

这一节咱们将由最简单的Todo-mvp给你们分析。

Todo-mvp的样例，实际上是一个简单的记事App。

一.文件目录

从文件目录咱们很简单的看

addedittask:编辑记事界面

data：数据架构设计

statistics：记事编辑

tasks:记事首页

util:工具类

base:基本接口

这里简单分析一下目录里面，基本就是每一个Activity为独立的文件夹，而后数据文件夹里面分为远端和本地，而后base的文件都放在主目录中。

二.基本的Activity里面的MVP架构

请认真观看官网的这张架构图

基础mvp架构图

图示中很是清楚的说明了MVP的基础架构，Presenter和View之间能够相互操做，数据交流，Model（模块）此处是离开Activity的所有图示都算是Model数据层，能够看到，其实经过一个REPOSITORY来管理数据存储，Remote data source和Local data source表明远端（网络）和本地（SQL）的数据来源。

MVC和MVP最大的区别在于，MVC中M和V是能够通讯交流，而MVP中M和V是无法直接交流的。

Base的View

Base的Presenter

很明显都是以接口的方式来利用组合来作公共的基础接口。

咱们以TaskActivity为例

其模块内都把View和Presenter再次封装到TasksContract统一的接口容器里面。

View接口中，是定义全部更改界面须要的方法。

而Presenter接口中，定义全部控制逻辑的方法。

其简单图示关系

Base架构图

MVP是经过接口的方式来解耦，因此View和Presenter都是经过接口来解耦。

在TaskActivity中

初始化TasksFragment，其继承了Contract的View，而初始化了TaskPresenter，其会继承Contract的Presenter。

继承View

继承Presenter

就正如架构中的这个黄色部分了

注意初始化的时候Presenter的时候是传入了Model和View的模块，那么才可以让Presenter做为内容控制者来统筹全局

TasksRepositroy至关于数据提供者（Model），其自己也是经过接口来解耦，而TasksContract.View至关于界面显示（View），也是接口。

而后View经过setPresenter的方法来，让其和Presenter相关关联。（View和Presenter是能够相互关联的）

三.数据层架构

数据层架构

从这个图能够很清楚看明白数据层是经过REPOSITORY做为入口，分别获取远端数据和本地数据的。

其类图以下，这样看应该比较清晰一点吧。

TaskDataSource是基础接口，作成基础接口，

这里的TasksRemoteDataSource只是用一个Map存储来模拟远端的存储，实现TasksDataSource的接口。

而TasksLocalDataSource 用的是本地的数据来存储数据。

最主要的TasksRepository就是作出包装给统一的接口给外部调用。

能够清晰的看到初始化的时候，会传入远端的对象和本地存储的的对象。

而后外包统一的接口给外部调用，以getTasks的方法为例

远端调用的方法，也是经过LoadTasksCallback回调。

这里看了数据层运用的，看起来是简单的封装，其实算是外观模式加接口的变种。

其封装好里面调用的多个类流程代码，经过一个接口类，让外界调用它的流程。

四.关于测试用例

国内如今不少公司之前的开发习惯都不会很注重自动化测试用例，由于自动化用例，须要些测试代码。可是国外的研发，很是重视测试，并且有本身一套的测试流程。测试用例，极可能就是研发本身写出来的。

国内大致上，如今也愈来愈注重测试了，特别大型App。

这里顺便经过这个todo-mvp 顺便也给你们普及一些测试代码的相关知识吧。

testCompile是声明本地测试的依赖，androidTestCompile是声明Instrumented测试依赖。

对于单元测试，须要预先了解如下内容

Android Studio的test和AndroidTest

AndroidJUnitRunner：一个兼容Junit4的Andriod单元测试框架

Mockito：单元测试利器

Espresso：支持UI测试的单元测试框架

P层：不须要任何Android环境，所以使用Junit测试便可

V层：使用Google强大的Espresso进行UI的测试

M层：涉及到数据库相关操做，所以须要依赖Android环境，使用AndroidJUnitRunner进行测试

View层

职责：MVP模式下，View层终于扬眉吐气了，View自己该作的事情都能作了，好比UI布局，数据渲染，点击按钮交互等等

测试方式：以正常小QA的测试思惟方法，就能够来定义这一层的测试方式，测试过程当中须要真机或模拟器，并作真实的操做。

测试选型：依赖于Android环境，用谷歌强大的Espresso+AndroidJUnitRunner，Espresso用于模拟和验证各类各样的UI操做，代码存放于AndroidTest中。

Presenter层：

职责：这一层是拉皮条的，负责M和V层的对接，因此有较少的处理输入输出的机会，他只用来控制逻辑，去调用相应的Model和View的逻辑。

测试选型：他的职责决定了他不多去断言输入输出，测试逻辑覆盖的路径是否正确便可，所以他与Android环境无关，用Junit+Mockito测试便可，代码存放于test中。

Model层

职责：负责数据的存取，数据可能来自于网络、数据库和内存

数据库增删改查：需测试数据存取的准确性，依赖Android环境进行测试，所以使用AndroidJUnitRunner，代码存放于androidTest中

网络请求：不测试真实的网络请求，但提供了Fake供其余层调用测试。

封装的门面类：决定了数据的来源和去向是来自于本地数据库 or 网络 or 内存，此为真正对其余层暴露的Model类。此类不作数据准确性的验证，只作mock测试，验证覆盖路径。UT选型Junit+Mockito，代码存放于test中。

这里想深刻了解有关测试的内用能够看Android官方MVP项目单元测试。

我创建了一个关于Android架构学习的群，里面能够进一步进行组件化学习和架构思想的的交流。

群号是316556016，也能够扫码进群。我在这里期待大家的加入！！！

这一节就介绍到这里了。

下一节将会介绍下一个MVP架构的内容，敬请期待！！！