跟着google学习mvp架构

crazyelephant 发布于1月前 阅读66次
0 条评论

作者博客

http://www.jianshu.com/u/cd0fe10b01d2

文章目录

  1. 前言

  2. 文件目录

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

  4. 数据层架构

  5. 关于测试用例

1

前言

跟着google学习mvp架构

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

https://github.com/googlesamples/android-architecture

这章节内容,将会带大家分析google官网这个架构的好东西。

Todo-mvp的样例,其实是一个简单的记事App。

2

文件目录

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

跟着google学习mvp架构

addedittask:编辑记事界面

跟着google学习mvp架构

data:数据架构设计

跟着google学习mvp架构

statistics:显示任务记录

跟着google学习mvp架构

tasks:记事首页

跟着google学习mvp架构

util:工具类

跟着google学习mvp架构

base:基本接口

跟着google学习mvp架构

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

3

基本的Activity里面的MVP架构

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

跟着google学习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

跟着google学习mvp架构

Base的Presenter

跟着google学习mvp架构

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

我们以TaskActivity为例

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

View接口中,是定义所有更改界面需要的方法。

跟着google学习mvp架构

而Presenter接口中,定义所有控制逻辑的方法。

跟着google学习mvp架构

其简单图示关系

跟着google学习mvp架构

MVP是通过接口的方式来解耦,所以View和Presenter都是通过接口来解耦。

在TaskActivity中

跟着google学习mvp架构

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

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

跟着google学习mvp架构

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

跟着google学习mvp架构

TasksRepositroy相当于数据提供者(Model),其本身也是通过接口来解耦,而TasksContract.View相当于界面显示(View),也是接口。

然后View通过setPresenter的方法来,让其和Presenter相关关联。(View和Presenter是可以相互关联的)

4

数据层架构

跟着google学习mvp架构

从这个图可以很清楚看明白数据层是通过REPOSITORY作为入口,分别获取远端数据和本地数据的。

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

跟着google学习mvp架构

TaskDataSource是基础接口,做成基础接口

跟着google学习mvp架构

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

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

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

跟着google学习mvp架构

可以清晰的看到初始化的时候,会传入远端的对象和本地存储的的对象。

跟着google学习mvp架构

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

跟着google学习mvp架构

远端调用的方法,也是通过LoadTasksCallback回调。

跟着google学习mvp架构

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

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

5

关于测试用例

国内现在很多公司以前的开发习惯都不会很注重自动化测试用例,因为自动化用例,需要些测试代码。但是国外的研发,非常重视测试,而且有自己一套的测试流程。测试用例,很可能就是研发自己写出来的。

国内大体上,现在也越来越注重测试了,特别大型App。

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

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

对于单元测试,需要预先了解以下内容:

  • Android Studio的test和AndroidTest

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

  • Mockito:单元测试利器

  • Espresso:支持UI测试的单元测试框架

跟着google学习mvp架构

  • P层:不需要任何Android环境,因此使用Junit测试即可

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

  • M层:涉及到数据库相关操作,因此需要依赖Android环境,使用AndroidJUnitRunner进行测试

跟着google学习mvp架构

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项目单元测试。

http://blog.csdn.net/zrbcsdn/article/details/51306370

跟着google学习mvp架构

查看原文: 跟着google学习mvp架构

需要 登录 后回复方可回复, 如果你还没有账号你可以 注册 一个帐号。