我发现了一些关于使用保留片段在配置更改时保存observable的示例(仍然不确定这是否是最好的方法).我发现的例子是直接在Activity或Fragment上处理observable,而不是从Presenter处理.
所以我试验并设置了这个quick example(仅使用Reactivex的RxJava和RxAndroid lib)来测试,这似乎工作正常.这个例子的作用是：
>使用无头保留片段启动活动.
>按钮
> Presenter调用FakeService以获得延迟(5秒)响应的可观察性.
> Presenter对此可观察对象执行.cache().
> Presenter告诉视图保留此可观察性.
> View将observable保存在保留的片段中.
> Presenter订阅了observable.
>用户进行配置更改(设备轮换).用户可以根据需要多次执行此操作.
> OnPause告诉Presenter的CompositeSubscription清除和取消订阅所有当前订阅.
>重新创建活动并重用现有的保留片段.
> Activity的onResume检查保留的片段的存储的observable是否为null.
>如果不为null,则告诉Presenter订阅它.
>保留的observable被订阅,并且因为.cache被调用,它只是将结果重放给新订阅者而不再次调用该服务.
>当Presenter向视图显示最终结果时,它还将保留的片段的已保存observable设置为null.
我想知道我是否正确地执行此操作,并且当在Presenter中处理observable的订阅时,是否有更高效或更优雅的方式来处理配置更改？
编辑：
感谢您的反馈.
基于此,我已经达到了我认为更清洁的解决方案,并且我已经更新了我的链接示例.
随着新的变化;而不是将Observable从Presenter传递给Activity到retainFragment以存储一个configurationChange事件,我宁愿将retainFragment设置为Presenter创建时的第二个“视图”.
这种方式当onResume()在设备旋转后发生时,我不需要让Activity执行将Observable从retainFragment传递回Presenter的丑陋管道.
Presenter可以直接与第二个“视图”进行交互,并检查保留的observable本身,并在需要时重新订阅.主要活动不再需要知道这个可观察的.突然间,这是一个更简单的视图层.
解决方法
>您可以使用Activity.onRetainNonConfigurationInstance().我听说它在Android N中没有被弃用.你可以继续使用保留的片段,如果你喜欢它,没有问题,但如果你不喜欢不使用片段你也不必.
>为什么只保留可观察的而不是整个演示者？创建一个新的演示者似乎有点浪费,也许你可以让它与可以“附加”和“分离”视图的同一个实例一起工作.但是,如果你的观察结果与任何观点脱节,你必须要处理如何处理,所以也许这已经足够了.
> Dan Lew最近提出了一个案例in his Droidcond SF talk,你不应该使用cache().他说,replay()可以让你更好地控制正在发生的事情和重放().autoconnect()与cache()的工作方式相同.他说服了我,但要亲自看看.
