Event-driven model

The BREW application model is an event-driven collaborative multitasking model. The core issue of the event processing mechanism is that the program should only process the required events. For events that do not need to be processed, the program must return the event to the system for processing. After the application is loaded, it can use the handleevent () function to receive all input events, and then return true (processed) or false (unprocessed) to indicate whether to process the events. There is a global event queue in the aee layer, and all events are stored in this queue. If the events in the queue are processed after delivery or are not processed, this event will be deleted from the event queue.

There are three main types of brew events: system events, predefined events, and custom events. The Event code range of system events is 0 ~ 7, that is, from evt_app_start to evt_app_browse_file. The Event code range of a predefined event is 0x0008-0x4fff, that is, the predefined or reserved events of the brew aee and OEM layers. Custom events refer to the events that brew applications can customize. Custom events should be no less than evt_user (0x5000 ). Brew applications can send any event to the application itself, or to other applications in the same process. If an event is sent to an application of different processes (mainly for brew 4.x and later versions), special application permissions are required.

Brew environment requires timely handling of events. In short, if the application fails to return at the appropriate time after the handleevent () call is executed, the aee may close the application to protect other requests from the device. Some operations, such as reading data from a network socket, may take a long time and cannot be completed within a single call event processor. The callback mechanism is used to notify the application after the operation is complete.

4.3.2.1 event Processor
The aee execution environment calls the BREW application's event processor to send messages about a series of events. Readers who have had windows programming experience will understand this mechanism. In Windows, Message Processing Mechanism: When an operation (signal, input, and so on) is performed in the interaction, Windows will generate corresponding events, through the event distribution mechanism of window, the corresponding window or application obtains the event to trigger the corresponding event processor for processing. The event processing mechanism in brew is similar to that in brew. After an event is captured in the brew environment, it is distributed to the corresponding application or control for processing by the event processor of the application or control.

The following is an example of the event processor interface in brew:

Boolean myapp_handleevent (iapplet * piapp,

Aeeevent ecode,

Uint16 wparam,

Uint32 wparam)

In this example, the variable piapp actually specifies the application structure, that is, a pointer of aeeapplet. Many applications define their structures as supersets of aeeapplet, and piapp can also point to this structure.

The ecode variable indicates the type of events received by the application, such as evt_app_start, evt_key, and evt_alarm.

The wparam and dwparam parameters are short data and long data values defined based on the received events. These values depend on the event and are defined based on the event itself. For some events, short data and long data fields both contain event data. For other events, long data fields have only one field, or even no field. Events that do not contain data include evt_app_start, evt_app_stop, evt_app_suspend, and evt_app_resume. Typical events that contain data in both data fields include evt_dialog_start and evt_command. Typical events that only contain data in short data fields include evt_alarm. Typical events that only contain data in long data fields include evt_net_status and evt_ctl_changing.

The key event is sent to the application as an evt_key event. The short data field contains the primary key code. For example, if you press the key to conform to "2", it contains the primary key code avk_2. The value of avk_2 is defined by the header file aeevcodes. h.

In emulator, the primary key code corresponding to the key symbol is determined by the device configuration file, or can be modified through the device configurator. On mobile phones, the primary key code is determined by the device manufacturer.

4.3.2.2 event handling prompt
When executing an application, only the events that the application may need to handle are considered. Many events can be ignored. For example, if you want to execute a game application, you only need to use the up and down arrow keys, you can ignore the received 0-9 button events.

However, if you receive critical events, you cannot ignore them regardless of the state of the application. System events such as evt_start, evt_stop, evt_suspend, and evt_resume affect applications under any circumstances. Note that all critical events must be received regardless of the state of the application. Some events are sent only when such notifications are required for application instructions. The application must register these notification events. You can specify the notification event registration for the MIF file in the MIF Editor, or use ishell_registernotify () for Dynamic Registration.

As a convention, when an application processes any data allocated by evt_start, it should be released when processing evt_stop. However, the memory data allocated in aeeclscreateinstance () must be released through the freeappdata () mechanism.

4.3.2.3 event distribution and proxy
When the control is activated, the event should be passed to the activated control to make the Control Self-Update, also called the event agent. For example, if the menu control is active, the event should be passed to imenuctl_handleevent (); if the text control is active, it should be passed to itextctl_handleevent (), then the control will take the corresponding action. In the menu control, it will change the selected project and re-draw the menu.

