RxAndroid 来管理应用状态（5）

上一次分享我们引入 RxAndroid 将代码进行重构，看上去似乎合情合理不过还存在许多问题。今天我们用更直观的图形来走一遍流程。

当用户点击提交按钮，出发 click 事件，从而启动 RxAndroid 的事件流。

触发事件就立即返回到 UI 在 doOnNext 方法中禁用提交按钮并且显示加载指示器，这是我们通常做法。这也是就是所谓副作用，这一个动作给我们这次点击提交事件流并没有什么关系。

然后我们又去 UI 中读取 EditText 中的数据，这一步是不合理的，也不便于测试。从我们整个事件流来看，他似乎格格不入，妈妈让小明买酱油，买酱油钱必须小明在去的路上回去取。应该是妈妈给钱让小明买酱油。

接下来就是用 flatmap 获取数据去服务器提交数据，

然后在 doOnNext 中隐藏加载器指示器，这是一个 bug，因为这一步其实只在成功后才会被调用。最后我们在成功或失败中更新界面，提示用户。

这只是一个简单的请求，想必我们的产品没有这么简单。如果是多个请求我们只需要复制一份就可以了。这样问题就是发起多个请求同时操作一个 UI 例如加载指示器，就可能造成 UI 竞争。

我们来尝试化简整个 RxAndroid 流，去掉副作用和一些不合理的动作。

触发事件我们事件就回流到 UI 操作提交按钮和加载指示器。

在提交成功后，事件又就流到 UI 操作提交按钮和加载指示器。

这两个非主流的动作是我们想要去掉的。

还就是这次开小差回去拽数据动作也是我们在下一次优化的重点。

我们解决方案是通过 SubmitEvent 对象将我们数据和点击事件包装在一起。这样就可以消除两次操作加载器副作用的动作

我们可以通过 Ul model 来实现与 UI 打交道。

这样我们就将 Rxandroid 流化简的为单向，没有回流了。这样就是我们的理想效果。

下次分享代码。