Android开发中的设计模式原理是什么？

Question

我是一个JaveEE开发者。最近我加入了一个Android开发团队。 Android的结构让我困惑。 MVC设计模式似乎不适合Android开发。那么Android开发的设计模式原则是什么？我的意思是有任何关于如何编写干净，简单的阅读和有效的Android代码的暗示。

Answer 1

Android的架构起初让我恼火，但是我开始看到一种让他们疯狂的方法。它很少被android文档解释。我最大的抱怨一直是，你的活动像普通应用程序一样共享对象的集中数据模型很困难。 Android似乎希望我成为一名游牧民，因为我只能在我的活动之间分享原语。在数据库中丢弃垃圾并不是一个模型，因为它不包含任何行为。因此，大多数人的业务逻辑都以我的活动结束，很难在其他活动中共享业务逻辑。

我来找出我错过了一些关键的拼图。 Android是MVC。但是，它与View相当。

1. 活动==控制器
2. 型号==应用的子类
3. 任何一个继承查看==查看

有趣的是，你可以创建应用程序的一个子类，并在您的清单文件中声明该，并且Android将创建一个此对象的单个实例，该实例的长度始终保持在应用程序的长度上，而不管Activity被销毁或创建。这意味着您可以构建一个所有活动都可以访问的集中式数据模型。

我看到的这种方式就像初始化Spring容器，你可以初始化对象并解决它们之间的依赖关系。这样，您可以将应用程序的模型部分与Activity本身分离开来。只需让Activity对模型进行调用，然后手动回调即可接收结果，以便更新UI。

Android的问题在于它将控制器和视图混合在一起。例如，像TabActivity，ListActivity这样的子类意味着正在使用某个视图。因此，交换视图是相当重要的。此外，即使您使用“活动”，Controller也会对视图进行非常具体的假设。他包含对TextView等UI对象的直接引用，并且它注册了低级别事件，如点击，键盘等。

如果Activity可以注册更多高级事件，如“Login”，“Update帐户余额“等，视图将响应一系列点击，键盘，触摸事件而分派。这样，控制器就可以在您可能描述的功能而不是设计功能的级别上工作。

我想我们最终会达到这种类型的设计，因为我们更好地理解想出更好的工具和技术。看起来Android可能具有可扩展性来实现这一点，但是社区需要绘制它。

Answer 2

Android中的动作，视图和活动是用Android UI工作的，并且是模型视图视图模型的实现，它在结构上与模型视图控制器（在同一族中）类似。

据我所知，没有办法摆脱这种模式。它可能可以完成，但您可能会失去现有模型的所有好处，并且必须重新编写自己的UI层才能使其工作。

您可以在以下找到MVC：

• 定义你的user interface由分辨率/硬件等各种XML文件
• 您可以通过语言环境等
各种XML文件定义您 resources
• 您将SQLite中的数据或您的自定义数据存储在/ assets /文件夹中，详细了解resources and assets
• 您扩展类似ListActivity，TabActivity和inflaters
• 利用XML文件的，你想为你的模型，您可以创建许多类，并有自己的包，将作为
• 很多Utils已经被结构为你写。 DatabaseUtils，Html，

没有可以服从的单个MVC模式。 MVC只是或多或少地声明你不应该混合数据和视图，例如视图负责保存处理数据直接影响视图的数据或类。尽管如此，Android处理类和资源的方式，有时甚至被迫遵循MVC模式。在我看来，更复杂的是这些活动有时对于观点负责，但在同一时间充当控制者。

如果你在xml文件中定义你的视图和布局，从res文件夹加载你的资源，并且如果你或多或少地在代码中混合这些东西，那么你无论如何都会遵循MVC模式。

Answer 3

我的印象是，android编程模型与MS WPF有很多相似之处。 XML布局定义，总是绑定到其中一个定义的代码...所以，如果您因为想要改进当前或开发android项目而询问设计模式，也许您应该查看WPF实践和模式用于改进架构，如MVVM。

请查看以下链接：

http://msdn.microsoft.com/en-us/magazine/dd419663.aspx

有一个已经尝试类似的事情，小项目：

http://code.google.com/p/android-binding/

欢呼

Answer 4

Android开发主要是图形用户界面的开发，像Java中的Swing/AWT包含许多匿名内部类reactin g到GUI事件。其中一件事让我摆脱了与Swing的大量合作......但是我拥有一部Android手机，所以我会咬紧牙关，然后克服它，就像许多苹果迷们说的那样关于天线问题。 ;）

Answer 5

Android使得制作控制器和查看单个类的典型决策成为可能。这鼓励把太多的东西放在同一个地方。一个活动对应一个屏幕，每个视图到一个屏幕区域（有时是整个屏幕），每个用户的控制器都是从屏幕的该区域进行手势操作的，模型只是模型，有时由环境或其他服务提供支持疯狂的一套实用功能。我使用Activity来协调一个或多个MVC三重奏。这有助于处理Android的选择，把所有东西都放在同一个地方。

我可以在不运行模拟器的情况下测试绝大多数Android应用程序。大赢。

Answer 6

对不起，我的英语。

Android具有非常好的模块化（活动，片段，视图，服务等）。所以在MVC中没有必要。

当然，有输入（活动，片段），逻辑，视图（XML或Java）和数据（数据库，文件，首选项）的分离。但这不是MVC。你不应该尝试使用MVC，它只会使你的架构复杂化。

Android并不是将东西放在全局范围内，而是激励您尽可能在对象范围（类成员，局部变量）中保留对象，并使用Intents/Bundles将对象传递到活动或传递到片段。这也是由于内存限制。如果前景活动 需要更多的资源，因此系统必须关闭后台进程 恢复记忆

该系统可能会破坏你的活动。

因此，将非常量（可变）对象存储为全局（静态）对象并不安全。通常你使用static作为不变的常量。

简而言之，你将你的应用程序划分成屏幕（Activities）。然后，每个屏幕 - 成片段（碎片）。要在屏幕上执行一系列操作，您还可以使用Fragments（example）将它们分开。

因此，您的应用程序中有非常小的块，每个块都可以轻松测试和重用。