8

Model-View-Presenter (MVP) 是一种众所周知的 GUI 应用程序设计模式。对于 Android,在纯 Java 模块中实现业务逻辑有助于测试,而无需 Android 模拟器。

但是,由于对 Android 应用程序的 GUI 有特殊要求,我很难在 Android 上实现该模式:

  • Activity 可能在任何时候被销毁(来电,用户按下主页按钮,...),并且在重新创建时它应该处于与离开时完全相同的状态。这与大多数其他 GUI 应用程序不同。

  • 一个 Activity 可以经历许多生命周期状态。它可能会暂停,在这种情况下不应修改 Activity 的 UI。例如,如果某些数据正在后台加载,如果它处于暂停状态,则无法将其传递到 MVP(Activity)的 View 部分。同样,这是一个不寻常的要求。

我已阅读博文MVP for Android并查看了示例源代码。我试图通过使用 MVP 模式实现的最终目标是能够使用转译器j2objc将所有业务逻辑转换为 Objective-C ,以便在 iOS 上实现相同的应用程序时可以重用业务逻辑。

有没有人成功地为 Android 实现了 MVP 模式,在这种情况下,我错过了什么?

4

2 回答 2

4

我建议在不涉及 Activity 的情况下实现 MVP 组件,也许从概念上考虑什么对 Android 和 GWT 都有用。使用带有模拟视图接口的测试驱动开发创建组件,添加测试直到业务逻辑完全实现和验证。TDD 有助于保持组件的 API 精简(为什么要为不需要的东西编写测试?),这使得组件的移植更容易。

您描述的 Activity 要求可以概括为与平台无关:组件应该是可序列化的(小's',而不是专门的 Java 序列化),并且需要接受生命周期状态事件。这些也可以使用系统功能的模拟进行全面测试。当您完成这一步时,您可能会注意到很少有 Activity 要求是特定于 Android 的,并且可能在其他平台上很有用。避免创建庞大的服务 API;例如,为了支持序列化,所需要的只是存储/加载方法,而不是Parcel API之类的东西。我发现在白板上向其他开发人员描述此类服务 API 是找到不必要的绒毛的好方法。

接下来,将组件移植到 Android,可能通过创建一个 Activity 委托给组件并为模拟接口提供 Android 特定的实现类。第一次应该全部“正常工作”,但实际上可能遗漏了一些要求,因此将它们添加到平台无关部分并重复。

当您准备好移植到 iOS 时,重新实现那些以前模拟的接口。如果这些接口是精简的,那么直接在 Objective-C 中创建它们可能会更容易,导入 j2objc 生成的协议头。例如,j2objc 的NSDictionaryMap类使用 NSDictionary 实现来实现 java.util.Map——无需编写和翻译 Java 版本,因为它只使用 iOS API。

于 2014-07-11T16:59:41.280 回答
1

我发现围绕 Android 构建的 MVP 变体是朝着隔离应用程序中业务逻辑的正确方向迈出的一步。但是,如果您想实现更好的关注点分离,并因此获得更多可重用的域/业务逻辑,我建议使用Presenter First 模式(您在评论中简要提及自己)。除了减少耦合之外,它还非常适合 TDD,并允许您对所有业务逻辑进行单元测试。

我最近开始了一个 GitHub 存储库,其中包含适用于 Android 的 Presenter First 示例。由于 Android 架构的复杂性,实现该模式并不简单。视图往往比普通 Presenter First 应用程序中可接受的“胖”,主要是因为活动生命周期和您提到自己的其他怪异。我已经尽我所能将业务逻辑与平台分离,但肯定还有改进的余地。您可以在以下位置找到示例:

http://github.com/olerass/presenter-first-android

也许你可以从那里使用一些想法?或者更好地贡献一些你自己的。

于 2016-01-14T22:53:30.177 回答