[译]使用MVI打造响应式APP(二):View层和Intent层

[qingmei2]

[译]使用MVI打造响应式APP(二):View层和Intent层

原文：REACTIVE APPS WITH MODEL-VIEW-INTENT - PART2 - VIEW AND INTENT
作者：Hannes Dorfmann
译者：却把清梅嗅

在 上文 中，我们探讨了对Model的定义、与 状态 的关系以及如何在通过良好地定义Model来解决一些Android开发中常见的问题。本文将通过 Model-View-Intent ，即MVI模式，继续我们的 响应式App 构建之旅。

如果您尚未阅读上一小节，则应在继续阅读本文之前阅读该部分。总结一下：以“传统的”MVP为例，请避免写出这样的代码：

class PersonsPresenter extends Presenter<PersonsView> {

  public void load(){
    getView().showLoading(true); // 展示一个 ProgressBar

    backend.loadPersons(new Callback(){
      public void onSuccess(List<Person> persons){
        getView().showPersons(persons); // 展示用户列表
      }

      public void onError(Throwable error){
        getView().showError(error); // 展示错误信息
      }
    });
  }
}

我们应该创建能够反映 状态 的Model，像这样：

class PersonsModel {
  // 在真实的项目中，需要定义为私有的
  // 并且我们需要通过getter和setter来访问它们
  final boolean loading;
  final List<Person> persons;
  final Throwable error;

  public(boolean loading, List<Person> persons, Throwable error){
    this.loading = loading;
    this.persons = persons;
    this.error = error;
  }
}

因此，Presenter层也应该像这样进行定义：

class PersonsPresenter extends Presenter<PersonsView> {

  public void load(){
    getView().render( new PersonsModel(true, null, null) ); // 展示一个 ProgressBar

    backend.loadPersons(new Callback(){
      public void onSuccess(List<Person> persons){
        getView().render( new PersonsModel(false, persons, null) );  // 展示用户列表
      }

      public void onError(Throwable error){
          getView().render( new PersonsModel(false, null, error) ); // 展示错误信息
      }
    });
  }
}

现在，仅需简单调用View层的render(personsModel)方法，Model就会被成功的渲染在屏幕上。在第一小节中我们同样探讨了 单项数据流 的重要性，同时您的业务逻辑应该驱动该Model。在正式将所有内容环环相扣连接之前，我们先简单了解一下MVI的核心思想。

Model-View-Intent (MVI)

该模式最初被 andrestaltz 在他写的JavaScript框架 cycle.js 中所提出; 从理论(还有数学)上讲，我们这样对Model-View-Intent的定义进行描述：

1.intent()

此函数接受来自用户的输入（即UI事件，比如点击事件）并将其转换为可传递给Model()函数的参数，该参数可能是一个简单的String对Model进行赋值，也可能像是Object这样复杂的数据结构。intent作为意图，标志着 我们试图对Model进行改变。

2.model()

model()函数将intent()函数的输出作为输入来操作Model，其函数输出是一个新的Model（状态发生了改变）。

不要对已存在的Model对象进行修改，我们需要的是不可变！对此，在上文中我们已经展示了一个计数器的具体案例，再次重申，不要修改已存在的Model！

根据intent所描述的变化，我们创建一个新的Model,请注意，Model()函数是唯一允许对Model进行创建的途径。然后这个新的Model作为该函数的输出——基本上model()函数调用我们App的业务逻辑（可以是交互、用例、Repository......您在App中使用的任何模式/术语）并作为结果提供新的Model对象。

3.view()

该方法获取model()函数返回的Model，并将其作为view()函数的输入，这之后通过某种方式将Model展示出来，view()和view.render(model)大体上是一致的。

4.本质

但是我们希望构建的是 响应式的App，不是吗？那么MVI是如何响应式的呢？响应式实际上意味着什么？

这意味着App的 UI反映了状态的变更。

因为Model反映了状态，因此，本质上我们希望 业务逻辑能够对输入的事件（即intents）进行响应，并创建对应的Model作为输出，这之后再通过调用View层的render(model)方法，对UI进行渲染。

