MVPArms 心得记录

MVC与MVP比较

MVC_MVP.png

相同点:

  • View:Activity&Fragment(为省事后文只说Activity啦) + layout xml,职责是显示信息和响应用户操作;
  • Model:提供数据的增删改查操作,并通过回调方法把结果反馈出去;数据位置是抽象过的,可能在本地或远程

不同点:

MVC模式

Activity还担当了Controller角色,这样职责又再增加:执行业务逻辑、调用Model操作数据以及把操作结果更新到界面上。

Activity=View+Controller,带来的问题:

  • 违背单一职责原则,界面操作和业务逻辑混在一起;
  • 业务逻辑原本是与平台无关的抽象,现在和安卓界面捆在一起,没法单元测试了

太Low了,让Presenter来主持大局吧

MVP模式:新增Presenter

  • 职责:体现抽象的业务逻辑、调用Model操纵数据、调用View刷新显示和展示信息、响应用户操作

  • Activity的Controler职责废除,由Presenter接手

    Activity大大简化

             1) 只由Presenter派活儿,被动显示信息
    
             2) 用户操作直接传递给Presenter处理
    
             3)与Model断交,两者互不相认
    

MVPArms架构实践

问题.Presenter怎么依赖View和Model

Presenter是平台无关的,是抽象的,View和Model是平台相关的,是具体的;既然不能直接依赖,那就需要把View和Model抽象为接口;

google官方todo-mvp是提供一个Contract接口,包含View和Presenter子接口

MVPArms的做法是在Contract接口中包含View和Model子接口;

至于Presenter是否需要抽取为接口,网上颇有争论,后文再聊

问题.类太多啦

嗯,让我们算一下有哪些类和接口

类:Activity, Presenter, Model,

接口:Contract(View、Model)

再加上Dagger需要的Module, Component;吓死宝宝了!

类多对这个问题要理性看待,只要职责清晰不重复,从解耦角度看反而是正面的,不是问题;

当然人都是懒的,工作量太多了怎么办?MVPArms模板出动,全家桶一次创建好

问题:职责细分后对象间的依赖怎么办?让Dagger来

原本Activity的一大块工作,现在被Presenter承包了,起码要创建Presenter吧,此外Presenter和Model也是需要资源才能干活的,比如:application context,adapter等等,这样多出了这些事情要做:

  • activity中创建new presenter,presenter中创建model

  • presenter增加setXXX,setYYY, setZZZ,给activity调用以传递资源

  • model可能也要增加setXXX,setYYY,给presenter调用;

    一堆无聊的代码!

    你会说不用啊,大部分资源都是全局的,做成单例直接XXX.getInstance就行了,但还是有很多资源不是单例的,而且本身单例模式对单元测试就不友好。

    好了,该Dagger登场了,不用再手工创建presenter,也不用setXXX了,全局资源也不用写成单例了,标注为@Singleton再通过AppComponent注入就行

    不过Dagger这货确实不直观,需要挺多学习成本,但是值得。

    Dagger解惑

  • DI容器和入口

    activity,fragment和Application是常用的DI容器。注入入口是:

    DaggerUserComponent.builder()
                    .appComponent(appComponent) // MVPArms在此处传入App全局依赖
                    .userModule(new UserModule(this))
                    .build()
                    .inject(this);
    

    这句调用完以后,带有@Inject注解的字段(Presenter、Model、Adapter等)都会被赋值;

  • Scope和单例生命周期:

    普通单例同类的static变量引用,即一个进程中只有一个单例对象;

如果把普通单例说成是全局单例,则dagger Scope修饰出来的单例,是局部单例。

对,这几个Scope作用没有区别,一毛一样:@Singleton @Activity @Fragment

至于被Scope修饰实例的生命周期,则跟随其所属Component:

  • Component在activity,fragment中创建:生命周期和activity,fragment一样
  • Component在Application中创建:生命周期和app一样长

RxJava:遇见更好的Model

Model的方法举例,调用者是P层:

// 不采用RxJava
void getUser(int idStart, int count, Callback<List<User>> resultCallback);

// 采用RxJava
Observable<List<User>> getUser(int idStart, int count);