Just as the event handler returns true or false to the aee execution environment, controls return true or false to indicate the events they process. Each control type only processes the necessary events. The standard menu control only processes "up", "down", and other key events, while the soft-key menu control processes "Left", "right", and other key events. If a control returns true from the issued event, the application can exit from the event processing function earlier, but can perform additional processing. If a control returns false from an issue event, the application should generally continue to process the event. If the control receives false from the event processor, brew performs the default processing.

When you press the "select" key, the menu control uses evt_command to notify the application. In this case, an evt_key button event from the "select" Key is handled by the menu control. In addition, for any view update of the menu control, the menu control sends the evt_command event back to the application. In fact, all control types can provide a proxy mechanism.

Aee Shell
 
My app
 
Imenuctl
 
 
 
 
 
 
 
 
 
All events
 
Key event
 
 
 
True/false
 
True/false
 

Figure 4-7: Event distribution example in brew

 

The event distribution proxy mechanism is very flexible, and you can freely process it as needed in the message loop (figure.

The user presses a key.
 
Events related to this key are transmitted

Event processing functions
 
You can give it

Imenuctl_handleevent ()
 
You can choose to process it first
 
You can also process it again.
 

Figure 4-8: Event proxy mechanism in brew

The difference between the Message Processing Mechanism in brew and the Message Processing Mechanism in Windows is that the brew architecture adopts the com method, that is, it has an object-oriented class hierarchy, the specific event processing mechanism is also used as interface functions exposed by each interface. An application is essentially an instantiated iapplet class. Therefore, all the event processing mechanisms used in the application are called interface functions exposed by each interface. Specifically, these event processors are different, mainly because of the differences between iapplet_handleevent and handleevent of other interfaces.

Iapplet_handleevent is registered and instantiated through the aeeapplet_new function in aeeclscreateinstance. The aeeapplet_new function instantiates the iapplet_handleevent by passing in the userapp_handleevent parameter.

In addition to iapplet handleevent, all interfaces that inherit iControl also have event processing functions that allow you to process events. There are two methods to call these specific icontrol_handleevents. One is explicitly called by the developer in the handleevent of the application, for example:

Switch (ecode)

{

Case evt_app_start:

Return (true );

Case evt_app_stop:

..........

Case evt_key:

Imenu_handleevent ....

Itextctl_handleevent ....

}

The other is that when these controls are included in the dialog box and in the focus state, the trigger of these event processing functions is implicit and is automatically triggered by the aee mechanism, you do not need to explicitly call these handleevents in the code. The idialog interface does not have exposed handleevent interface functions, but you can use idialog_seteventhandle to register an event handler function for this dialog box. It should be noted that when the event processing function is triggered: Once a dialog box is activated, the aee layer will send all the events directly to the dialog box, this dialog box automatically calls the handleevent of the focus control to process the event. Only when the control does not process the event will the event processing function registered in the dialog box be called.

After brew is run, the UI tasks in the operating system capture various events. In this case, the UI tasks distribute the events to the brew environment through aee_dispatch. The Brew environment then distributes events to the destination through the aee_sentevent. Different processes are implemented in two different cases.

If no dialog box is activated, the iapplet_handleevent is automatically called by brew to handle the event. At this time, the iapplet_handleevent called is actually the app_handleevent registered by the user. This allows your applications to capture and process events. In your app_handleevent, you can issue events. For example, you can call imenu_handleevent to send events to various controls for processing.

If an active dialog box exists, brew automatically calls the event based on the dialog box, so that the event is intercepted first in the dialog box. The processing after the dialog box is to check which of the included controls is in the focus, the event is sent to its handleevent for processing, and its return value is used to determine whether the event has been processed. When it returns false, the dialog box continues to forward the event to the handleevent registered in the dialog box (if any). If the handleevent still returns false, brew continues to forward the event to app_handleevent. This mechanism makes various events automatically processed when an application is created in the form of a dialog box, which simplifies the amount of code, but makes the event process even more obscure, your application cannot directly control it.

This article from the csdn blog, reproduced please indicate the source: http://blog.csdn.net/wireless_com/archive/2009/07/21/4365612.aspx