多个活动/片段和模型视图演示者模式

Question

首先，我知道使用Model View Presenter有不同的实现，在我看来，只要你清楚地定义了抽象层并完成了他们指定的角色，那么你如何实现这个模式就可以解释了。我在很多只有一个Activity的应用程序中实现了这种模式。我现在开始了一个包含多个活动并附加Fragments的新项目，包括嵌套片段（ViewPager）。

我现在正试图将MVP翻译成这个项目，并且我已经打了一个概念墙，想要一些指导和见解。

到目前为止，我已经创建了上述结构并开始与View＆amp; 1建立1：1的关系。演示者（无论Activity还是Fragment）。我觉得这没关系，但是例如我发送了一个请求，要求从Activity视图到其Presenter做一些事情，它将结果返回到Activity查看我将如何传播结果即更新当前不在Paused()或Stop()状态的所有其他活动/片段。我觉得在这种情况下应该有一个中央Presenter更新所有必要的活动和片段视图，但我不知道该如何去做。

目前，当创建每个Activity和Fragment时，它会创建一个Presenter类的新实例，将其自身作为引用传递（活动和片段实现自己的接口），演示者存储作为WeakReference，可以在返回结果时调用相关的接口方法。

根据Fragments想要彼此通信的文档和附加的Activity，您应该使用回调接口。考虑到这一点，我应该有一个Activity实现的回调接口和Fragments回调它们何时请求什么，所以实质上只有Activity有一个Presenter和Model层，Fragments必须按顺序回调提出各种要求？

很抱歉，如果这听起来有点混乱，希望这足以清楚地了解我想要实现的目标，如果我正在思考正确的方向......或者完全不合适的话！

Answer 1

我认为在内部活动中有一个演示者是可以的。基本上活动就像一个控制器，它应该知道主持人。

如果活动或其他片段也需要将演示者放入片段中，那将是错误的。只有当此演示者专门为片段设计时，才能将演示者放入片段中。

  

，演示者将其存储为WeakReference，并在返回结果时调用相关的接口方法

为什么你需要WeakReference？如果你有1：1的关系，那么我认为你的演示者没有它自己的生命周期，这意味着它的生命周期取决于活动或片段。没有内存泄漏的风险，因为它不是单身人士，对吗？有一个强有力的参考应该是安全的。

我不确定我是否回答了你的问题，因为它看起来有点宽泛。我的观点是，片段只是分开了＃34;部分＆＃34;活动，你应该把它们当作零件。如果演示者只属于这个部分，那么它应该在里面。否则它应该是活动的。您使用interface访问活动是正确的，这是Google在其示例中使用的一种众所周知的设计方法。

Answer 2

不，没有界面了。您可以使用RxJava Observables更新所有视图here或某种Bus（Otto - 已弃用或EventBus）。而且你会喜欢它，因为它们使交互太容易了。