Android MVP - Contract

字数 1622阅读 855

说起Android比较流行的架构模型,MVC、MVP、MVVM这几种是最常见的,也是当前主流的架构模型,本篇通过对MVC到MVP的进化过程,给出一种MVP个人认为比较适合的开发模式 - Contract用法(MVVM下节再讨论):

MVP前世

MVC模式(Model、View、Controller)已经开始渐渐地退出,它最大的痛点在于Controller中既承载了View又包括了业务逻辑,导致Controller最终会很庞大,不利于维护和可读,比如:

public class XXXActivity extents Activity {
     public void onCreate(Bundle saveInstanceState) {
          super.onCreate(saveInstanceState);
          setContentView(layout);
          initView();
          initData();
     } 
     
     public void initView() {
            view1 = findViewById(id);
            view2 = findViewById(id);
            ...
            view1.setOnClickListener(this);
            view2.setXXListener(..);
            ...
     }

     public void initData() {
           model.loadData(response -> {
               view1.setXXX(response.XX);
               view2.setXXX(response.XX);
          });
           ...
     }

     @Override
     public void onClick(View v) {
           model.commit();
           model.doSth();
           ...
     }
}

即使你拆分出许多XXXHelper或者说XXXViewBlock,并且只在Controller中处理业务流程(Helper或者Block中持有Activity引用,不持有Model,为了不与Model耦合在一起),比如:

public class XXXActivity extents Activity {
     private XXViewHelper helper1;
     private XXViewHelper helper2;
     public void onCreate(Bundle saveInstanceState) {
          super.onCreate(saveInstanceState);
          setContentView(layout);
          initView();
          initData();
     } 
     
     public void initView() {
            helper1 = new XXViewHelper(this); // 传入Activity
            helper2 = new XXViewHelper(this); // 传入Activity
     }

     public void initData() {
           model.loadData(response -> {
               helper1.updateView(response);
               helper2.updateView(response);
          });
           ...
     }

     // 供Helper调用
     public void commit() {
           model.commit();
     }

     // 供Helper调用
     public void doSth() {
           model.doSth();
     }
}

但仍然解决不了的问题是,Activity向这些Helper或者Block暴露的信息太多了,比如生命周期这些方法,以及不希望Helper它们看到的方法,不利于开发者对业务流程的理解,并且看到没有?现在的Activity已经有点像Presenter了,只是里边还存在一些 Helper的初始化。

MVP今生

由于上述分析,为了进一步减轻Activity的压力,所以决定将Activity只做一些与View相关的事情,那处理业务流程的部分去哪了?这个就是新产生的一个模块-Presenter。虽然很多文章都有写,但我还是再次声明下它们的工作职责,如下:

MVP示意图

View: 只处理UI及页面效果的细节,向Presenter暴露更新UI的方法;并且持有Presenter的引用,通过Presenter对其暴露的方法进行一些初始化页面以及业务提交等动作,但不关注动作的具体实现。

Presenter: 只关注业务逻辑的细节,持有View的引用,通过调用View层向其暴露的方法去更新UI (这里的View引用不是具体某个控件的引用,我们也不能让Presenter持有某一控件的引用);并且也持有一个或者多个model的引用(在于你想将Presenter,也就是业务逻辑拆分的程度,避免Presenter也像MVC中Controller一样被撑爆),可以使用model,通过对数据库或者网络的访问从而拿到数据,调用View暴露的方法去刷新UI。

Model:向Presenter暴露获取、存储、提交数据等方法,具体实现细节Presenter不关注;Model通过Callback 将数据返回给Presenter。

Ok,按照之前规定的原则:

  • View 向 Presenter 暴露更新UI的方法,于是我们有了 IView
  • Presenter 向 View 暴露执行一些特定业务方法,比如初始化页面,提交等。

于是,就产生了第一种MVP模式:


MVP第一种模式

