以下是一个示例方案:
我有一个活动(视图)和该视图的演示者。演示者从网络API中提取用户列表,并使用List对象将其保存在内存中。活动包含不同类型的片段,以根据User.type显示有关用户的内容。这两个片段(UserType1Fragment和UserType2Fragment)也有各自的演示者。
活动的演示者决定接下来显示片段的类型(I或II)。片段的演示者决定用户对象的显示方式,并处理名为killUser()的按钮单击事件。这应该更新活动的演示者中的List对象。
这就是问题所在:
片段如何呈现对活动演示者中的数据的引用?演示者不应直接相互沟通。也许我应该将List抽象到存储库/交互器中?如何在演示者之间分享名单?
答案 0 :(得分:22)
所以我最终实现了@Jahnold推荐的东西。 (我将在为想法stackoverflow.com/a/41966497/568898提供的链接中发布图表)
Hannes Dorfmann(创建/管理着名的Mosby MVP图书馆的人:Github link)也指出了我的方向。
<强>实施强>
我有一个主要活动的演示者和可以在该活动中使用的多个片段。每个片段都有自己的演示者。然后我使用存储库(搜索存储库模式),它基本上存储模型和业务逻辑。对于我的用例,我将此存储库保留为单例。存储库以三种形式提供数据,从在线api,sqllite数据库或存储在存储器中的缓存(基本上是项目的arraylist)。我在这个存储库中也有一些currentitem int索引和东西,它们会根据当前状态进行更新。
因此,数据,状态和业务逻辑存储在此共享存储库中。主持人和观点非常愚蠢。我在演示者中没有太多业务逻辑(特定于应用程序的逻辑)。它们只是具有与数据必须如何显示相关的逻辑(查看特定逻辑)和逻辑预处理。
示例强>
当用户单击子片段中的按钮时片段和活动需要彼此交谈(通过演示者),片段要求其演示者处理ClickClick,演示者更新存储库的currentItemSelected数据(或别的东西)并要求片段向活动实现的接口监听器发出一个事件(例如onbuttonclick)。当活动获得事件时,它会要求它自己的演示者处理它,然后活动演示者在存储库中查找更新以获取新的currentItemSelected。
额外信息(高级版):
您还可以关注Clean架构,它是MVP架构的更高级版本。 MVP只处理视图的体系结构,其中Clean体系结构也处理业务逻辑和数据体系结构,MVP只是用于处理视图的干净拱的一小部分。使用它,您可以将我的案例中的mega repo分解为处理特定业务逻辑用例的更多用例(或交互器),并且存储库只提供数据。所以逻辑流程现在是视图 - &gt; presenter - &gt; interactor - &gt; repo and back。
答案 1 :(得分:0)
您可以通过片段的newInstance()将列表引用传递给片段。我认为演示者不应该直接相互沟通。