5.通过RxJava串联

我们希望我们的数据流的单向性，因此RxJava闪亮登场。我们的App必须通过RxJava保持 数据的单向性 和 响应式 来构建吗？或者必须用MVI模式才能构建吗？当然不，我们也可以写 命令式 和 程序性 的代码。但是，基于事件编程 的RxJava实在太优秀了，既然UI是基于事件的，因此使用RxJava也是非常有意义的。

本文我们将会构建一个简单的虚拟在线商店App，其UI界面中展示的商品数据，都来源于我们向后台进行的网络请求。

我们可以精确的搜索特定的商品，并将其添加到我们的购物车中，最终App的效果如下所示：

这个项目的源码你可以在Github上找到，我们从实现一个简单的搜索界面开始做起：

首先，就像上文我们描述的那样，我们定义一个Model用于描述View层是如何被展示的—— 这个系列中，我们将用带有 ViewState 后缀的类来替代 Model；举个例子，我们将会为搜索页的Model类命名为SearchViewState。

这很好理解，因为Model反应的就是状态（State），至于为什么不用听起来有些奇怪的名称比如SearchModel，是因为担心和MVVM中的SearchViewModel类在一起会导致歧义——命名真的很难。

public interface SearchViewState {

  // 搜索尚未开始
  final class SearchNotStartedYet implements SearchViewState {
  }

  // 搜索中
  final class Loading implements SearchViewState {
  }

  // 返回结果为空
  final class EmptyResult implements SearchViewState {
    private final String searchQueryText;

    public EmptyResult(String searchQueryText) {
      this.searchQueryText = searchQueryText;
    }

    public String getSearchQueryText() {
      return searchQueryText;
    }
  }

  // 有效的搜索结果，包含和搜索条件匹配的商品列表
  final class SearchResult implements SearchViewState {
    private final String searchQueryText;
    private final List<Product> result;

    public SearchResult(String searchQueryText, List<Product> result) {
      this.searchQueryText = searchQueryText;
      this.result = result;
    }

    public String getSearchQueryText() {
      return searchQueryText;
    }

    public List<Product> getResult() {
      return result;
    }
  }

  // 表示搜索过程中发生了错误
  final class Error implements SearchViewState {
    private final String searchQueryText;
    private final Throwable error;

    public Error(String searchQueryText, Throwable error) {
      this.searchQueryText = searchQueryText;
      this.error = error;
    }

    public String getSearchQueryText() {
      return searchQueryText;
    }

    public Throwable getError() {
      return error;
    }
  }
}

因为Java是一种强类型的语言，因此我们可以选择一种安全的方式为我们的Model类拆分出多个不同的 子状态。

我们的业务逻辑返回的是一个 SearchViewState 类型的对象，它可能是SearchViewState.Error或者其它的一个实例。这只是我个人的偏好，们也可以通过不同的方式定义，例如：

class SearchViewState {
  Throwable error;  // 非空则意味着，出现了一个错误
  boolean loading;  // 值为true意味着正在加载中
  List<Product> result; // 非空意味着商品列表的结果
  boolean SearchNotStartedYet; // true意味着还未开始搜索
}

再次重申，如何定义Model纯属个人喜好，如果你用Kotlin作为编程语言，那么sealed classes是一个不错的选择。

将目光聚集回到业务代码，让我们通过 SearchInteractor 去执行搜索的功能，其输出就是我们之前说过的SearchViewState对象：

public class SearchInteractor {
  final SearchEngine searchEngine; // 执行网络请求

  public Observable<SearchViewState> search(String searchString) {
    // 如果是空的字符串，不进行搜索
    if (searchString.isEmpty()) {
      return Observable.just(new SearchViewState.SearchNotStartedYet());
    }

    // 搜索商品列表
    // 返回 Observable<List<Product>>
    return searchEngine.searchFor(searchString)
        .map(products -> {
          if (products.isEmpty()) {
            return new SearchViewState.EmptyResult(searchString);
          } else {
            return new SearchViewState.SearchResult(searchString, products);
          }
        })
        .startWith(new SearchViewState.Loading())
        .onErrorReturn(error -> new SearchViewState.Error(searchString, error));
  }
}

