Brew Callback机制和事件驱动机制

 

internal(kernel)->uitask->brew internal->active dialog->dialog ctrl->brew apps.

for clr: if app not process it, then brew will close the current running app.
for end: brew will close all apps, not passed this event to all apps, unless hook.

    BREW key process:
   
    hitask->uitask->handlekey------>state machine->process directly
                                |-->brew->key map->process brew environment

    About HOOK(PL_SYSTEM & AFLAG_Phone):改机制看起来神通广大,不过一山还比一山高.

    judgement(private option):
    1. BREW内核事件作用于Dialog--top visible app--internal
    2. BREW用户自定义事件作用于Dialog--all apps--internal (eg.sendevent postevent)

    BREW各种机制:
    大致分为两大类:一.callback机制 二.事件驱动机制
    一. callback机制
        1.AEECallback机制
          这是BREW标准callback机制,相关操作函数为Callback_init(),Ishell_resume();Callback_cancel().
          与AEECallback对应的还有native callback,它不像AEECallback那样只能运行在BREW环境中,它能在uitask和other task之间相互调用.
        2.Timer机制
          这应该是操作系统相关都应该提供的机制,虽然BREW不是操作系统.相关操作函数有两组
          Ishell_Settimer() Ishell_Canceltimer()
          Ishell_SettimerEx() Callback_Cancel()
          上面那组是标准的,不过据介绍都普遍转向下面那组了.哎,这是什么世道,标准的都被人摒弃,以后怎么混啊(小发牢骚下).
          其实他们也是为了我们能用得简单,下面那组用的是标准的AEECallback(看来标准也是有一片天地的).
          与AEECallback机制的比较:
          他们都是异步实现通知的一种方法,只不过AEECallback是下一个BREW环境被执行到执行,Timer机制是在timer过期之后的下一个loop执行.
        3.sleep机制(应该是事件驱动机制,不过那个超时时间应该是用timer做的,而且有一定的可比性就先放这了)
          这个机制好像是专为screen saver设计的,通过AEE_Dispatch()的返回值确定是否进入sleep模式.
          在超过默认的时间过了以后,用户还没有进行按键操作,BREW internal会发送EVT_APP_NO_SLEEP,返回true,重置30秒,返回false,每个loop都询问.个人认为这种设计有问题,因为返回false的话系统进入睡眠模式,没有必要重复地进行询问.
    二. 事件驱动机制
        1.alarm机制
          首先介绍它的原因是它也跟timer有一定的可比性:虽然都是在时间到期后做一定的事情,不过还是有本质区别的:
          .驱动机制不一样,timer是基于callback的,对进程的依赖性比较大.alarm机制是基于事件的,就算实例不存在也不打紧.
          .存储介质不一样,timer应该是存在在进程的栈中,alarm是存储在文件系统之类的非易失性的存储器中.
          .时长不一样,timer应该是比较短期的,甚至是毫秒级的,alarm可能是几天到几年不等,比如闹钟等.那么中间地带应该怎么选择呢,我个人认为有个标准,如果频率太高那么就用timer,不用来回创建和销毁实体,带来不必要的损耗,如果需要有记忆性,那么就用alarm,就算关机了也能有效.
        2.hook机制
          它是先于top visible得到事件的一种机制.它是在某一应用中用来对同一按键进行不同处理的必要机制,只要它返回true,其他任何app或internal默认处理函数都无法得到响应.
        3.notify机制
          hook机制看起来听牛的,不过notify更有特权,只要它被注册过,就算你是hook,就算你还返回了true,都无法阻止我的执行.而且目的性很强,只对自己感兴趣的消息进行处理.我的人生有一个notify,并不是在出生的时候就注册,但是确实是一个不错的notify,在做任何决定之前,它都会跳出来,查看一下我的头脑,如果脑子过热,它就会对我说"嘿,小子,现在还不是做决定的时候,等冷静下来再说".我希望这个机制不会失效.