欢迎来到Doc100.Net免费学习资源知识分享平台!
您的位置:首页 > 程序异常 >

brew与android中的ui事件框架比较解决办法

更新时间: 2014-01-05 02:45:34 责任编辑: Author_N1

 

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还略有不同
--参考方法--
写的很好啊
上一篇:上一篇
下一篇:下一篇

 

随机推荐程序问答结果

 

 

如对文章有任何疑问请提交到问题反馈,或者您对内容不满意,请您反馈给我们DOC100.NET论坛发贴求解。
DOC100.NET资源网,机器学习分类整理更新日期::2014-01-05 02:45:34
如需转载,请注明文章出处和来源网址:http://www.doc100.net/bugs/t/14021/
本文WWW.DOC100.NET DOC100.NET版权所有。