欢迎使用CSDN-markdown编辑器

看到一篇比较好的文章，最近比较忙，所以比较少上QQ和博客了，有事QQ找吧

作者：Hannes Dorfmann
原文链接 : Ted Mosby – Software Architect
文章出自 : Android开发技术前线
译者 : Mr.Simple

我给这篇关于Android库的博客起的名字灵感来源于《老爸老妈浪漫史》中的建筑设计师Ted Mosby。这个Mosby库可以帮助大家在Android上通过Model-View-Presenter模式做出一个完善稳健、可重复使用的软件，还 可以借助ViewState轻松实现屏幕翻转。
Model-View-Presenter (MVP)
MVP模式是一个把view从低层模型分离出来的一种现代模式。MVP由model–view–controller (MVC)软件模式衍生而来，常用于构建UI
• MVP中的M（model）代表的是将会显示在view（UI）中的数据。
• MVP中的V（view）是显示数据（model）并且将用户指令（events）传送到presenter以便作用于那些数据的一个接口。View通常含有Presenter的引用。
• MVP中的P（presenter）扮演的是“中间人”的作用（就如 MVC中的controller），且presenter同时引用view和model。值得注意的是，“Model”这个词并不正确。严格意义上来说， 它指的应该是检索或控制一个Model的业务逻辑层。举个例子，比如你的数据库里面包含了User，而你的View想要显示一个User列表，那么 Presenter会引用数据库中的业务逻辑层（比如DAO）从而查询到一个User列表。如图1-1.

从数据库中查询或显示User列表的具体流程如图1-2：

以上工作流程图应该能够说明问题了。但是，还有以下几点值得注意的地方：
• Presenter不是一个OnClickListener。View主要是负责处理用户输入并调用presenter相应的方法。那么问题来了，为什么不把Presenter 直接做成一个OnClickListener，从而把“转发流程”给省略掉呢？大家想想，如果这样做的话，首先，presenter需要知道view的内部构件。举个例子，如果一个View有两个按钮，且这个view在这两个按钮上都把Presenter 注册成OnClickListener的 话，那么发生点击事件时Presenter （在不知道view中按钮引用等内部构件的情况下）怎么能够区分出是哪一个按钮被点击了 呢？Model，View和Presenter三者应解耦。其次，如果让Presenter 执行OnClickListener，Presenter就 被绑定到了Android平台上。理论上来说presenter和业务逻辑层都是纯旧式的能够与桌面应用或其他任何java应用共享的java代码。
• 大家在第1步和第2步中可以看到，View 只执行Presenter 指 示的操作：用户点击“load user button”（第1步）后，view并没有直接显示加载动画，而是在第2步presenter明确告诉其显示加载动画后才显示的。这一Model- View-Presenter的变体称之为MVP 被动视图。这个view可以说是要多笨有多笨。这时我们需要让presenter以一种更抽象的方式来控制view。比如，presenter在调用 view.showLoading() 时并不控制view的诸如动画等具体事项。所以presenter不应调用view.startAnimation() 等方法。
• 通过执行MVP被动视图，并发性以及多线程更容易处理。大家可以看到，第3步中数据库查询异步运行，并且presenter作为Listener/Observer，在数据准备显示时presenter收到通知。
Android上的MVP
目前为止一切顺利。但是大家怎么样把MVP运用到自己的Android 应用上呢？第一个问题在于，我们要把MVP模式运用到什么地方？Activity上、Fragment上、还是像RelativeLayout这类的 ViewGroup上？我们来看看Android平板上的Gmail应用，如图1-3：

在我看来，上图屏幕中有四个可以使用MVP的地方。我所说的“可以使用MVP的地方”是指屏幕上显示的、在逻辑上属于一个整体的UI元素。因此这些地方也可以称为是可以运用MVP的一个单独的UI单元。如图 1-4.

