对于BREW，我非常熟悉，但是对于Android，只能算刚刚认识，最近看了些Android的UI事件处理的相关文档，发现Android的UI事件处理框架与BREW有一些异同，这里给予一些比较，纯属个人认识。 如有不当之处，欢迎指正。
相同之处在于，从高层而言，Android与BREW的UI事件框架均是基于职责链模式的，运行时构成了Event Chain。 Event Chain中的每一个部件默认将事件传递给后继者。 事件在Event Chain的终点处自然终止， 或者在中间异常终止（中间部件返回了TRUE，导致事件流终止）。
主要的不同之处在于， 成为/替换 Event Chain中Handler的方式不同以及事件监听者的用途不同。具体来说：
在BREW中，默认的Event Chain可能是 BREW Shell-> Dialog-> App->Control。 由于BREW的组件和框架是基于C实现的，不提供“实现”继承，所以，对于Event Chain中的某个部件（组件）， 如果期望改变其事件的默认处理方式（即Hook Event），不可能使用继承后覆写_HandleEvent的方法，只能基于组件本身提供的Handler Hook API， 类似于 _SetHandler。 所以， 对于IStatic， IMenu， ITextCtl等组件， 开发者不可能去改变其事件处理方式，因为这些组件没有提供Hook API。 而对于Dialog， 其提供了IDialog_SetEventHandler API，使得开发者可以将自己的Handler按插到Chain中去，并允许终止Event Chain（Return TRUE）。 对于 Applet的HandleEvent，那再熟悉不过了，AEEApplet_New允许传递应用的Handler，使其作为Event Chain的一个节点。
需要注意的是， BUIW中的Widget，Form等组件也提供SetHandler方式来Hook Event， 但是其内部的实现，其实是将Default Handler与 Customer Handler直接交换了，使得他们彼此指向对方，这样，Event Chain中参与的仍然是Widget，Form的Default Handler，但是由于其指向了Customer Handler，所以，Event Chain中参与的Handler就自然变成了Customer Handler了，达到Hook的目的。 这样，为了能使Event Chain保持不间断， Customer Handler中最后必须再次回调Default Handler（通过HANDLERDESC_Call）， 除非你真的希望事件流在此终端
BREW中，同时提供了UI事件的Notification机制，这是基于Observer模式，使得感兴趣的客户，可以监听UI事件的变化。 注意，BREW中的事件监听的目的真的仅仅是监听，与Event Chain是独立的，完全不会影响Event Chain的正常流向。 也就是说 BREW中的UI事件的监听， 不管是否存在返回值，以及返回TRUE，FALSE， 都不会影响正常的事件流。 仅仅通知感兴趣的客户，发生了什么，而不是需要等待客户决策什么。 仅仅是Notification， 而不是Verification。 BUIW中通过View的Add Listener可以监听UI变化。 该监听场景仅仅在观察者实例存在时有效， 因为其是基于Callback的， 如果回调的对象不存在，那么也就没有通知的意义了。 BREW中另外提供一种全局生命期的通知机制，即便观察者实例不存在，仍然可以进行通知（只对App有效），这是通过BREW的INotifier机制实现的。 对应于Key，BREW允许应用注册Key Notification。
而在Android中，改变Event Chain却可以有两种方式，或者说，Android框架提供了两种方式。 一种是基于模版方法模式，一种基于观察者模式。 基于模版方法模式简言之，就是直接继承组件并覆写相应的Handler方法，由于面向对象语言（Java）支持基于实现的继承，所以这种方式是允许的。 通过这种方式，开发者可以改变所有UI控件（View）的默认事件处理方式， 当然，为了使得Event Chain不中断，你必须在你覆写的Handler方法最后，Return Super.Handler， 除非你期望事件流到此为止，那么你Return True即可。
但是，这种方式的一个很大的弊端在于，现实中不可操作。 因为，我不可能仅仅为了改变一个View的事件处理（或者监测事件变化），就要去继承它重新实现一个类！ 如果每个View都这样去做，那太疯狂了，根本就不可行！！ 所以， Android就又提供了一种改变Event Chain的方法， 就是通过Listener， 每个View控件均提供一组SetXXXListener的方法，允许用户调用其并将IListener接口实例传入， 然后在View相应的UI事件发生时，通过对象委派的方式，调用到IListener对象中相应的Handler方法。 这是典型的Observer模式。 这里的对象委派，其实就是面向对象的回调实现版本。 OK， 同样是事件监听，同样采用Observer模式，但是由于Android和BREW使用其的目的不同，所以，实际的效果也就不同。 在Android中，事件监听者直接参与到了Event chain中，可以直接改变Event Chain的行为并随时中止它， 这也就是为什么Android中的大部分Listener方法是带Boolean类型的返回值的，而BREW中的不需要。 因为，BREW中的事件监听仅仅是Notify，而不是Verify， 而Android中的事件监听，是Notify，同时也是Verify。
------解决方案--------------------------------------------------------
Ding.
------解决方案--------------------------------------------------------
很好，学习了
------解决方案--------------------------------------------------------
BREW MP的windows manager还略有不同
------解决方案--------------------------------------------------------
写的很好啊