MVP一直想学习,奈何上班时间紧,离职之后抑郁又爆发,现在算是勉强回复了点状态了吧.

MVP的理解

View的基本功能

View在MVP模式作为一个方便解耦的划分功能是非常单一的,仅仅只是数据的展示而已,所以通常View的接口都是viod的,不同的界面对应不同类型的View.

例如项目中的:
ISwipeRefreshView
方法很明显的体现了该View的功能,显示影藏刷新,以及错误提示.
IMainView
中的方法也挺简单,填充数据,添加数据,没有更多数据,以及一个更新日志,就没了.

Model的数据交互

Mode层来控制数据的获取,只关心数据的获取,由Persenter控制其返回结果,来与View进行交互.

Presenter的交互控制取舍

Presenter负责所有的逻辑控制,是项目的核心,控制Model和View的交互处理,线程切换等等.
通常来说Activity只负责View的展示功能,所有交互都放到Presenter里进行处理,但是View同时负责了处理用户交互操作,必然就要处理一些交互处理.
处理方式是在Activity中调用Presenter处理?
个人感觉不合适,既然要分离,那么就彻底分离,回调去让Presenter去实现,让Presenter内部去负责处理,Activity不关心.

谷歌的MVP实现

谷歌的项目

MVP的写法

相对于常见的MVP模式多了一个Contract,Contract是一个接口类,类中只有View和Presenter两个接口.
这种写法将要配对使用的View Presenter写在了一起,可读性很好.

项目的分包

项目的分包一直没有一个统一的标准,这里比较喜欢谷歌的分包方法,将Activity功能明确,按照功能来分包,包下包含功能的Activity,使用到的Contract,Presenter等.

Model层的划分

项目中的Model层独立出来了,并做了本地和模拟远程两种处理方式,通过TasksRepository来进行统一的管理,本地远程和管理的Repository统统继承了TasksDataSource接口,来实现对数据的获取保存等操作.
在Repository中进行网络获取和本地获取的判断处理.同时进行本地化的保存.

小结

在谷歌方案中View和Presenter是处于同一包下的,而Model是单独在data包下的,在项目中只有一种类型的Model,但是在项目中个模块的划分自然也带来不同的Model类型,通常Model和Presenter关系一对多,多对一都是由可能的,所以Model需要进行功能的细分.

MVP的实战

利用之前做过的一个题目推倒重做.

Presenter的取舍

问题:
在项目中的界面,主要的内容展示是ViewPager,那么Presenter在主页面中是否存在,内容主要在ViewPager中主界面可以说只是一个壳子,操作全在ViewPager中
结果:
~~~想按照MVP的模式来进行,界面中也对应指定的Presenter但是,这个Presenter是在不知道怎么写,毕竟首页就只是一个ViewPager和Adapter,不知道怎么插入Presenter~~~
主界面的Activity只是一个壳子,没有操作,即不需要对应的P和V.

Presenter的划分

问题:
在我的理解中逻辑操作尽量的交给Presenter,那么那些自成一体的控件,如RecyclerView有自己的Adapter形成了一个小循环,Presenter是否需要插入其中,如何插入其中,变为一个成功的小三?
结果:
从谷歌的项目分析来看,Presenter不需要插入其中,但是内部的相应操作(例如点击等)需要通过接口的方式来交给Presenter来进行处理.