看起来MVP似乎很适合运用到Activity，特别是Fragment上。通常Fragment只负责显示单一的如ListView之类的内容，就像依靠MailProvider 来获取一系列Mails的InboxPresenter 控制下的 InboxView一样。但是，MVP不 仅仅限于Fragment或Activity，它还可以运用到SearchView中显示的ViewGroup中。在我的大多数app里面我都在 Fragment运用MVP模式。但是大家可以自行决定把MVP运用到什么地方，前提是view是独立的，这样这样presenter才能在不与其他 Presenter冲突的情况下控制View。
我们为什么要实现MVP？
我们如何在不使用MVP模式时显示Email列表到Fragment? 通常，我们需要获取并且合并本地SQL数据库和从IMAP邮件服务器获取的邮件列表，然后将邮件列表绑定到收件箱view中。那么，此时fragment的代码又会是怎么样的呢？我们需要运行两个AsyncTasks 并 实现一个“等待机制”（等到两个任务将两者的加载数据合并到一个单独的mail列表）。我们还需要注意的是在加载时要显示加载动画 （ProgressBar），之后用ListView替代。我们需要把所有的代码放到Fragment中吗？要是加载过程中出现错误怎么办？屏幕翻转怎么 办？谁来负责撤销AsyncTasks ？这一系列的问题都可以通过MVP得到解决。让我们跟那些带有上千行大杂烩代码的activity和fragment说拜拜吧
但是，在我们深入研究如何将MVP运用到Android中之前，我们需要弄清楚的一个问题是：Activity或Fragment究竟是一个View还是一个Presenter。Activity或Fragment似乎既是View也是Presenter，因为它们都有 onCreate() 或onDestroy()之 类的生命周期回调功能，并且它们负责从一个UI控件到另一个UI 控件的转换（比如在加载时显示ProgressBar，然后显示带有数据的ListView）等View操作。大家可能会觉得这里的Activity或 Fragment就是一个Controller，我猜可能也是这么一个初衷。但是在经历了几年的Android应用开发之后，我得出这么一个结论：我们应 该把Activity或Fragment看作是一个不太智能的View，而不是把它们看作一个Presenter。后文我会给出原因。
综上，我想给大家介绍一个在Android平台上开发基于MVP的应用的一个 Mosby库。
Mosby
大家可以在Github和Maven Central上找到Mosby库。Mosby分为几个子模块，大家可以根据自己的需要选取组件。我们来回顾一下最重要的一个模块。
核心模块 ( Core Module)
《老爸老妈浪漫史》中的建筑设计师Ted Mosby想建造一栋摩天大楼。而建造这样一栋宏伟的建筑必须打好坚实的地基。这对Android应用的开发来说是也是一样的道理。基本上，Core Module 分为两种类型：MosbyActivity 和MosbyFragment。这两者是所有其他activity或fragment子类的基类（相当于建筑的地基）。两者都使用我们大家所熟知的APT （Annotation Processing Tool）来减少一些样板式代码。MosbyActivity 和MosbyFragment 使 用Butterknife进行view的注入，使用Icepick 将实例状态保存和存储到Bundle中，使用FragmentArgs注入 Fragment参数。我们不需要再调用Butterknife.inject(this)等插入方法。这类代码已经包含在了MosbyActivity 和 MosbyFragment中。它是即时可用的。我们需要做的就是使用子类中相应的注解。核心模块与MVP没有关联，它只是写一个大型软件的基础。
MVP模块( MVP Module )
Mosby库中的MVP模块使用泛型来确保类型安全。所有view的基类是MvpView。从根本上说这只是一个空的interface 。Presenter的基类是MvpPresenter：
public interface MvpView{}

public interface MvpPresenter{
public void attachView(V view);
public void detachView(boolean retainInstance);
}
上文提到，我们把Activity和Fragment看做View。因此Mosby库的MVP模块提供了 属于MvpViews 的MvpActivity和MvpFragment作为Activity和Fragment的基类。
public abstract class MvpActivity

extends MosbyActivity implements MvpView{

protected P presenter;
@Override  protected void onCreate(Bundle savedInstanceState){
    super.onCreate(savedInstanceState);
    presenter = createPresenter();
    presenter.attachView(this);
    super.onDestroy();
    presenter.detachView(false);
}

protected abstract PcreatePresenter();

}

public abstract class MvpFragment

MosbyFragment implements MvpView{
protected Ppresenter;

@Override public void onViewCreated(View view,@Nullable Bundle savedInstanceState){
    super.onViewCreated(view,savedInstanceState);
    // Create the presenter if needed
    if(presenter == null){
        presenter = createPresenter();
    }
    presenter.attachView(this);
}

@Override public void onDestroyView(){
    super.onDestroyView();
    presenter.detachView(getRetainInstance());
}

protected abstract PcreatePresenter();
}

}

@Override protected void onDestroy(){
这一理念主要是一个MvpView (也就是Fragment or Activity)会关联一个MvpPresenter，并且管理MbpPresenter的声明周期。大家从上面的代码片段可以看到，Mosby使用Activity和Fragement生命周期来实现这一目的。通常presenter是绑定在该生命周期上的。所以初始化或者清理一些东西等操作（例如撤销异步运行任务）应该在 presenter.onAttach()和 presenter.onDetach() 上进行。我们稍后会谈到presenter如何使用setRetainInstanceState(true) “避开”Fragment中的生命周期。我相信大家也注意到了， MvpPresenter是一个interface 。MVP模块提供一个 MvpBasePresenter，这个MvpBasePresenter只持有View（是一个Fragment或Activity）的弱引用，从而避免内存泄露。因此，当presenter想要调用view方法时，我们需要查看isViewAttached() 并使用getView()来获取引用，以检查view是否连接到了presenter。
Loading-Content-Error (LCE)
通常Fragment会一直重复做某一件事。它在后台加载数据，同时显示加载view（即ProgressBar），并在屏幕上显示加载的数据，或 者当加载失败时显示view错误。如今，下拉刷新支持很容易实现，因为SwipeRefreshLayout是Android支持库的组成部分。为了避免 重复执行这一工作流，Mosby库的MVP模块提供了MvpLceView。
public interface MvpLceView extends MvpView{
/**
* 显示一个加载中的视图
* loading view 必须有个id 为 R.id.loadingView的View
* @param pullToRefresh 如果是true,那么表示下拉刷新被触发了
*/
public void showLoading(boolean pullToRefresh);
/**
* 显示 content view.
*