作者博客
http://www.jianshu.com/u/cd0fe10b01d2
文章目录
1
前言
或者你已经看过了google官方相关的MVP样例。
https://github.com/googlesamples/android-architecture
这章节内容,将会带大家分析google官网这个架构的好东西。
Todo-mvp的样例,其实是一个简单的记事App。
2
文件目录
从文件目录我们很简单的看
addedittask:编辑记事界面
data:数据架构设计
statistics:显示任务记录
tasks:记事首页
util:工具类
base:基本接口
这里简单分析一下目录里面,基本就是每个Activity为独立的文件夹,然后数据文件夹里面分为远端和本地,然后base的文件都放在主目录中。
3
基本的Activity里面的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接口中,定义所有控制逻辑的方法。
其简单图示关系
MVP是通过接口的方式来解耦,所以View和Presenter都是通过接口来解耦。
在TaskActivity中
初始化TasksFragment,其继承了Contract的View,而初始化了TaskPresenter,其会继承Contract的Presenter。
就正如架构中的这个黄色部分了
注意初始化的时候Presenter的时候是传入了Model和View的模块,那么才可让Presenter作为内容控制者来统筹全局
TasksRepositroy相当于数据提供者(Model),其本身也是通过接口来解耦,而TasksContract.View相当于界面显示(View),也是接口。
然后View通过setPresenter的方法来,让其和Presenter相关关联。(View和Presenter是可以相互关联的)
4
数据层架构
从这个图可以很清楚看明白数据层是通过REPOSITORY作为入口,分别获取远端数据和本地数据的。
其类图如下,这样看应该比较清晰一点吧。
TaskDataSource是基础接口,做成基础接口
这里的TasksRemoteDataSource只是用一个Map存储来模拟远端的存储,实现TasksDataSource的接口。
而TasksLocalDataSource 用的是本地的数据来存储数据。
最主要的TasksRepository就是做出包装给统一的接口给外部调用。
可以清晰的看到初始化的时候,会传入远端的对象和本地存储的的对象。
然后外包统一的接口给外部调用,以getTasks的方法为例
远端调用的方法,也是通过LoadTasksCallback回调。
这里看了数据层运用的,看起来是简单的封装,其实算是外观模式加接口的变种。
其封装好里面调用的多个类流程代码,通过一个接口类,让外界调用它的流程。
5
关于测试用例
国内现在很多公司以前的开发习惯都不会很注重自动化测试用例,因为自动化用例,需要些测试代码。但是国外的研发,非常重视测试,而且有自己一套的测试流程。测试用例,很可能就是研发自己写出来的。
国内大体上,现在也越来越注重测试了,特别大型App。
这里顺便通过这个todo-mvp 顺便也给大家普及一些测试代码的相关知识吧。
testCompile是声明本地测试的依赖,androidTestCompile是声明Instrumented测试依赖。
对于单元测试,需要预先了解以下内容:
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