模型视图演示器与Android应用程序设计

Question

问题:非常大和复杂的活动类。难以阅读/理解和修改。很难测试。

可能的解决方案:模型-视图-演示器(可能与依赖注入)。还有伪装测试对象！

我计划在我的Android应用程序中实现Model演示器。这基本上是模型-视图-控制器的变体。本质上，让活动成为一个美化的布局管理器，并将任何业务逻辑交给演示者。查看演示者的另一种方法是，它类似于在活动中实例化的Helper类，通过提供演示者可以使用的接口/回调的活动来完成繁重的任务。

我想了解一下社区对此的看法。例如:这意味着什么接口？

模型和视图对演示者有什么责任？

对于演示者，我认为活动将实现演示者所需的接口？

什么类型的事情应该进入主持人和活动？

主持人会是一对一的活动吗？如果一个活动有多个片段显示不同的小部件，每个小部件都有自己的适配器，那该怎么办？我们现在需要多个主持人还是只需要一个？

主持人和适配器呢？

演示者应该如何使用ListView和ListViewAdapter来表示某项活动？主持人和适配器之间有什么关系？

演示者应该选择适配器来使用吗？还是应该由活动做出这个决定？演示者应该处理模型数据还是适配器？适配器和表演者之间有冲突吗？适配器是主持人吗？或者更少的东西。通常，适配器只用于活动中的小部件(如ListViews )。我认为，他们不会打电话来获取数据本身。

因此，在模型视图演示器中，关键是真正决定演示者与其他类之间的通信，以及演示者与活动、适配器和视图/包括片段之间的通信。

对Android来说，模型视图演示者只是一个非常糟糕的主意吗？还是说它与Android框架很相配？

请记住，在Android之外，还有许多非常成熟的SDK的例子，它们仍然需要像MVP这样的微体系结构。事实上，例子不胜枚举。Flex对于Flash来说是非常成熟的SDK，但是它仍然需要MVP和MVC框架来支持几乎所有的主要应用程序。

EJB需要Spring来简化和组织它。MFC/Struts等，列表还在继续。为什么Android会有所不同呢？为什么我们要假设SDK具备Android系统所需的一切，而没有像MVP这样的设计模式？

很高兴知道，在我花了数百个小时在此之前，请随时评论/回答这个问题的任何部分。

Answer 1

Android比我所遇到的任何平台都更能惩罚糟糕的MV(P/C)设计。忘记它为在活动堆栈中上下传递状态提供的笨拙方法。尽可能多地将状态和逻辑从您的活动中提取出来。酌情将其移动到Services、ContentProviders和SharedPreferences中。试着使你的活动成为纯粹的视图。在Android教程中，服务从来没有得到足够的重视。即使是O‘’Reilly编程的Android书也只给了他们四分之一页！

在扩展应用程序时要小心。如果您曾经在自己的过程中启动服务(例如，允许在某个活动崩溃时优雅地关闭它)，那么该服务将拥有它自己的应用程序副本。

Answer 2

只是为了给其他可能感兴趣的人提供一个参考。几年前我也是这么想的。当我们将MVC/MVVM/表示模型应用于android应用程序时，我们真正想要的是有一个清晰的结构化项目，更重要的是更容易进行单元测试。目前，如果没有第三方框架，通常会有大量代码(如addXXListener()、findViewById().)，它们不会增加任何业务价值。更重要的是，您必须运行android单元测试，而不是普通的JUnit测试，后者需要很长时间才能运行，并且使单元测试变得有些不切实际。出于这些原因，几年前我们开始了一个开源项目RoboBinding --一个用于Android平台的数据绑定表示模型框架。RoboBinding帮助您编写易于阅读、测试和维护的UI代码。RoboBinding消除了不必要的代码(如addXXListener或)的需要，并将UI逻辑转换为表示模型，该模型是pojo，可以通过normal JUnit tests进行测试。RoboBinding本身提供了300多个JUnit测试，以确保其质量。其他选择:Android绑定，Bindroid和MvvmCross。