标准方法的弊端

建立所有这些组件之间的通信涉及创建特殊接口的一个标准的方法，称为听众。任何类都可以通过一个监听器实例的任何部分，将照顾通知侦听器内构件发生各种事件。

这种方法有两个主要缺点：

• 组件通常是不知道对方可能无法传递和接收的听众对象直接。如果用户改变一些数据在屏幕上（就像他的名字一样），我们需要更新对其他应用程序的屏幕数据。但一个活动或片段不能互相交谈，由于Android平台的限制，所以我们不能把听者从一个到另一个活动。
• 任何不平凡的应用程序有许多相通的组件将需要执行大量的听众。这可能会使你的代码，使它不灵活和高度凝聚力。

有效的解决方案：消息总线

一个行之有效的方法这个问题是一个消息总线（由发布订阅模式）描述。这种方法被广泛使用在Android平台本身，例如在意图的实现。

消息总线的工作原理如下：任何成分，愿意接收来自应用程序其他部分的通知，在总线寄存器（订阅事件通知）。当事件被触发，发送一个消息（发表）的公共汽车，并立即转发给所有注册用户。该组件不需要直接交谈。

公共汽车也有可能创造所谓的能力棘手的事件坚持在公交车上不断地传送给所有新用户（现有用户首次出版时）。棘手的事件通常覆盖如果同类型的一个棘手的事件已经在公共汽车上时，新的事件被公布。他们常用的当我们不想让用户错过重要事件如加载数据通过网络或当我们希望用户收到邮件后立即登记无需等待一个新的非粘性的事件。

基于消息总线的例子

让我们中的几个应用实例看消息总线。

1。加载和显示新闻

假设我们开发的主菜单使用导航抽屉中的应用。一个屏幕可从菜单是一个新闻饲料和未读邮件的数目的片段显示在菜单。

应用程序是由4个主要部分：一个菜单，一个片段的消息显示，当地的DB和AsyncTask在后台数据库和缓存加载消息。

我们可以使用一个消息总线构建这个应用程序。应用程序启动之后，菜单立即显示缓存中的未读项目数和从服务器下载饲料任务在后台启动。

当任务顺利完成和更新的饲料是存储在数据库中，一个消息发表在公共汽车。菜单和新闻片段接收消息和更新自己根据新的数据从数据库加载。因此，我们可以相处的不衔接，因为只有这里是数据库共享组件。

2。文件下载状态

考虑这样一种情况，当用户从网上下载一个文件（文件或数据库更新）。下载的文件可能需要一些时间，在此期间用户可以离开屏幕后回来。我们需要将应用程序从下载过程和使用文件下载服务是一个明显的解决方案在这里。然而，我们仍然需要向用户报告下载状态。

在这种情况下，我们需要建立2个组成部分之间的通信：活动（GUI）和下载服务。

消息总线非常适合这类集成。该服务将出版活动与当前粘下载状态（下载活动，下载进度，文件属性）。一旦软件外包公司的信息屏（活动）长大，它能让所有的信息从总线上需要向用户显示。