Brew Background Application Development

Overview Overview

Brew applications can be grouped into 3 categories: active, pending, and background; an active or suspended application resides in the application stack, which is used by brew to manage the application in progress. The top of the stack is the active application, which is the only way to interact with the user directly via screen replacement or user events, and suspend the application to some extent under the current active application stack.

Because multiple applications may be in a pending state, developers should try to ensure that the resources in the suspend program are minimized. Applications in stacks can be suspended or activated by suspend or resume.

In the brew2.0 version, it involves the development of background applications. The background application does not reside on the application stack, that is, it does not change the state of the operation according to the suspend or activate event. In contrast, background applications, once initialized to run, are always in operation, and are not affected by user direct delivery instructions.

Starting/ending Start and end

When the background application starts to initialize, it is also like other normal brew applications, it can be started directly from the Brew application interface, or it can be started by using the Ishell_startapplet function in other brew applications.

To put a brew application in the background, brew application must set the value of Dwparam to false when handling evt_app_stop events; This way, after the Evt_app_stop event is processed, the brew application is run in the background, and the background application becomes brew for normal use, and the application itself must be activated by running the Ishell_startapplet function themselves.

As we know from the foregoing, it can be difficult to terminate a background application because they cannot accept any keystroke events directly, so there are two ways to end a background application: The background application terminates itself after a scheduled task has been successfully executed, or it ends the application by sending an event via a separate application. The specific use of the following three kinds of methods:

Other applications use Ishell_sendevent or Ishell_postevent functions to send events (Ecode value greater than Evt_user) to notify the end of the backend application;

The background application terminates the background application through the Ishell_closeapplet function after the task is done. Depending on the help of the API, activating a function that calls Ishell_closeapplet (Pishell, TRUE) for this parameter will close all executing programs and return to the standby interface. However, when invoked by an activation application, this operation does not affect the program outside the application stack;

The application activates itself by invoking the Ishell_startapplet function so that user events can be accepted normally;

Suspend/resume hangs and restores

Because background applications reside outside the application stack, they are not affected by the hang and recovery time. Background applications are activated to handle suspend and restore times, and can be activated by events sent by itself or by other programs.

Event handling Incident handling

When the background application is running, it cannot accept key events. However, many background applications can use event handling to interact with other activation applications, which allows curves to control background applications. In this case, the activation application can use the Ishell_sendevent () or Ishell_postevent () method to notify the backend application to react accordingly.

Limitations Limitations

The main limitation of background application is that the screen information cannot be modified and communicated directly to the user unless it is activated. In addition, developers should pay attention to the background application of the operating environment of limited resources. This is extremely important for the background because there may be multiple backgrounds running at the same time. Moreover, the equipment running the background application will require more power support, which may lead to the inability to enter the trusted mode;

As a result, long-term background applications should avoid harmful effects on the battery life of the equipment. Some OEM vendors may limit the performance of the backend application, for example: When running background, it will not be able to use the socket or play a beep.