带有 Presenter 的 RxJava 和用于配置更改的保留片段
RxJava with Presenter and retained fragment for configuration changes
我是 RxJava 的新手，并且将其与 MVP 架构一起使用。
我找到了一些关于使用保留片段在配置更改时保存可观察对象的示例（仍然不确定这是否是最好的方法）。不过，我发现的示例是直接在 Activity 或 Fragment 上处理 observable，而不是来自 Presenter。
所以我试验并设置了这个 quick example（仅使用 Reactivex 的 RxJava 和 RxAndroid 库）只是为了测试，这似乎工作正常。这个例子所做的是：
- 使用无头保留片段启动 activity。
- 按钮
- Presenter 为延迟（5 秒）响应可观察调用 FakeService。
- Presenter 对此 observable 执行 .cache()。
- Presenter 告诉视图保留这个 observable。
- View 将 observable 保存在保留的片段中。
- Presenter 订阅了 observable。
- 用户进行了配置更改（设备轮换）。用户可以根据需要多次执行此操作。
- OnPause 通知 Presenter 的 CompositeSubscription 清除并取消订阅所有当前订阅。
- Activity 被重新创建并重新使用现有的保留片段。
- Activity 的 onResume 检查保留片段的存储 observable 是否为空。
- 如果不为空，则告诉 Presenter 订阅它。
- 保留的 observable 已被订阅，并且由于调用了 .cache，它只是将结果重播给新订阅者而无需再次调用该服务。
- 当 Presenter 向视图显示最终结果时，它还会将保留片段的已保存可观察对象设置为 null。
我想知道我这样做是否正确，以及当在 Presenter 中处理可观察对象的订阅时，是否有更有效或更优雅的方式来处理配置更改？
编辑：
感谢您的反馈。
基于此，我得出了我认为更简洁的解决方案，并且我已经用这些更改更新了我的链接示例。
有了新的变化；我没有将 Observable 从 Presenter 传递到 Activity 再到要存储的 retainedFragment，而是在创建 Presenter 时将 retainedFragment 设置为第二个 "view"。
这样当 onResume() 在设备旋转后发生时，我不需要让 Activity 执行将 Observable 从 retainedFragment 传回 Presenter 的丑陋管道。
Presenter 可以直接与第二个 "view" 交互并检查保留的 observable 本身并在需要时重新订阅。 main Activity 不再需要知道这个 observable。突然间它是一个简单得多的视图层。
听起来不错，干得好！一些建议：
- 您可以直接使用
Activity.onRetainNonConfigurationInstance()。我听说它在 Android N 中不再被弃用。如果您愿意，可以继续使用保留的片段，这没有问题，但如果您不想使用片段，则不必这样做。
- 为什么只保留observable而不保留整个presenter？创建一个新的演示者似乎有点浪费，也许你可以让它与可以 "attach" 和 "detach" 视图的相同实例一起工作。但是话又说回来，如果你的 observable 在你脱离任何视图时发射，你必须处理该怎么做，所以也许这就足够了。
- Dan Lew 最近提出了一个案例 in his Droidcond SF talk，您不应该使用
cache()。他说 replay() 可以让你更好地控制正在发生的事情，而 replay().autoconnect() 的工作原理与 cache() 相同。他说服了我，但你自己看看。
看起来不错，你可以看看那个例子 - https://github.com/krpiotrek/RetainFragmentSample
此库 https://github.com/MaksTuev/ferro 包含另一种存储屏幕数据和管理后台任务的方法。
你的场景看起来像这样
打开Activity，创建演示者
推送按钮
Presenter 为延迟（5 秒）响应可观察调用 FakeService。
配置已更改，presenter 未被销毁，Observable 未取消订阅，所有 rx 事件已冻结
Activity 重新创建，重用演示器，演示器在视图上显示以前加载的数据，所有 rx 事件都已解冻
我认为这有帮助
我是 RxJava 的新手，并且将其与 MVP 架构一起使用。
我找到了一些关于使用保留片段在配置更改时保存可观察对象的示例（仍然不确定这是否是最好的方法）。不过，我发现的示例是直接在 Activity 或 Fragment 上处理 observable，而不是来自 Presenter。
所以我试验并设置了这个 quick example（仅使用 Reactivex 的 RxJava 和 RxAndroid 库）只是为了测试，这似乎工作正常。这个例子所做的是：
- 使用无头保留片段启动 activity。
- 按钮
- Presenter 为延迟（5 秒）响应可观察调用 FakeService。
- Presenter 对此 observable 执行 .cache()。
- Presenter 告诉视图保留这个 observable。
- View 将 observable 保存在保留的片段中。
- Presenter 订阅了 observable。
- 用户进行了配置更改（设备轮换）。用户可以根据需要多次执行此操作。
- OnPause 通知 Presenter 的 CompositeSubscription 清除并取消订阅所有当前订阅。
- Activity 被重新创建并重新使用现有的保留片段。
- Activity 的 onResume 检查保留片段的存储 observable 是否为空。
- 如果不为空，则告诉 Presenter 订阅它。
- 保留的 observable 已被订阅，并且由于调用了 .cache，它只是将结果重播给新订阅者而无需再次调用该服务。
- 当 Presenter 向视图显示最终结果时，它还会将保留片段的已保存可观察对象设置为 null。
我想知道我这样做是否正确，以及当在 Presenter 中处理可观察对象的订阅时，是否有更有效或更优雅的方式来处理配置更改？
编辑： 感谢您的反馈。 基于此，我得出了我认为更简洁的解决方案，并且我已经用这些更改更新了我的链接示例。
有了新的变化；我没有将 Observable 从 Presenter 传递到 Activity 再到要存储的 retainedFragment，而是在创建 Presenter 时将 retainedFragment 设置为第二个 "view"。
这样当 onResume() 在设备旋转后发生时，我不需要让 Activity 执行将 Observable 从 retainedFragment 传回 Presenter 的丑陋管道。
Presenter 可以直接与第二个 "view" 交互并检查保留的 observable 本身并在需要时重新订阅。 main Activity 不再需要知道这个 observable。突然间它是一个简单得多的视图层。
听起来不错，干得好！一些建议：
- 您可以直接使用
Activity.onRetainNonConfigurationInstance()。我听说它在 Android N 中不再被弃用。如果您愿意，可以继续使用保留的片段，这没有问题，但如果您不想使用片段，则不必这样做。 - 为什么只保留observable而不保留整个presenter？创建一个新的演示者似乎有点浪费，也许你可以让它与可以 "attach" 和 "detach" 视图的相同实例一起工作。但是话又说回来，如果你的 observable 在你脱离任何视图时发射，你必须处理该怎么做，所以也许这就足够了。
- Dan Lew 最近提出了一个案例 in his Droidcond SF talk，您不应该使用
cache()。他说replay()可以让你更好地控制正在发生的事情，而replay().autoconnect()的工作原理与cache()相同。他说服了我，但你自己看看。
看起来不错，你可以看看那个例子 - https://github.com/krpiotrek/RetainFragmentSample
此库 https://github.com/MaksTuev/ferro 包含另一种存储屏幕数据和管理后台任务的方法。
你的场景看起来像这样
打开Activity，创建演示者
推送按钮
Presenter 为延迟（5 秒）响应可观察调用 FakeService。
配置已更改，presenter 未被销毁，Observable 未取消订阅，所有 rx 事件已冻结
Activity 重新创建，重用演示器，演示器在视图上显示以前加载的数据，所有 rx 事件都已解冻
我认为这有帮助