Android开发：观察者模式使用实例
Android开发：观察者模式应用实例
观察者模式应用实例——Broadercast实现进程间异步通信
1 Broadcast实现进程通信
利用Broadcast可以实现Android中的进程间通信。
比如，存在客户端BCClient和服务端BCService这两个不同的进程，它们之间的通信过程具体如下图所示：
通过这样的方式双方能完成通信，不过要达到异步通信的目的，需要进一步改进设计。
2实现异步通信
为了实现异步通信，需要对客户端的类进行重新设计，同时考虑到系统的扩展性、可复用性，以及服务端对外接口的易用性。选择将BCClient的视图ClientActivity剥离出去，并对ClientReceiver做进一步封装，相当于在原客户端和服务端中间构建出一层作为中间层。
为了便于说明，客户端和服务端需要一个应用场景。假设服务端负责管理系统相关设备，并提供操作设备的接口，而客户端则根据需求通过中间件来异步调用相应的服务。
比如，用户点击客户端的按钮来获取设备信息，并且点击按钮后用户不必一直等待服务端返回信息才能继续操作，而是服务端响应完成后自动通知客户端。
由于整个过程客户端不是进行同步等待，而是异步接收，设计时考虑引入设计模式中的“观察者模式”。
2.1 观察者模式
通过以上分析，明确了设计的改进重点在于对ClientReceiver的封装，并且封装采取的合理策略应当是 “观察者模式”。改进设计后ClientReceiver就被中间层所替代，中间层的类图如下：
从类图中不难看出，这是一个典型的“观察者模式”的类设计模型，DevListener对应于观察者模式中的观察者“Observer”，而DevManager就是观察者模式中的主题“Subject”。原ClientReceiver的主要功能被封装在中间层的DevReceiver类中，而服务端接口的直接调用者是DevManager类。
2.2 客户端服务端交互流程
在加入“观察者模式”后，客户端和服务端的交互流程如下：
1、客户端-->创建监听器-->在监听器中重写回调函数，用于处理服务端返回结果-->将该监听器注册到DevManager -->调用DevManager 的readDevInfo方法向服务端发送广播；
2、服务端-->利用BroadcastReceiver接受到广播信息-->处理信息-->向客户端（DevReceiver）发送广播信息；
3、客户端-->利用BroadcastReceiver（DevReceiver）接受到广播信息-->调用DevManager的notifyListener方法-->调用客户端重写好的回调函数，完成异步通信。
2.3 客户端调用
加入中间层后，客户端能够方便的使用DevManager提供的服务，在使用DevManager提供的服务时如同使用Button控件一样（Button控件的内部实现也是利用了观察者模式）方便、简洁。
客户端调用代码如下：
客户端的调用服务过程主要是通过DevManager对监听器DevListener进行注册、监听。运行结果如下，当点击“send”按钮的时候发送设备读取请求，即调用readDevInfo方法，点击完成后不必等待服务端的相应。
服务端处理完客户端请求后，会向中间层的DevReceiver发送广播，DevReceiver接到广播后回调客户端重载的dealWith函数，部分代码如下：
回调完成后，客户端获取到服务端信息：
3 小结
观察者模式的核心思想是将数据表示层和逻辑层分离，并定义了稳定的消息传递机制、抽象出调用接口。在需要采用异步通信的应用场景中，合理地运用观察者模式往往会有很好的效果。
当然观察者模式也存在有缺陷。目前本例中的Observer（即本例中的DevListener）只有一个，如果一个Subject（即本例中的DevManager）中注册有大量Observer（即DevManager中存在一个存放DevListener的集合）的话，在广播通知Observer时存在效率问题，毕竟需要遍历集合中所有的Observer。
原文链接：http://www.linuxidc.com/Linux/2011-09/42585.htm
观察者模式应用实例——Broadercast实现进程间异步通信
1 Broadcast实现进程通信
利用Broadcast可以实现Android中的进程间通信。
比如，存在客户端BCClient和服务端BCService这两个不同的进程，它们之间的通信过程具体如下图所示：
通过这样的方式双方能完成通信，不过要达到异步通信的目的，需要进一步改进设计。
2实现异步通信
为了实现异步通信，需要对客户端的类进行重新设计，同时考虑到系统的扩展性、可复用性，以及服务端对外接口的易用性。选择将BCClient的视图ClientActivity剥离出去，并对ClientReceiver做进一步封装，相当于在原客户端和服务端中间构建出一层作为中间层。
为了便于说明，客户端和服务端需要一个应用场景。假设服务端负责管理系统相关设备，并提供操作设备的接口，而客户端则根据需求通过中间件来异步调用相应的服务。
比如，用户点击客户端的按钮来获取设备信息，并且点击按钮后用户不必一直等待服务端返回信息才能继续操作，而是服务端响应完成后自动通知客户端。
由于整个过程客户端不是进行同步等待，而是异步接收，设计时考虑引入设计模式中的“观察者模式”。
2.1 观察者模式
通过以上分析，明确了设计的改进重点在于对ClientReceiver的封装，并且封装采取的合理策略应当是 “观察者模式”。改进设计后ClientReceiver就被中间层所替代，中间层的类图如下：
从类图中不难看出，这是一个典型的“观察者模式”的类设计模型，DevListener对应于观察者模式中的观察者“Observer”，而DevManager就是观察者模式中的主题“Subject”。原ClientReceiver的主要功能被封装在中间层的DevReceiver类中，而服务端接口的直接调用者是DevManager类。
2.2 客户端服务端交互流程
在加入“观察者模式”后，客户端和服务端的交互流程如下：
1、客户端-->创建监听器-->在监听器中重写回调函数，用于处理服务端返回结果-->将该监听器注册到DevManager -->调用DevManager 的readDevInfo方法向服务端发送广播；
2、服务端-->利用BroadcastReceiver接受到广播信息-->处理信息-->向客户端（DevReceiver）发送广播信息；
3、客户端-->利用BroadcastReceiver（DevReceiver）接受到广播信息-->调用DevManager的notifyListener方法-->调用客户端重写好的回调函数，完成异步通信。
2.3 客户端调用
加入中间层后，客户端能够方便的使用DevManager提供的服务，在使用DevManager提供的服务时如同使用Button控件一样（Button控件的内部实现也是利用了观察者模式）方便、简洁。
客户端调用代码如下：
public class ClientActivity extends Activity {
private static final String TAG = "ClientActivity>>>>>>>>>";
private DevManager dm;
@Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.main);
Log.i(TAG,"onCreate");
Button button = (Button)findViewById(R.id.button);
button.setOnClickListener(new BroadcastListener());
dm = DevManager.getInstance();
dm.setDevListener(new DevListener(){
@Override
public void dealWith(DevEvent event) {
Toast.makeText(getApplicationContext(),event.getEventContent(), 10000).show();
}
});
}
class BroadcastListener implements OnClickListener{
@Override
public void onClick(View view) {
Log.i(TAG, "Click SendButton");
dm.readDevInfo(view.getContext());
}
}
}
客户端的调用服务过程主要是通过DevManager对监听器DevListener进行注册、监听。运行结果如下，当点击“send”按钮的时候发送设备读取请求，即调用readDevInfo方法，点击完成后不必等待服务端的相应。
服务端处理完客户端请求后，会向中间层的DevReceiver发送广播，DevReceiver接到广播后回调客户端重载的dealWith函数，部分代码如下：
public void onReceive(Context context, Intent intent) {
if(intent.getAction().equals("DoServiceResponse")){
Log.i(TAG,"Action Is DoServiceResponse");
Communication info = (Communication)intent.getParcelableExtra("ResponseInfo");
if(info != null){
Log.i(TAG,"Receive ResponseInfo");
DevEvent event = new DevEvent();
event.setEventContent(info.getContent());
DevManager.getInstance().notifyListener(event);
}
}
//notifyListener的实现如下：
public void notifyListener(DevEvent event){
if(listener == null){
return;
}
else{
Log.i(TAG, "Notify Listener");
listener.dealWith(event);
}
}
回调完成后，客户端获取到服务端信息：
3 小结
观察者模式的核心思想是将数据表示层和逻辑层分离，并定义了稳定的消息传递机制、抽象出调用接口。在需要采用异步通信的应用场景中，合理地运用观察者模式往往会有很好的效果。
当然观察者模式也存在有缺陷。目前本例中的Observer（即本例中的DevListener）只有一个，如果一个Subject（即本例中的DevManager）中注册有大量Observer（即DevManager中存在一个存放DevListener的集合）的话，在广播通知Observer时存在效率问题，毕竟需要遍历集合中所有的Observer。
原文链接：http://www.linuxidc.com/Linux/2011-09/42585.htm