问题:非常庞大且复杂的 Activity 类。难以阅读/理解和修改。难以测试。
可能的解决方案:Model-View-Presenter(可能使用依赖注入(inject))。 和模拟测试对象!
我正计划在我的 Android 应用程序中实现模型- View -展示器。 这基本上是模型- View - Controller 的变体。本质上，让 Activity 一个美化的布局管理器，并将任何业务逻辑推迟到 Presenter。另一种看待 Presenter 的方式是，它就像一个在 Activity 中实例化的 Helper 类，通过 Activity 提供 Presenter 可以使用的接口(interface)/回调来完成繁重的工作。
我想听听社区对此的一些想法。例如:
这意味着什么接口(interface)？
Model 和 View 与 Presenter 有什么责任。
对于 Presenter 我想 Activity 会实现 Presenter 需要的接口(interface)？
Presenter 与 Activity 应该包含哪些类型的内容？
演示者会与 Activity 一对一吗？具有多个 fragment 的 Activity 显示不同的小部件，每个小部件都有自己的适配器怎么样？我们现在需要多个演示者还是只需要一个？
Presenter 与 Adapter 有何区别？
Presenter 应该如何将 Activity 与 ListView 和 ListViewAdapter 联系起来？
Presenter 与 Adapter 有什么区别？
演示者应该选择要使用的适配器吗？或者 Activity 应该做出这个决定吗？
Presenter 应该处理模型数据还是适配器？适配器和演示器之间是否存在冲突？适配器是演示器吗？或更少/更多。通常 Adapters 仅适用于 Activity 中的 ListViews 等小部件。我认为他们不会进行获取数据本身的调用。
所以在 model-view-presenter 中，关键的事情实际上是决定在 presenter 和其他类中发生什么，以及在 presenter 和 Activity 、适配器和 View /包括 fragment 之间应该进行什么通信。
Model-View-Presenter 对于 Android 来说真的不是一个好主意吗？或者它是否适合 Android 框架？
请记住，在 Android 之外有许多非常成熟的 SDK 示例仍然需要像 MVP 这样的微架构。事实上例子比比皆是:例如。 Flex 是非常成熟的 Flash SDK，但它仍然需要适用于几乎所有主要应用程序的 MVP 和 MVC 框架。
EJB 需要 Spring 来简化和组织它。 MFC/Struts 等，这个列表还在继续。为什么 Android 应该有所不同？为什么我们要假设 SDK 具备 Android 所需的一切，而没有像 MVP 这样的设计模式？
很高兴知道，在我为此花费数百小时之前，请随时对此问题的任何部分发表评论/回答。
最佳答案
Android 对糟糕的 MV(P|C) 设计的惩罚比我遇到的任何平台都多。忘掉它提供的用于在 Activity 堆栈上下传递状态的笨拙方法吧。尽可能多地从您的 Activity 中获取状态和逻辑。视情况将其移动到 Services、ContentProviders 和 SharedPreferences 中。尽量使您的 Activity 纯 View 。 IMO，服务在 Android 教程中从未得到足够的重视。即使是 O'Reilly Programming Android 一书也只给了他们四分之一的页面!
谨慎扩展应用程序。如果您曾经在其自己的进程中启动服务(例如，允许它在 Activity 崩溃时正常关闭)，那么该服务将拥有自己的应用程序副本。
关于android - Model-View-Presenter 和 Android 应用程序设计，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/12291316/