采用RxJava后,返回值变为Obserable<XXX>,由于Obserable天然的数据流属性,带来了以下好处:

  • 不用Callback了,P层subscribe就行

  • 返回值更直观,一目了然

  • Obserable可以自如的切换线程,这样可以把切换线程操作放到P层,Model层方法更简洁

  • Obserable可以进行灵活的变换操作,比如

    • 如果网络返回值是包装过的,而非直接是一个List<User>时,可以做map变换,取出map

    • 如果网络报错提示token过期,可以做flatMap变换,插入一个login,然后再次getUser

      这两种情况用传统Callback方式也能搞定,但嵌套callback远不如Rx分步流水线优雅

RxJava 结合Model场景

  • 网络

    必须是retrofit了,带上RxJavaCallAdapter;

    再加上RxCache,则一并搞定缓存读写,RxCache是挺方便的,但功能并不全面,比如要强制读缓存就不行,需要二次开发

  • 数据库

    这部分MVPArms没有封装;能想到的理想方案是RxJava结合Room,等到有实践再经验再补充;

让Presenter和Model感知ActivityLifeCycle

使用 2017 Google IO 发布的 Architecture Components 中的 Lifecycles 的新特性 (此特性已被加入 Support library),使Presenter和Model可以感知SupportActivity和Fragment的生命周期;

MVPArms 怎么做到的,上Code:

public class BasePresenter<M extends IModel, V extends IView> 
                            implements IPresenter, LifecycleObserver {
@Override
    public void onStart() {
        //将 LifecycleObserver 注册给 LifecycleOwner 后 @OnLifecycleEvent 才可以正常使用
        if (mRootView != null && mRootView instanceof LifecycleOwner) {
          ((LifecycleOwner) mRootView).getLifecycle().addObserver(this);
          if (mModel!= null && mModel instanceof LifecycleObserver){
              ((LifecycleOwner) mRootView).getLifecycle().addObserver((LifecycleObserver) mModel);
            }
        }
    }

这样Presenter可以主动执行操作,不需要通过Activity来启动了,比如:

@OnLifecycleEvent(Lifecycle.Event.ON_CREATE)
void onCreate() {   
    requestUsers(true);//打开 App 时自动加载列表
}

这段代码是在Activity.onCreate()后面执行

Contact中是否要写Presenter接口

这个问题存在争论,google todo-mvp-exmaple是写了P接口的;

Contract中包含MVP三个接口,看起来是比较清晰了,但在MVPArms框架中,P接口没有必要存在:

  • 没有任何地方需要用到,P接口存在反而会让人迷惑:Activity类的Presenter泛型参数到底填P接口还是P类呢,实际填P接口会导致BaseActivity的mPresenter对象Dagger编译报告MissBinding;既然这么尴尬,还是不要写P接口了吧
  • 另一个不写P接口的理由是:Activity所依赖的P已经是抽象的业务逻辑了,没有必要再多做抽象

认为要写P接口的人,一般都用这个理由:看起来P暴露给View的接口方法更清晰。

能懒则懒,我喜欢不写。

其它问题

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 143,639评论 1 302
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 61,591评论 1 258
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 95,050评论 0 213
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 41,169评论 0 180
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 48,976评论 1 258
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 38,876评论 1 178
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 30,476评论 2 273
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 29,229评论 0 167
  • 想象着我的养父在大火中拼命挣扎,窒息,最后皮肤化为焦炭。我心中就已经是抑制不住地欢快,这就叫做以其人之道,还治其人...
    爱写小说的胖达阅读 29,095评论 6 234
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 32,579评论 0 213
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 29,356评论 2 215
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 30,698评论 1 232
  • 白月光回国,霸总把我这个替身辞退。还一脸阴沉的警告我。[不要出现在思思面前, 不然我有一百种方法让你生不如死。]我...
    爱写小说的胖达阅读 24,272评论 0 32
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 27,168评论 2 214
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 31,605评论 3 210
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 25,645评论 0 9
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 26,035评论 0 166
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 33,609评论 2 232
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 33,698评论 2 233

推荐阅读更多精彩内容