来看下SearchInteractor.search()的方法签名：我们将String类型的searchString作为 输入 的参数，以及Observable<SearchViewState>类型的 输出，这意味着我们期望随着时间的推移，可以在可观察的流上会有任意多个SearchViewState的实例被发射。

在我们正式开始查询搜索之前（即SearchEngine执行网络请求），我们通过startWith()操作符发射一个SearchViewState.Loading,这将会使得View在执行搜索时展示ProgressBar。

onErrorReturn()会捕获在执行搜索时抛出的所有异常，并且发射出一个SearchViewState.Error——在订阅这个Observable时，我们为什么不去使用onError()回调呢？

这是一个对RxJava认知的普遍误解，实际上，onError()的回调意味着 整个可观察的流进入了不可恢复的状态，因此可观察的流结束了，而在我们的案例中，类似“没有网络连接”的error并非不可恢复的error：这只是我们的Model所代表的另外一个状态。

此外，我们还有另外一个可以转换到的状态，即一旦网络连接可用，我们可以通过 SearchViewState.Loading 跳转到的 加载状态。

因此，我们建立了一个可观察的流，这是一个每当状态发生了改变，从业务逻辑层就会发射一个发生了改变的Model到View层的流。

我们不想在网络连接错误时终止这个可观察的流，因此，在error发生时，类似这种可以被处理为 状态 的error（而不是终止流的那种致命的错误），可以反应为Model，被可观察的流发射。

通常，在MVI中，Model的Observable永远不会被终止（即永远不会执行onComplete()或者onError()回调）。

总结一下，SearchInteractor(即业务逻辑)提供了一个可观察的流Observable<SearchViewState>，每当状态发生了变化，就会发射一个新的SearchViewState。

6.View层的职责

接下来我们来讨论一下View应该是什么样的，View层的职责是什么？显然View层应该对Model进行展示，我们已经认可View层应该有类似 render(model) 这样的函数。此外，View应该提供一个给其他层响应用户输入的方法，在MVI中这个方法被称为 intents。

在这个案例中，我们只有一个intent:用户可以在输入框中输入一个用于检索商品的字符串进行搜索。MVP中的好习惯是为View层定义一个接口，所以在MVI中我们也可以这样做。

public interface SearchView {

  // 搜索的intent
  Observable<String> searchIntent();

  // 对View层进行渲染
  void render(SearchViewState viewState);
}

我们的案例中View层只提供了一个intent,但通常View拥有更多的intent;在 第一小节 中我们讨论了为什么一个单独的render()函数是一个不错的实践，如果你对此还不是很清楚的话，请阅读该小节并通过留言进行探讨。

在我们开始对View层进行具体的实现之前，我们先看看最终界面的展示效果：

public class SearchFragment extends Fragment implements SearchView {

  @BindView(R.id.searchView) android.widget.SearchView searchView;
  @BindView(R.id.container) ViewGroup container;
  @BindView(R.id.loadingView) View loadingView;
  @BindView(R.id.errorView) TextView errorView;
  @BindView(R.id.recyclerView) RecyclerView recyclerView;
  @BindView(R.id.emptyView) View emptyView;
  private SearchAdapter adapter;

  @Override public Observable<String> searchIntent() {
    return RxSearchView.queryTextChanges(searchView) // 感谢 Jake Wharton :)
        .filter(queryString -> queryString.length() > 3 || queryString.length() == 0)
        .debounce(500, TimeUnit.MILLISECONDS);
  }

  @Override public void render(SearchViewState viewState) {
    if (viewState instanceof SearchViewState.SearchNotStartedYet) {
      renderSearchNotStarted();
    } else if (viewState instanceof SearchViewState.Loading) {
      renderLoading();
    } else if (viewState instanceof SearchViewState.SearchResult) {
      renderResult(((SearchViewState.SearchResult) viewState).getResult());
    } else if (viewState instanceof SearchViewState.EmptyResult) {
      renderEmptyResult();
    } else if (viewState instanceof SearchViewState.Error) {
      renderError();
    } else {
      throw new IllegalArgumentException("Don't know how to render viewState " + viewState);
    }
  }

