在Android中实现Model-View-Presenter的困难

模型 – 视图 – 演示者(MVP)是GUI应用程序中众所周知的devise模式。 对于Android来说,在普通的Java模块中实现业务逻辑可以在不需要Android模拟器的情况下进行testing。

但是,由于对Android应用程序的graphics用户界面的特殊要求,我在Android上实现模式时遇到困难:

  • 一个活动可能会在任何时候被破坏(来电,用户按回家button,…),当重新创build时,它应该处于与离开时完全相同的状态。 这与大多数其他GUI应用程序不同。

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

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

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

Solutions Collecting From Web of "在Android中实现Model-View-Presenter的困难"

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

您描述的活动需求可以概括为独立于平台:组件应该是可序列化的(小的,而不是特定的Java序列化),并且需要接受生命周期状态事件。 这些也可以使用模拟系统function进行全面testing。 在您完成这一步骤时,您可能会注意到很less的活动需求必须是特定于Android的,并且可能在其他平台上很有用。 避免创build大量的服务API; 以支持序列化,例如,所有需要的是存储/加载方法,而不是像Parcel API 。 我发现在白板上向另一个开发者描述这样的服务API是find不必要的绒毛的好方法。

接下来,将组件移植到Android,也许通过创build一个委托给组件的Activity并为模拟接口提供Android特定的实现类。 第一次应该都是“正常工作”,但实际上有些要求可能已经错过了,所以把它们加到平台无关的部分再重复一遍。

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

我发现Android构build的MVP变体是将应用程序中的业务逻辑隔离的一个正确方向。 但是,如果您希望实现更好的问题分离,并且由此创build更多可重用的域/业务逻辑,我build议使用Presenter First模式 (您在注释中简要提及自己)。 除了减less耦合之外,它还可以很好地支持TDD,并允许您unit testing所有业务逻辑。

我最近开始了一个GitHub回购与Presenter为Android的第一个例子。 由于Android架构的复杂性,实现这种模式并不容易。视图往往比普通的Presenter First应用程序中看起来“更胖”,主要是因为您提到自己的活动生命周期和其他古怪。 我已经尽力将平台的业务逻辑分离出来,但是还有很大的改进空间。 你可以在以下地址find例子:

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

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