The following development proposes help to avoid common errors and minimize the amount of time required for testing, debugging, and rewriting source code. The development proposal can avoid the following questions:
One: Problems caused by transplanting to the ARM environment from Windows
2: Problem on the target device, but it is not necessarily detected in Brew Simulator.
Three: Routine effective operation
By studying and implementing these guidelines, you can minimize the total amount of time from Windows to ARM, and make the application running normally on the mobile device.
First: Perform a NULL pointer check.
Execute inspections in both cases:
You must check the NULL pointer when you create a BREW interface instance. If the pointer is incorrect, the interface will not be available.
Check all the pointers that have been transferred and returned by the memory or allocated memory to ensure their validity. The invalid pointer should be processed using an exception handling mechanism.
SECOND: Avoid stack overflow.
Do not put large groups on the stack. Do not declare the large groups or variables as local variables in the function, because the stack size of the BREW environment is limited. If a large amount of memory is required (for example, greater than 256 bytes), dynamic memory assignment operators, such as Malloc or IHEAP. If the assignment is in a recursive routine, the buffer is dynamically allocated. If the function in the stack is called, the stack of the previously stack buffer is monitored.
Third: Do not write a compact cycle.
Using a compact loop can cause the target device to be automatically reset. Therefore, don't write a compact cycle that requires a large amount of time processing applications. This prevents other events from passing to the application, thereby avoiding device reset. When an event is received, the application will process the required processing, then returned from the event such that other events can be sent to the application.
FOURTH: Sight for applications and equipment.
To ensure that the application can perform on any target device independently of the memory size, keyboard, screen size, and color depth, use iShell_GetDeviceInfo () to get instructions from the target device. Use this result to specify parameters such as display, buttons, and multimedia without hardcoding these parameters. Use the CONVERTBMP routine to process images on different devices.
FIFTH: Use resources.
Use resources to store strings, dialogs, and bitmaps for specific languages. This helps localize the application to move it from a language target device to another language target device. Do not hardly encode information on these types in the source file.
Sixth: Clear memory.
Since the available memory on the target mobile device is limited, unused memory must be released. Release memory in both cases:
1: All instances of the created object must be released.
2: When the application terminates, all dynamic memory must be released (all allocated memory).
3: It is recommended that you release it when you don't need memory.
Seventh: Do not use global or static variables.
The BREW structure does not support global or static variables because dynamic downloaded applications cannot process these data types. In addition, using globally or static variables may cause a target error in the connector. Always store lasting data in the small program structure.
EIGHTH: Do not initialize the structure when the structure is defined.
For the ARM compiler, the definition and initialization structure is considered static data. Please refer to "Do not use global or static variables".
NINTH: Do not assign variables within the conditional statement.
Such problems should be avoided using the ARM compiler. Don't write assignment code in the conditional statement.
TENTH: Do not use the original floating point operation.
The same as the above "Do not use global variables"; here include type conversion. Floating point calls provided in the Assistant function using BREW.
Eleventh: Use the standard library function provided by BREW.
Due to the RAM restriction on the target device, you need to control the compiled code size to the minimum, so you should use the BREW subset of the standard C library function (if available), not to use the standard library function.
Avoid the type forced conversion error.
Since the ARM compiler handle implicit type conversion is strict than most Windows compilers, it is clearly declared type conversion. This avoids compilation errors when converting from Windows SDK to an ARM environment.
Check the return value.
When you call the BREW API method with the return value, the return value of success and failure should be handled.
Handling error code.
Some functions may return Void, so the BREW API getLastError () mechanism should be used to identify errors.
Document and directory name.
In the BREW version 3.0, BREW supports the name and directory of case sensitive. Specifically by using the IFilemgr API's FS: Naming Rules to support case-sensitive file access. For more information, see the BREW API Reference Information Online Help. Afterwards, please make sure the following:
The MIF file name and the applet must fully match (including case you use the old name rules (ie, not an FS :) access file, you must ensure that the file name used in the application must be named with the file on the disk. It is exactly uniform (for lowercase). When using this rule, your application will not be able to access files and directories that use hybrid case names on disk.
If you want to use the files and directories of the hybrid name, you must use the FS: Name Rules.
If you are developing an application that is lower than Brew version of Brew 3.0, follow the rules:
BREW only supports files and directories using lowercase names. Therefore, make sure that only the files and directories of lowercase characters are used. BREW API 1.0.1.x version and later use the case-sensitive case in a transparent mode of application developers. Do not use a file name with two dots (.) Or a database name with a dot (.). These characters cannot be used due to unknown issues.
Minimize code size.
To minimize the size of the code, disable the debug information option before loading the application to the target device.
Set warning level.
When compiling an application in Windows, the warning level should be set to the highest level, namely 4. This operation helps to check the code more fully. Since the ARM compiler is more stringent than the Windows compiler in indication errors, it should ensure that the application can successfully compile the ARM target.
Combination multiple read and write.
By combining multiple read and write operations (if possible), the efficiency of reading and writing files can be fully improved. Read the data into the buffer and access it when you need it.
