Brew advanced and proficient-3G mobile value-added business operation, customization and development-62-principles in BREW application development

In brew-based mobile value-added business development, following certain development principles helps avoid common errors and minimize the time required for testing, debugging, and rewriting the source code, improve system development efficiency. By studying and implementing these guiding principles, you can minimize the total amount of time you have switched from windows to the arm framework, and make your applications run properly on mobile devices as much as possible. These development principles are as follows:

(1) perform the NULL pointer check. When creating a brew interface instance, you must check the NULL pointer. if the pointer is incorrect, this interface cannot be used. Check all pointers passed and returned by the allocated memory to ensure its validity. Invalid pointers should be handled using an exception handling mechanism.

(2) Avoid stack overflow. Do not declare large arrays or variables as local variables in the function, because the stack size available in the aee environment is very limited. If you need a large amount of memory (for example, greater than 256 bytes), use the dynamic memory allocation operator, such as mallqc or iheap.

(3) do not write compact loops. Using a compact loop will automatically restart devices on some target phones. Therefore, do not compile a compact loop that takes a lot of time to process a single event in an application, but adopt an event notification or callback mechanism. This prevents device resetting. When an event is received, the application processes it and returns it from the event so that other events can be sent to the application.

(4) applications are not related to devices. To ensure that the application runs on any target device independently of the memory size, keyboard size, screen size, and color depth, use ishell getdevicelnfo to obtain instructions from the target device. Use this result to specify parameters such as display, buttons, and multimedia, instead of directly coding these parameters in the application.

(5) use resource articles. Using resources to store strings, dialogs, and bitmaps in a specific language helps applications to be localized and internationalized, that is, to facilitate the migration of target devices from one language to target devices in another language, instead of directly encoding these types of information in the application.

(6) Clear the memory. Because the available memory on the target mobile device is very limited, unused memory must be released. In either of the following situations, the memory needs to be released: first, all instances of the created object must be released. Second, when the application is terminated, all dynamic memory (all allocated memory) must be released and can be released in a timely manner when no memory is needed.

(7) do not use global or static variables. The Brew structure does not support global or static variables (Global or static variables are supported in Versions later than 4.x) Because Dynamically Loaded applications cannot process these data types. In addition, the use of global or static variables may cause a target error in the connector. Therefore, we recommend that you always store persistent data in the main structure of the application.

(8) do not initialize the structure when defining the structure. The structure defined and initialized by the arm compiler is considered as static data.

(9) do not assign variables in the Condition Statement. This type of problem should be avoided when using the arm compiler. do not compile the code with a value assignment statement in the Condition Statement.

(10) do not use the original floating point operation (the use of the original floating point operation is supported only in Versions later than 4.x ). Similar to "do not use global variables", type conversion is included here. We recommend that you use the floating point function call provided in the Helper function.

(11) try to use the standard library functions provided by brew. Due to ram restrictions on the target device, you need to minimize the size of the compiled code. Therefore, use the brew subset of the Standard C library function (if provided ), instead of using standard library functions