BREW is very event-driven. As such, an application will get many events that it may not be expecting. Controls talk to themselves using events. The system sends events to the application to tell it a variety of things about the state of the phone. All of these need some action taken by the application. Because of this, a well-designed event handler is required for a stable application.
It is the application’s responsibility to make sure all controls being used get the messages they require to function properly. It is not defined what all of the events are, so the best way to handle this is to take special action on those events you know about and may want to intercept occasionally (such as the arrow keys or CLR key) and have a default handler that passes everything else to any active controls to see if they can handle the event.
Handling the CLR key (event code of EVT_KEY with a wParam of AVK_CLR) is a special case in BREW. A well-designed application will have the CLR key behaving as a backspace when in text entry controls, as a back key to go back a screen, and exiting the application when on the main screen. This means an application needs to watch for it and perhaps do something special. If FALSE is ever returned from handling the CLR key, the application will exit. Except at the main screen, this is likely not the action you want the application to take.
One of the most important events to handle properly in any application is the suspend event (EVT_APP_SUSPEND). If an application receives this, it means that the phone wants to do something, such as notifying the user of a voice call or maybe an SMS message. QUALCOMM defines a bunch of things that an application must do before returning from a suspend event. These things including closing down all used sockets, stopping all timers, and deactivating all controls, among many other things. An application will not pass testing if these aren’t done.
