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的接口方法更清晰。

能懒则懒,我喜欢不写。

其它问题

推荐阅读更多精彩内容