在Notifications情况下，NotificationCompat。构建器使用构建器模式

就像,

mBuilder = new NotificationCompat.Builder(this)
                    .setSmallIcon(R.drawable.ic_stat_notification)
                    .setContentTitle(getString(R.string.notification))
                    .setContentText(getString(R.string.ping))
                    .setDefaults(Notification.DEFAULT_ALL);

在Notifications情况下，NotificationCompat。构建器使用构建器模式

就像,

mBuilder = new NotificationCompat.Builder(this)
                    .setSmallIcon(R.drawable.ic_stat_notification)
                    .setContentTitle(getString(R.string.notification))
                    .setContentText(getString(R.string.ping))
                    .setDefaults(Notification.DEFAULT_ALL);

我想添加一个设计模式，已经应用在Android框架。这是在Asynctask实现中使用的半同步半异步模式。请参阅我在

https://docs.google.com/document/d/1_zihWXAwgTAdJc013-bOLUHPMrjeUBZnDuPkzMxEEj0/edit?usp=sharing

Android框架中使用了多种模式，例如:

广播接收器使用观察者模式 远程服务调用使用代理模式 视图和视图组使用复合模式 媒体框架使用立面模式

所有这些模式，MVC, MVVM, MVP和Presentation Model，都可以应用到Android应用中，但是如果没有第三方框架，就不容易得到组织良好的结构和干净的代码。

MVVM起源于PresentationModel。当我们将MVC、MVVM和Presentation Model应用到Android应用中时，我们真正想要的是有一个清晰的结构化项目，更重要的是更容易进行单元测试。

目前，如果没有第三方框架，通常会有大量代码(如addXXListener()、findViewById()等)，这不会增加任何业务价值。更重要的是，你必须运行Android单元测试，而不是正常的JUnit测试，后者需要很长时间才能运行，并且使单元测试有些不切实际。

基于这些原因，几年前我们开始了一个开源项目RoboBinding——一个用于Android平台的数据绑定表示模型框架。RoboBinding帮助您编写更易于阅读、测试和维护的UI代码。RoboBinding消除了对addXXListener等不必要代码的需求，并将UI逻辑转移到表示模型(Presentation Model)，这是一个POJO，可以通过正常的JUnit测试进行测试。RoboBinding本身带有300多个JUnit测试，以确保其质量。

我尝试使用模型-视图-控制器(MVC)和模型-视图-呈现者架构模式来进行android开发。我的发现是模型-视图-控制器工作得很好，但有几个“问题”。这一切都取决于你如何看待Android Activity类。它是控制器还是视图?

实际的Activity类并没有扩展Android的View类，但是它可以处理向用户显示一个窗口，也可以处理该窗口的事件(onCreate, onPause等)。

这意味着，当你使用MVC模式时，你的控制器实际上是一个伪视图控制器。因为它处理的是向用户显示窗口，以及您使用setContentView添加到它的附加视图组件，并且还处理至少各种活动生命周期事件的事件。

在MVC中，控制器应该是主要的入口点。如果将其应用到Android开发中，这是有争议的，因为活动是大多数应用程序的自然入口。

正因为如此，我个人认为模型-视图-呈现者模式非常适合Android开发。因为视图在这个模式中的角色是:

作为入口的 渲染组件 将用户事件路由到演示者

这允许你像这样实现你的模型:

视图——它包含你的UI组件，并为它们处理事件。

Presenter - this will handle communication between your model and your view, look at it as a gateway to your model. Meaning, if you have a complex domain model representing, God knows what, and your view only needs a very small subset of this model, the presenters job is to query the model and then update the view. For example, if you have a model containing a paragraph of text, a headline and a word-count. But in a given view, you only need to display the headline in the view. Then the presenter will read the data needed from the model, and update the view accordingly.

模型——这应该是你的全域模型。希望它也能帮助您使域模型更加“紧凑”，因为您不需要像上面提到的那样使用特殊的方法来处理情况。

通过将模型与视图完全解耦(通过使用演示器)，测试模型也变得更加直观。您可以为域模型进行单元测试，也可以为演示器进行单元测试。

试试吧。我个人认为它非常适合Android开发。