Android 上的嵌套 MVP：如何
Nested MVP on Android: how to
我正在开发一个由 3 个主要部分组成的 Android 测试项目，每个部分都遵循 MVP 模式 开发。
这些部分相互 嵌套 ，我想知道我遵循的策略是 correct/best 还是
结构：
- Book: 包含不同页面的 ViewPager
- Page: 包含多个 Items 的自定义 LinearLayout
- 项目：自定义视图（在这个例子中是一个简单的按钮）
每个部分都使用一个 MVP 结构（例如，对于 Book，我制作了 BookPresenter、BookView 和 BookModel，对于 Page 和 Item 也是如此）
作为一个用户案例，我想跟踪用户点击按钮的次数以及每次将页面背景更改为随机颜色，以及何时用户点击第 10 次告诉 BookPresenter 转到第二页。
为此我设置了一些东西
- BookView 创建 BookPresenter，BookPresenter 又创建每个 PageView。
- 每个 PageView 创建 PagePresenter，后者又创建 ItemView（最终创建 ItemPresenter）
在这一切中，BookPresenter 引用了 PagePresenter，PagePresenter 引用了 ItemPresenter，因此当需要执行某些操作时，它们可以与结构中的子或父演示者进行通信
现在问题：
这是设置具有嵌套 MVP 的系统的正确方法吗？
因为如果我想拥有一个 PageView 但不是在一本书中，我需要将它放在报纸中（其他 class 具有一些替代行为的书）我仍然需要重新创建与演示者的整个依赖链以及所有其他...
“Child-Presenter”如何与“Parent-Presenter”沟通？他们不（直接，不通过 EventBus）
从我的角度来看，这种父子关系是代码味道，因为它们在父子之间引入了直接耦合，这导致代码难以阅读、难以维护，更改需求影响很大组件（因此在大型系统中这几乎是不可能的任务），最后但并非最不重要的是引入了难以预测甚至更难重现和调试的共享状态。
到目前为止一切顺利，但信息必须以某种方式从演示者 A 流向演示者 B：演示者如何与另一个演示者通信？他们没有！一个 Presenter 必须告诉另一个 Presenter 什么？事件 X 发生了吗？演示者不必相互交谈，他们只是观察相同的模型（或者准确地说是业务逻辑的相同部分）。这就是他们获得有关更改的通知的方式：从底层。
每当事件 X 发生时（即用户单击视图 1 中的按钮），Presenter 都会让该信息下沉到业务逻辑。由于其他 Presenter 正在观察相同的业务逻辑，因此业务逻辑会通知他们发生了一些变化（模型已更新）。
来源：http://hannesdorfmann.com/android/mosby3-mvi-4
因此，让我们将其应用到您的示例中。
你应该有类似 Readable 的东西（如果你想对 Book implements Readable 和 NewsPaper implements Readable 进行抽象）。使用 Readable.getPageCount() 可以得到 ViewPager 的页数。使用 Readable.getCurrentPage() 可以得到当前的 Page。然后，您需要某种观察者模式，以便在页面更改时得到通知。当用户单击 ItemView 中的按钮时，您还需要一个 Listener / Observer 模式。这样的点击将是上图中的事件 X。单击按钮后，信息将通过 Presenter 向下流动到更改 Readable 对象的业务逻辑。然后，此更改将通知此 Readable 对象的观察者，例如 PagePresenter，然后更新 PageView 以设置页面的背景颜色。
所以关键是：通过业务逻辑进行通信，而不是一些视图到视图或演示者到演示者的通信。
希望对您有所帮助。
我正在开发一个由 3 个主要部分组成的 Android 测试项目，每个部分都遵循 MVP 模式 开发。 这些部分相互 嵌套 ，我想知道我遵循的策略是 correct/best 还是
结构：
- Book: 包含不同页面的 ViewPager
- Page: 包含多个 Items 的自定义 LinearLayout
- 项目：自定义视图（在这个例子中是一个简单的按钮）
每个部分都使用一个 MVP 结构（例如，对于 Book，我制作了 BookPresenter、BookView 和 BookModel，对于 Page 和 Item 也是如此）
作为一个用户案例，我想跟踪用户点击按钮的次数以及每次将页面背景更改为随机颜色，以及何时用户点击第 10 次告诉 BookPresenter 转到第二页。
为此我设置了一些东西
- BookView 创建 BookPresenter，BookPresenter 又创建每个 PageView。
- 每个 PageView 创建 PagePresenter，后者又创建 ItemView（最终创建 ItemPresenter）
在这一切中，BookPresenter 引用了 PagePresenter，PagePresenter 引用了 ItemPresenter，因此当需要执行某些操作时，它们可以与结构中的子或父演示者进行通信
现在问题： 这是设置具有嵌套 MVP 的系统的正确方法吗？ 因为如果我想拥有一个 PageView 但不是在一本书中，我需要将它放在报纸中（其他 class 具有一些替代行为的书）我仍然需要重新创建与演示者的整个依赖链以及所有其他...
“Child-Presenter”如何与“Parent-Presenter”沟通？他们不（直接，不通过 EventBus）
从我的角度来看，这种父子关系是代码味道，因为它们在父子之间引入了直接耦合，这导致代码难以阅读、难以维护，更改需求影响很大组件（因此在大型系统中这几乎是不可能的任务），最后但并非最不重要的是引入了难以预测甚至更难重现和调试的共享状态。
到目前为止一切顺利，但信息必须以某种方式从演示者 A 流向演示者 B：演示者如何与另一个演示者通信？他们没有！一个 Presenter 必须告诉另一个 Presenter 什么？事件 X 发生了吗？演示者不必相互交谈，他们只是观察相同的模型（或者准确地说是业务逻辑的相同部分）。这就是他们获得有关更改的通知的方式：从底层。
每当事件 X 发生时（即用户单击视图 1 中的按钮），Presenter 都会让该信息下沉到业务逻辑。由于其他 Presenter 正在观察相同的业务逻辑，因此业务逻辑会通知他们发生了一些变化（模型已更新）。
来源：http://hannesdorfmann.com/android/mosby3-mvi-4
因此，让我们将其应用到您的示例中。
你应该有类似 Readable 的东西（如果你想对 Book implements Readable 和 NewsPaper implements Readable 进行抽象）。使用 Readable.getPageCount() 可以得到 ViewPager 的页数。使用 Readable.getCurrentPage() 可以得到当前的 Page。然后，您需要某种观察者模式，以便在页面更改时得到通知。当用户单击 ItemView 中的按钮时，您还需要一个 Listener / Observer 模式。这样的点击将是上图中的事件 X。单击按钮后，信息将通过 Presenter 向下流动到更改 Readable 对象的业务逻辑。然后，此更改将通知此 Readable 对象的观察者，例如 PagePresenter，然后更新 PageView 以设置页面的背景颜色。
所以关键是：通过业务逻辑进行通信，而不是一些视图到视图或演示者到演示者的通信。
希望对您有所帮助。