  private void renderResult(List<Product> result) {
    TransitionManager.beginDelayedTransition(container);
    recyclerView.setVisibility(View.VISIBLE);
    loadingView.setVisibility(View.GONE);
    emptyView.setVisibility(View.GONE);
    errorView.setVisibility(View.GONE);
    adapter.setProducts(result);
    adapter.notifyDataSetChanged();
  }

  private void renderSearchNotStarted() {
    TransitionManager.beginDelayedTransition(container);
    recyclerView.setVisibility(View.GONE);
    loadingView.setVisibility(View.GONE);
    errorView.setVisibility(View.GONE);
    emptyView.setVisibility(View.GONE);
  }

  private void renderLoading() {
    TransitionManager.beginDelayedTransition(container);
    recyclerView.setVisibility(View.GONE);
    loadingView.setVisibility(View.VISIBLE);
    errorView.setVisibility(View.GONE);
    emptyView.setVisibility(View.GONE);
  }

  private void renderError() {
    TransitionManager.beginDelayedTransition(container);
    recyclerView.setVisibility(View.GONE);
    loadingView.setVisibility(View.GONE);
    errorView.setVisibility(View.VISIBLE);
    emptyView.setVisibility(View.GONE);
  }

  private void renderEmptyResult() {
    TransitionManager.beginDelayedTransition(container);
    recyclerView.setVisibility(View.GONE);
    loadingView.setVisibility(View.GONE);
    errorView.setVisibility(View.GONE);
    emptyView.setVisibility(View.VISIBLE);
  }
}

render(SearchViewState)方法的作用显而易见，searchIntent()方法中，我们使用了Jake Wharton的 RxBinding ，这是一个对Android UI组件提供了RxJava响应式支持的库。

RxSearchView.queryText()创建了一个Observable<String>,每当用户在EditText上输入了一些文字，它就会发射一个对应的字符串；我们通过filter()去保证只有当用户输入的字符数达到三个以上时才进行搜索；同时，我们不希望每当用户输入一个字符，就去请求网络，而是当用户输入结束后再去请求网络（debounce()操作符会停留500毫秒以决定用户是否输入完成）。

现在我们知道了屏幕中的searchIntent()方法就是 输入 ，而render()方法则是 输出。我们如何从 输入 获得 输出 呢，如下所示：

7.连接View和Intent

剩下的问题就是：我们如何将View的intent和业务逻辑进行连接呢？如果你认真观看了上面的流程图，你应该注意到了中间的 flatMap() 操作符，这暗示了我们还有一个尚未谈及的组件： Presenter ;Presenter负责连接这些点，就和我们在MVP中使用的方式一样。

public class SearchPresenter extends MviBasePresenter<SearchView, SearchViewState> {
  private final SearchInteractor searchInteractor;

  @Override protected void bindIntents() {
    Observable<SearchViewState> search =
        intent(SearchView::searchIntent)
        // 上文中我们谈到了flatMap,但在这里switchMap更为适用
            .switchMap(searchInteractor::search)
            .observeOn(AndroidSchedulers.mainThread());

    subscribeViewState(search, SearchView::render);
  }
}

什么是 MviBasePresenter, intent() 和 subscribeViewState() 又是什么？这个类是我写的 Mosby 库的一部分（3.0版本后，Mosby已经支持了MVI）。本文并非为了讲述Mosby，但我向简单介绍一下MviBasePresenter是如何的便利——这其中没有什么黑魔法，虽然确实看起来像是那样。

让我们从生命周期开始：MviBasePresenter并未持有任何生命周期，它暴露出一个 bindIntent() 方法以供View层和业务逻辑进行绑定。通常，你通过flatMap()、switchMap()或者concatMap()操作符将intent “转移”到业务逻辑中，这个方法仅仅在View层第一次被附加到Presenter中时调用，而当View再次被附加在Presenter中时（比如，屏幕方向发生了改变），将不再被调用。

这听起来有些怪，也许有人会说：

