Cod*_*oid 11 android design-patterns android-layout
问题:真的很大且复杂的Activity类.难以阅读/理解和修改.很难测试.
可能的解决方案:Model-View-Presenter(可能具有依赖注入).和模拟测试对象!
我打算在我的Android应用程序中实现Model-View-Presenter.这基本上是模型 - 视图 - 控制器的变体.实质上,使Activity成为一个美化的布局管理器,并将任何业务逻辑推迟到Presenter.另一种查看Presenter的方法是,它就像一个在Activity中实例化的Helper类,通过提供Presenter可以使用的接口/回调的活动来完成繁重的工作.
我想得到一些社区的想法.例如:这隐含了哪些接口？
Model和View与Presenter有什么责任.
对于Presenter,我想Activity会实现Presenter所需的接口吗？
Presenter vs. Activity应该包含哪些内容？
演示者是否与活动一对一？那么一个Activity有多个片段显示不同的小部件,每个小部件都有自己的适配器？我们现在需要多个演示者还是只有一个？
Presenter与适配器怎么样？
演示者应如何与ListView和ListViewAdapter说一个Activity？什么进入Presenter与适配器？
Presenter应该选择要使用的适配器吗？或者活动应该做出这个决定？Presenter应该处理模型数据还是适配器？适配器和演示者之间是否存在冲突？适配器是主持人吗？或更少/更多的东西.通常,适配器仅适用于活动中的ListViews等小部件.我认为他们不会调用获取数据的调用.
因此,在模型 - 视图 - 演示者中,关键是确定演示者与其他类的内容以及演示者与活动,适配器和视图/包括片段之间的通信.
Model-View-Presenter对Android来说真是个坏主意吗？或者它是否适合Android框架？
请记住,Android之外有很多非常成熟的SDK仍然需要像MVP这样的微架构.事实上,例子比比皆是:例如.Flex是非常成熟的Flash SDK,但它仍然需要几乎所有主要应用程序的MVP和MVC框架.
EJB需要Spring来简化和组织它.MFC/Struts等和列表一直在继续.为什么Android会有所不同？为什么我们应该假设SDK在没有像MVP这样的设计模式的情况下拥有Android所需的一切？
很高兴知道我花了数百个小时之前,请随时评论/回答这个问题的任何部分.
Android 对糟糕的 MV(P|C) 设计的惩罚比我遇到过的任何平台都多。忘记它提供的用于在活动堆栈中上下传递状态的笨拙方法吧。从你的活动中获得尽可能多的状态和逻辑。根据需要将其移至 Services、ContentProviders 和 SharedPreferences 中。尝试让你的活动变得纯粹的观点。IMO，服务在 Android 教程中从未得到足够的重视。甚至 O'Reilly 的《Android 编程》书也只给了他们四分之一页！
小心扩展应用程序。如果您曾经在自己的进程中启动一个服务（例如，允许它在活动崩溃时正常关闭），那么该服务将拥有自己的应用程序副本。