Model-View-Presenter（MVP）是一种众所周知的GUI应用程序设计模式。对于Android，在普通Java模块中实现业务逻辑有助于测试而无需Android模拟器。
但是，由于Android应用程序GUI的特殊要求，我在Android上实现模式时遇到了困难：
活动可能会在任何时候被破坏（来电，用户按下主页按钮，......），并且在重新创建时，它应该处于与离开时完全相同的状态。这与大多数其他GUI应用程序不同。
活动可以经历许多生命周期状态。可能会暂停，在这种情况下，不应修改活动的UI。例如，如果某些数据在后台加载，则如果它处于暂停状态，则无法将其传递给MVP（Activity）的View部分。同样，这是一个不寻常的要求。
我已阅读博文MVP for Android，并查看了example source code。我试图通过使用MVP模式实现的最终目标是能够使用转换器j2objc将所有业务逻辑转换为Objective-C，这样在iOS上实现相同的应用程序时可以重用业务逻辑
有没有人成功实现了Android的MVP模式，在这种情况下，我缺少什么？
答案 0 :(得分：4)
我建议在不涉及Activity的情况下实现MVP组件，或许在概念上考虑什么对Android和GWT都有用。使用带有模拟View接口的测试驱动开发创建组件，添加测试直到业务逻辑完全实现和验证。 TDD有助于保持组件的API精益（为什么要为不需要的东西编写测试？），这样可以更轻松地移植组件。
您描述的活动要求可以概括为与平台无关：组件应该是可序列化的（小型的，不是特定的Java序列化），并且需要接受生命周期状态事件。这些也可以使用模拟系统功能进行全面测试。在执行此步骤时，您可能会注意到很少有活动要求必须是特定于Android的，并且可能在其他平台上有用。避免创建庞大的服务API;例如，为了支持序列化，所需的只是存储/加载方法，而不是Parcel API。我发现在白板上向其他开发人员描述这样的服务API是找到不必要的麻烦的好方法。
接下来，将组件移植到Android，可能是通过创建委托给组件的Activity并为模拟接口提供特定于Android的实现类。它应该首次“正常工作”，但实际上，可能已经错过了一些要求，因此将它们添加到与平台无关的部分并重复。
当您准备移植到iOS时，重新实现之前模拟的接口。如果这些接口是精简的，那么直接在Objective-C中创建它们可能会更容易，导入j2objc生成的协议头。例如，j2objc的NSDictionaryMap类使用NSDictionary实现实现java.util.Map - 不需要编写和翻译Java版本，因为它只使用iOS API。
答案 1 :(得分：1)
我发现围绕MVP变种Android是朝着正确方向迈出的一步，可以隔离应用中的业务逻辑。但是，如果您希望实现更好的关注点分离，并因此需要更多可重用的域/业务逻辑，我建议您使用Presenter First pattern（您在评论中简要提及）。除了减少耦合之外，它还适用于TDD，并允许您对所有业务逻辑进行单元测试。
我最近用Android的Presenter First示例开始了一个GitHub回购。由于Android架构的复杂性，实现模式并不简单。视图往往更加“粗壮”。比普通的Presenter First应用程序似乎可以接受的，主要是因为你自己提到的活动生命周期和其他奇怪的东西。我已尽最大努力将业务逻辑与平台分离，但仍有改进的余地。您可以在以下位置找到示例：
http://github.com/olerass/presenter-first-android
也许你可以从那里使用一些想法？或者甚至更好地贡献自己的一些。