MviBasePresenter在屏幕方向发生了改变后依然能够存活？如果是这样，Mosby如何保证Observable的流不会发生内存的泄漏？

这就是 intent() 和 subscribeViewState() 的作用所在了，intent() 在内部创建一个PublishSubject，就像是业务逻辑的“网关”一样；实际上,PublishSubject订阅了View层传过来的intent的Observable,调用intent(o1)实际返回了一个订阅了o1的PublishSubject。

屏幕发生旋转时，Mosby将View从Presenter中分离，但是，内部的PublishSubject只是暂时和View解除了订阅；而当View重新附着在Presenter上时，PublishSubject将会对View层的intent进行重新订阅。

subscribeViewState()方法做的是同样的事情，只不过将顺序调换了过来（Presenter向View层的通信）。它在内部创建一个BehaviorSubject作为从业务逻辑到View层的“网关”。

由于它是一个BehaviorSubject，因此，即使此时Presenter没有持有View，我们依然可以从业务逻辑中接收到Model的更新（比如View并未处于栈顶）；BehaviorSubjects始终持有它最后的值，并在View重新依附后将其重新发射。

规则很简单：使用intent()来“包装”View层的所有intent,使用subscribeViewState()替代Observable.subscribe().

8.UnbindIntents

与bindIntent()相对应的是 unbindIntents() ,该方法只会执行一次，即View被永久销毁时才会被调用。举个例子，将一个Fragment放在栈中，直到Activity被销毁之前，该View一直不会被销毁。

由于intent()和subscribeViewState()已经对订阅进行了管理，因此您只需要实现unbindIntents()。

9.其它生命周期的事件

那么其它生命周期的事件，比如onPause()和onResume()又该如何处理？我依然认为Presenter不需要生命周期的事件，然而，如果你坚持认为你需要将这些生命周期的事件视为另一种形式的intent，您的View可以提供一个pauseIntent()，它是由android生命周期触发，而又不是按钮点击事件这样的由用户交互触发的intent——但两者都是有效的意图。

结语

第二小节中，我们探讨了Model-View-Intent的基础，并通过MVI浅尝辄止实现了一个简单的页面。也许这个例子太简单了，所以你尚未感受到MVI模式的优点：代表 状态 的Model和与传统MVP或者MVVM相比的 单项数据流。

MVP和MVVM并没有什么问题，我也并非是在说MVI比其它架构模式更优秀，但是，我认为MVI可以帮助我们 为复杂的问题编写优雅的代码 ，这也正如我们将在本系列博客的 下一小节（第3小节）中探讨的那样——届时我们将针对 状态折叠器 （state reducers）的问题进行探讨，欢迎关注。

---

系列目录

《使用MVI打造响应式APP》原文

• Part 1: Model
  
• Part 2: View and Intent
• Part 3: State Reducer
• Part 4: Independent UI Components
  
• Part 5: Debugging with ease
  
• Part 6: Restoring State
  
• Part 7: Timing (SingleLiveEvent problem)
  
• Part 8: In-App Navigation
  

《使用MVI打造响应式APP》译文

• [译]使用MVI打造响应式APP(一):Model到底是什么
• [译]使用MVI打造响应式APP[二]:View层和Intent层
• [译]使用MVI打造响应式APP[三]:状态折叠器
• [译]使用MVI打造响应式APP[四]:独立性UI组件
• [译]使用MVI打造响应式APP[五]:轻而易举地Debug
• [译]使用MVI打造响应式APP[六]:恢复状态
• [译]使用MVI打造响应式APP[七]:掌握时机(SingleLiveEvent问题)
• [译]使用MVI打造响应式APP[八]:导航

《使用MVI打造响应式APP》实战

• 实战：使用MVI打造响应式&函数式的Github客户端

---

关于我

Hello，我是却把清梅嗅，如果您觉得文章对您有价值，欢迎 ❤️，也欢迎关注我的博客或者Github。

如果您觉得文章还差了那么点东西，也请通过关注督促我写出更好的文章——万一哪天我进步了呢？

• 我的Android学习体系
• 关于文章纠错
• 关于知识付费