Challenges of mobile J2ME development
Michael Juntao Yuen
05.05.2004
Rating: --- (out of 5)
|
The most visible difference between the mobile and PC platforms is the difference in computing hardware. Today's PCs have much faster CPUs and far more memory and storage spaces than any mobile computing devices. Desktop and server developers can afford the luxury to write applications with bloated features (e.g., Microsoft Office); they also have access to rich productivity features provided by large, all-in-one frameworks (such as the J2SE platform itself). However, on mobile devices, it is a completely different story. With CPUs as slow as 20 MHz and RAM as little as 100 KB, we must carefully evaluate the features we need, thoroughly optimize our code, and live with limited framework support. In this section, we discuss how to cope with those challenges.
Reduce application footprint
Pervasive mobile devices have extremely limited memory and storage spaces, requiring us to minimize both the storage and runtime footprints of the application. Specific suggestions are as follows:
- Optimize the packaging process: Even after carefully choosing the best lightweight library, we may still find that the application utilizes only part of the library. In the packaging process, we should include only the classes we actually use. We can do this manually for smaller libraries or use automatic tools bundled with some J2ME IDEs (such as the IBM WebSphere Studio Device Developer) for large libraries. If you want to further reduce the binary application size, you can use a bytecode obfuscator to replace long variable names and class names with shorter, cryptic ones.
- Partition the application: Since the MIDP runtime loads classes only as needed, we can partition the application into separate parts to reduce the runtime footprint. For MIDP applications, the MIDlet suite can contain several relatively independent MIDlets.
Although the standard MIDP specification does not support shared libraries, some vendor-specific implementations do. An example is...
To continue reading for free, register below or login
To read more you must become a member of SearchMobileComputing.com
the BlackBerry Java Development Environment (JDE) for BlackBerry handheld devices. A shared library further reduces the overall footprint, since the library no longer needs to be duplicated and packaged in each application.
Minimize the garbage collector
One great advantage of Java is the built-in garbage collector that automatically frees memory space used by stale objects. This allows developers to focus on the core logic rather than on mundane details of memory management. As a result, Java developers are usually unconcerned about object creation. In fact, many popular Java design patterns promote the idea of creating more objects in exchange of more maintainable code. For example, in the Sun Smart Ticket (Chapter 5) sample application, the use of the MVC and facade patterns results in many objects that simply delegate the action to the next layer. To get a feel for this problem, just look into the numerous classes that implement the RemoteModel interface.
But on mobile devices, due to the small amount of available memory, the garbage collector must run more often. When the garbage collector runs, its thread takes up precious CPU cycles and slows down all other application processes. For effective J2ME applications, we need to minimize object creation and quickly dispose of objects that are no longer in use. Specific suggestions are as follows:
- Carefully examine design patterns in early stages of the development cycle. For example, the screen flow-based approach demonstrated in the iFeedBack sample (Chapter 3) results in many fewer objects than a traditional MVC implementation.
- Concisely reuse existing objects at the implementation level. For example, if a same button (e.g., the DONE button) appears in many screens, we should create it once and reuse it.
- Use arrays and StringBuffers. Arrays are much faster and more memory efficient than collection objects. When we modify or concatenate strings, the immutable String objects result in a lot of intermediate objects. The StringBuffer is much more efficient.
- Close network connections, file handlers, and Record Management System (RMS) record stores quickly after use.
- We need to look over the documentation carefully to find out all the close(), destroy(), and dispose() methods and use them judiciously. It is usually considered a best practice to place those methods in the finally block to make sure that the resources are released even if runtime exceptions are thrown.
Read more about the challenges of mobile development at InformIT.
|
|
|
|
|
|