看到以上类图,可能会有人有疑问:

  1. 在IView中为什么我不直接写 updateView(Response r),这样不是写的接口方法更少吗?

    这个问题问的好!因为我曾经也有过这样的问题,试想一下,如果我们把Model中的Response直接存在于Activity(View层)中,那当我们更改Response的时候,会导致View层也需要进行相应的变动,还能做到View和Model的完全解耦吗?所以View 向 Presenter暴露的方法参数一定要符合两点:
    (1). 基本数据类型
    (2). 公共数据类型

  2. 为什么要写IPresenter,让Activity直接引用 XXXPresenter不就好了?

    确实,这样做从功能上来说也可以,但是,为了更严格一些,让Presenter向View暴露那些View关注的方法,这样开发View的同学就会一下子明白自己只需要关注哪些方法就够了;同理,Presenter持有IView的引用而不是Activity的也是这个原因。

按照以上模式,我们用伪代码来实现一下第一种MVP模式(以下代码不严谨,只表达意思):

Presenter:
interface IPresenter {
     void initData();
     void commit();
}

class XXXPresenter implements IPresenter {
       private IView mView;
       private Model mModel;
       private Callback mCallback = new Callback() {
             public void onSuccess(Response r) {
                  mView.cancelLoading();
                  if (r.url == 'initDataUrl') {
                       mView.updateHeader(r.header);
                       mView.updateContent(r.content);
                  } else if (r.url == 'commitUrl') {
                       // 页面跳转或者其他什么的
                  }
             }
             public void onError(Error e) {
                 mView.showError();
             }
       };
 
       XXXPresenter(IView view) {
            mView = view;
            mModel = new Model();
       }
       
       @Override
       public void initData() {
             mView.showLoading();
             mModel.request(xx, xx, mCallback);
       }

       @Override
       public void commit() {
             mView.showLoading();
             mModel.request(xx, xx, mCallback);
       }
}
View:
interface IView {
     void updateHeader(String header);
     void updateContent(String content);
     void showLoading();
     void cancelLoading();
     void showError(String error);
}

public class XXXActivity extends BaseActivity implements IView {
       private IPresenter mPresenter;
       private TextView tvHeader;
       private TextView tvContent;
       
       public void onCreate(Bundle saveInstanceState) {
          super.onCreate(saveInstanceState);
          setContentView(layout);
          initView();
          initData();
     } 

     public void initView() {
         tvHeader = findViewById(..);
         tvContent = findViewById(..);
         tvHeader.setOnClickListener(new OnClickListener(){
             public void onClick(View v) {
                 mPresenter.commit();
             }
         });
     }

     public void initData() {
         mPresenter = new XXXPresenter(this);
         mPresenter.initData();
     }
     
     @Override
     public void updateHeader(String header) {
         tvHeader.setText(header);
     }
    
     @Override
     public void updateContent(String content) {
         tvContent.setText(content);
     }
}

由于 showLoading、cancelLoading 以及 showError都是公用方法,所以你可以把它们放到 BaseActivity中,不用每个Activity都实现一遍。

讲完了吗?Contract在哪呢? 好汉不要急,待我娓娓道来~
以上的MVP确实解决了两个问题:

  1. Activity过重
  2. View与Model解耦

但是,我觉得还没有解决好,哪里还有问题呢:

  1. IView 每次都要声明 showLoading等公共方法
  2. Presenter中每次请求时都要调用mView的showLoading等公共方法
  3. 能不能把IView和IPresenter定义在同一个文件里,这样我就能一眼看出这个页面的业务是什么样子的。

带着这几个问题,Google官方的MVP Contract横空出世:

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

关注一下工程结构,如下:



如果我们按照模块划分包的话,最适合这种模式,我们来看下一个模块下的组成:


AddEditTaskContract
  • 由于我们再BasePresenter中因为网络请求可能会调用到View的showLoading等方法,所以BasePresenter我写成了抽象类,并且指定一个<? extends BaseView>的泛型;

  • 上图指定一个Presenter的泛型,目的是为了:

 public interface BaseView<T> {

    void setPresenter(T presenter);

}
AddEditTaskFragment
AddEditTaskPresenter

而Presenter的实例化完全可以放到Activity中执行,所以并不需要给BaseView指定Presenter的泛型(可能有点绕。。。。。。),在按照之前第一种MVP模式的业务逻辑再上一张优化后的类图 :

MVP 之 Contract

话不多说,直接贴一段优化后的伪代码:

// BaseView 
public interface BaseView {
    public void showLoading();
    public void cancelLoading();
    public void showError();
}

// BaseActivity
public class BaseActivity extends Activity implements BaseView {
    public void showLoading() {
          LoadingUtil.showLoading(this);
    }
    public void cancelLoading() {
         LoadingUtil.cancelLoading(this);
    }
    public void showError() {
         LoadingUtil.showError(this);
    }
}
// BasePresenter
public abstract class BasePresenter<View extends BaseView> {
    private View mView;
    protected Callback mCallback = new Callback() {
             public void onStart() {
                  mView.showLoading();
             } 
             public void onSuccess(Response r) {
                  mView.cancelLoading();
                  onRequestSuccess(r);
             }
             public void onError(Error e) {
                 mView.showError();
                 onRequestFailed(e);
             }
       };

       protected abstract void onRequestSuccess(Response r);

       protected abstract void onRequestFailed(Error e);
}
// Contract
interace Contract {
    interface View extends BaseView {
        void updateHeader(String header);
        void updateContent(String content);
    }

   abstract class Presenter extends BasePresenter<View> {
       protected Presenter(View view) {
           super(view);
       }
       protected abstract void initData();
       protected abstract void commit();
   }
}
// 具体的XXPresenter
class XXPresenter extends Contract.Presenter {
     private Model mXXModel;
     protected XXPresenter(View view) {
           super(view);
           mXXModel = new Model();
     }
    protected void initData() {
         mXXModel.request(xx, xx, mCallback);
    }
    protected void commit() {
         mXXModel.commit(xx, xx, mCallback);
    }
    protected void onRequestSuccess(Response r) {
          if (r.url == 'initDataUrl') {
               mView.updateHeader(r.header);
               mView.updateContent(r.content);
         } else if (r.url == 'commitUrl') {
              // 页面跳转或者其他什么的
         }
    }
    protected void onRequestFailed(Error e) {
         // 做一些其他的error逻辑,基类已经调用baseview的showerror
    }
}
// XXActivity
public class XXActivity extends BaseActivity implements Contract.View {
       private Contract.Presenter mPresenter;
       private TextView tvHeader;
       private TextView tvContent;
       
       public void onCreate(Bundle saveInstanceState) {
          super.onCreate(saveInstanceState);
          setContentView(layout);
          initView();
          initData();
     } 

     public void initView() {
         tvHeader = findViewById(..);
         tvContent = findViewById(..);
         tvHeader.setOnClickListener(new OnClickListener(){
             public void onClick(View v) {
                 mPresenter.commit();
             }
         });
     }

     public void initData() {
         mPresenter = new XXPresenter(this);
         mPresenter.initData();
     }
     
     @Override
     public void updateHeader(String header) {
         tvHeader.setText(header);
     }
    
     @Override
     public void updateContent(String content) {
         tvContent.setText(content);
     }    
}

如果是一个View组件而不是Activity或者Fragment,也可以使用,那就需要我们把BaseActivity对于View的公共处理抽成一个BaseViewHelper,这样尽量多地复用代码,代码我就不贴了哈,这也是个题外话~

结束语

以上就是MVP的Contract写法,单看Contract,个人感觉还是比较清晰的,而且再加一部分的代码复用,我相信会让你的app更加敏捷地迭代~

此致 敬礼 凑个一万字整

推荐阅读更多精彩内容