Question

将演示者的角色从活动中剥离出来会有什么好处？

为了剖析作为演示者的活动，可以分开哪些角色/关注点？

为什么要将它们分成两个不同的问题？

在什么情况下不统一它们是否有意义？

举例，优点或缺点。

Answer 1

我可以看到将演示者与活动分开的两个主要原因：可重用性和可测试性。

可重用性的真实用例：我们有一个插图实体，其中包含摄影师，版权和拍摄日期等属性，可以链接到文档。传说是关于文档和插图之间的关系。您可以在自己的屏幕上编辑插图和图例，但我们也希望可以从图例屏幕编辑插图。所以我们为插图画面做了一个演示者。插图活动是该演示者的一个非常薄的包装器，并且图例活动有点复杂，但重用了演示者和视图。活动的责任是提供RequestContext并执行fire()（保存/取消按钮位于其他活动上，类似于Google网上论坛上的操作）。

可重用性的假设用例：

对于不同的形式因素，您希望在同一屏幕上聚合内容或在自己的屏幕上将它们分开（例如主/细节），当您聚合它们时，进行两项活动可能并不理想。通过使用手机外形中的精简活动，您可以在平板电脑或桌面外形中的单个活动中重复使用组件（演示者/视图）。
在不同平台上重复使用相同的演示者：您可以在Android应用和网络应用上使用相同的演示者（甚至可能通过java2objc使用iOS应用），该视图将是原生Android视图或基于GWT的视图，导航将由Android活动和/或片段与GWT活动和场所处理。

关于可测试性（这是理论上的），您可以在没有活动生命周期麻烦的情况下测试您的演示者（模拟视图），然后单独测试生命周期（是否正确初始化和清理）升级演示者，获取/缓存数据等，模拟演示者。）

另请参阅 https://code.google.com/p/google-web-toolkit/source/detail?r=10185的提交消息 Ray的想法是让MVP成为小部件的实现细节，就像单元小部件今天使用内部演示者一样。从外面看，它们只是小部件，你可以按照你想要的方式构图;在内部，他们使用MVP，因此您可以在不需要GWTTestCase的情况下测试它们。

Answer 2

首先感谢两个问题，这些问题促使我进入有史以来最长的研究。：）

根据Thomos Broyer所说here。

活动无法与小工具交谈，主持人可以这样做。

两个主要关注领域：

1-将数据导入小部件：如何改进这种设计？

Server (RequestFactory) ---> Activity ---> WidgetPresenter ---> Widget

此处，RequestFactory将数据交给Activity，然后将其提供给Presenter widget 随后将其交给widgets。

2-从server获取数据到widget ---> WidgetPresenter ---> Activity ---> Server(RequestFactory)

{{1}}

GWT - 将演示者的角色与活动分开

2 个答案: