多个活动/片段和模型视图控制器模式

Question

首先，我知道使用MVP模式有不同的实现方式，但在我的脑海中，只要你清楚地定义了抽象层并让它们扮演指定的角色，那么如何实现此模式就是开放的。我一直在多个应用程序中实施此模式，其中只有一个Activity。现在，我开始了一个新项目，其中包括多个Activity和附加的Fragments，包括嵌套的Fragments（ViewPager）。

我现在正在尝试将MVP转换为此项目，并遇到了概念上的障碍，希望得到一些指导和见解。

到目前为止，我已经创建了上述结构，并开始进行视图和Presenter之间1:1的关系（无论是Activity还是Fragment）。我认为这是可以的，但是例如，如果我从Activity View发送请求执行某些操作并返回结果给Activity View的Presenter，那么我该如何传播结果，即更新当前处于未暂停或停止状态的所有其他Activities/Fragments？在这种情况下，我觉得应该有一个中央Presenter来更新所有必要的Activity和Fragment Views，但是我不确定如何去做。

目前，每当创建每个Activity和Fragment时，它都会创建一个Presenter类的新实例，将自身作为引用传递（Activity和Fragments各自实现其自己的接口），Presenter将其存储为WeakReference，并在返回结果时调用相关接口方法。

根据文档，每当Fragments想要相互通信并与附加的Activity通信时，应使用回调接口。考虑到这一点，我是否应该有一个回调接口，由Activity实现并在Fragments请求某些内容时回调，因此本质上只有Activity需要一个Presenter和Model层，Fragments必须通过回调才能请求各种内容？

如果我的描述有点混乱，请见谅，希望这足够清楚，以便理解我想要实现什么，以及我是否在正确地思考...或者完全偏离了轨道！

- Mark

Answer 1

我认为在活动中放置一个演示者是可以的。基本上，活动就像一个控制器，它应该知道演示者。

如果活动或其他片段也需要演示者，把演示者放在片段里就是错误的。只有当这个演示者专门为片段设计时，才可以将演示者放在片段内。

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

为什么你需要在这里使用 WeakReference？如果你有1:1的关系，那么我认为你的演示者没有自己的生命周期，这意味着它的生命周期取决于活动或片段。因为它不是单例，所以没有内存泄漏的风险，对吧？它应该是安全的，使用强引用。

我不确定我是否回答了你的问题，因为对我来说看起来有点广泛。我的观点是，片段只是活动的分离“部分”，你应该把它们视为部分。如果演示者属于这个部分，那么它应该在内部。否则，它应该在活动中。你关于使用 interface 访问活动是正确的，这是谷歌在他们的例子中使用的一个著名的设计方法。

- Gennadii Saprykin

---

感谢您的评论和想法。我想我会使用Presenter与Activity一起使用，并让它处理更新片段。单例模式会出现内存泄漏吗？只有当单例模式引用了一个Activity或Fragment（基本上是具有可能出现的生命周期的东西）时才会发生这种情况？如果是这样，我确实在其他地方使用单例模式，但它没有保留任何引用。我对具有生命周期回调的Activity和Fragment（任何具有生命周期回调的东西）使用WeakReferences，因为我不必在配置更改时将Strong references设置为null，而且WeakReference允许GC。 - Mark

如果您的Presenter不是单例模式，那么在配置更改时就不应该有任何问题，因为Presenter本身也会被重新创建。但是，如果您使用了保留的Fragment，则可能需要使用WeakReference。无论如何，看起来您很清楚地理解了弱引用的工作原理，所以我不需要再解释了。谢谢。 - Gennadii Saprykin

不，Presenter 不是一个 Singleton。创建 Presenter 后，我会将其引用存储在一个 HashMap<String, Object> 中的 headless retained fragment 中，并在 Activity 的配置更改时重新获取其引用。... 当我认为自己已经理解 Java 中的某些内容时，它似乎总是给我带来一些曲折！感谢你的建议。 - Mark

Answer 2

不，不再使用界面。你可以使用 RxJava Observables 来更新所有视图，如此处所述 here 或某种类型的 Bus（Otto-已弃用或EventBus）。它们使交互变得更加容易，你会喜欢它们的。

- Jemshit Iskenderov

---

感谢您的评论，我已经简要地查看了这些内容 - 看起来相当可行和有趣。我正在寻找一种模式解决方案或概念，而不是“这个库可以消除复杂性”。我并不反对使用这个或任何其他解决问题的库，远非如此，但我认为在直接使用这些处理许多复杂性的其他库之前，理解良好的理解非常重要。 - Mark

我会称之为反应式编程方法，而不是库。我认为在不久的将来，我看不到其他逃避 Rx 的方式了。 - Jemshit Iskenderov

我肯定会研究响应式编程/RxJava，但就目前而言，对于我和这个项目来说，通过托管活动进行通信并不是问题。我不确定我是否认同您的观点，即没有逃脱响应式编程的方法，但我尊重您的意见。 - Mark