RxAndroid 来管理应用状态(5)

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

《RxAndroid 来管理应用状态(5)》

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

《RxAndroid 来管理应用状态(5)》

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

《RxAndroid 来管理应用状态(5)》

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

《RxAndroid 来管理应用状态(5)》

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

《RxAndroid 来管理应用状态(5)》

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

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

《RxAndroid 来管理应用状态(5)》

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

《RxAndroid 来管理应用状态(5)》

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

《RxAndroid 来管理应用状态(5)》

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

《RxAndroid 来管理应用状态(5)》

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

《RxAndroid 来管理应用状态(5)》
《RxAndroid 来管理应用状态(5)》

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

《RxAndroid 来管理应用状态(5)》

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

《RxAndroid 来管理应用状态(5)》
《RxAndroid 来管理应用状态(5)》
《RxAndroid 来管理应用状态(5)》

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

《RxAndroid 来管理应用状态(5)》

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

《RxAndroid 来管理应用状态(5)》

下次分享代码。

    原文作者:zidea
    原文地址: https://www.jianshu.com/p/57d4504c69c0
    本文转自网络文章,转载此文章仅为分享知识,如有侵权,请联系博主进行删除。
点赞