BREW development guidelines
--------------------------------------------------------------------------------
The following development guidelines are provided to help you avoid common mistakes and minimize the amount of time you spend testing, debugging, and reworking your source code. The guidelines identify the following:
Issues that cause problems in transitioning from Windows to the ARM environment
Issues that cause problems on the target device, but cannot necessarily be detected in the BREW Emulator
General good practices
By reviewing and implementing these guidelines, you should be able to minimize the overall transition time from Windows to ARM and maximize the success of your application running correctly on the mobile device.
Development guidelines Description
Perform NULL pointer checks. There are two situations, as follows:
You must check for NULL pointers when you create an instance of a BREW interface. If the pointers are not correct, the interface cannot be used.
QUALCOMM recommends that you check all pointers, both passed and returned from BREW methods or allocated memory, to ensure their validity. Invalid pointers should be handled with an exception handling mechanism.
Avoid stack overflow. Do not have huge arrays on the stack. Do not declare huge arrays or variables as local variables inside functions, because the stack size available to the BREW environment is limited. If substantial memory is needed (for example, greater than 256 bytes), use the dynamic memory allocation operators such as MALLOC or use IHeap.
If the allocation is in a recursive routine, dynamically allocate your buffers. If the function is deep in a call stack, monitor the stack for prior large stack buffers.
Do not program tight loops. Staying within a tight loop could cause the target device to reset itself. For this reason, do not program tight loops in which a lot of time is spent processing a single event in an application. This prevents other events from being posted to the application and eventually causes the reset.
When an event is received, applications do the required processing and return from that event. This enables other events to be sent to the application.
Strive for device independent applications. To ensure that your application can execute on any target device independent of memory size, keypad, screen size, and color depth, use ISHELL_GetDeviceInfo() to get specifications from the target device. Use the results to specify parameters such as display, key, and multi-media. Do not hard code these parameters.
Use the CONVERTBMP routine to deal with images on different devices.
Use resources. Use resources to store language-specific strings, dialogs, and bitmaps. This helps localize the application and move it from a target device in one language to a target device in a different language. Do not hard code these types of information in the source files.
Clean up memory. Since the available memory on the target mobile device can be limited, you must free unused memory. There are two situations as follows:
You must release all instances of objects you create.
You must release all dynamic memory (all allocated memory) when an application terminates.
QUALCOMM recommends that you free memory when it is no longer needed.
Do not use global or static variables. The BREW architecture does not support global or static variables, because these types of data cannot be handled by an application that is dynamically downloaded. Additionally, the use of global or static variables causes a linker error on the target. Always store persistent data in the applet structure.
Do not initialize a structure when defining it. From the perspective of the ARM compiler, defining and initializing a structure is considered static data. See above "Do not use global or static variables.”
Do not assign variables inside conditional statements. Avoid problems with an ARM compiler. Do not write code that assigns values inside conditional statements.
Do not use native floating point operations. Same as above for "Do not use global variables”; this includes typecasting.
Use the BREW-supplied floating point calls in the Helper functions.
Use BREW-supplied standard library functions. To keep your compiled code size to a minimum because of RAM limitations on a target device, use the BREW subset of standard C library functions when supplied rather than the standard library functions.
Avoid typecasting errors. Because the ARM compiler handles implicit typecasts more strictly than most Windows compilers, explicitly declare typecasts. This avoids compilation errors when transitioning from the Windows SDK to the ARM environment.
Check return values. When calling a BREW API method that returns a value, handle both successful and failed return values.
Handle error codes. Because some functions return void, wherever applicable, use the BREW API GetLastError() mechanism to identify the error.
Use lower case file and database names. Because the EFS in the QUALCOMM ASIC is case sensitive, use lower case file and database names. BREW API releases 1.0.1.x and later handle the case sensitivity issue transparently to the application developer.
Do not use a filename with two dots (.) or a database name with one dot (.). These characters cannot be used due to a known problem.
Minimize code size. To minimize the size of the code, disable the debug info option before loading the application onto a target device.
Set the warning level. Set the warning level to the highest, level 4, while compiling the application on Windows. This action helps you do a more thorough check of your code. Because the ARM compiler is stricter in indicating errors than the Windows compiler, you ensure that your application compiles smoothly for the ARM target.
Combine multiple reads and writes. To improve the overall efficiency of reading and writing files, by combining multiple read and write operations, where possible. Read the data into a buffer and access as needed.
扫一扫
1352
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
