BREW与Android中的UI事件框架比较,该如何处理

BREW与Android中的UI事件框架比较
对于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还略有不同
------解决方案--------------------
写的很好啊

相关内容推荐