Welcome Guest!
Create Account | Login
Locator+ Code:

FTPOnline Channels Conferences Resources Hot Topics Partner Sites Magazines About FTP RSS 2.0 Feed

FTPOnline Special Report: Mobile Java Development

email article
printer friendly
more resources

Efficient MIDP for Symbian-Based Devices
Apply best practices to overcome execution environment challenges when developing mobile Java applications.
by Martin de Jode

April 17, 2006

Writing code for mobile phones presents challenges you won't face when targeting the desktop or server: constrained memory, limited processor speed, restricted screen real estate, different user input paradigms, and so on. So when developing mobile applications you should concentrate on techniques to cope with limitations in the execution environment because of constraints in memory and CPU cycles on mobile phones.


The exact hardware resources obviously vary from phone to phone, with high-end smartphones having more resources than mid- or low-range phones, but ballpark figures would be a processor clocking in at the order of 100 MHz (compared to GHz on the desktop) and RAM measured in terms of a few MB (rather than hundreds of MB for a PC).

The focus here is on efficient MIDP rather than optimized MIDP because many of the tips introduced in this discussion are concerned with efficient coding style rather than genuine optimizations. As such they should be adopted as standard practices, with the additional benefit of improved performance.

Various platforms were used to evaluate the practices recommended here: Sun's Wireless Toolkit 2.2—running Sun's K Virtual Machine (KVM)—on Microsoft Windows 2000; a Sony Ericsson P800, which runs Sun's KVM on Symbian OS; a Nokia 6600, which runs Sun's CLDC Hotspot Implementation on Symbian OS; and a non-Symbian OS, Series 40 Nokia 6620 (details not available) representing midtier phones. (See "Evolving the Symbian OS" for more information about key new features in Symbian OS version 9.)

A key part of any optimization is identifying the performance bottlenecks. The Wireless Toolkit provides various profiling aids that allow you to trace class loading, method calls, memory usage, and garbage collection, among other things. The toolkit can be useful for identifying potential bottlenecks, but there is no substitute for on-target profiling, which generally has to be done by hand by bracketing potential trouble spots with methods such as System.currentTimeMillis() and Runtime.freeMemory(). Note that the virtual machines (VMs) running on Symbian OS support a dynamic heap, so runtime freeMemory() might give unexpected results if the VM has just made an extra allocation of memory to the heap.

Accessing Attributes
Let's get started by looking at field access. Generally, it is accepted wisdom that accessing an object's field directly is more efficient than using access methods (getters). In other words, you would use this code:

String firstName = 

rather than this code:

String firstName = 

On the Wireless Toolkit, tests showed this preference to be the case, with direct field access being about 10 times quicker. However, running tests on phones showed different results. On the Nokia 6620 times were identical for direct field access compared to using an access method. For the KVM-based Sony Ericsson P800, using an access method was about 20 percent slower than direct field access, whereas for the CLDC HI-based Nokia 6600, using an access method took about double the time compared to direct field access (although in terms of absolute time it was the fastest phone in the sample group).

In all cases, accessing object fields using access methods occurred on sub-microsecond time scales. So the message is: Don't abandon good programming principles by making all object fields public, because with modern optimized VMs you will gain little to nothing.

Back to top

Java Pro | Visual Studio Magazine | Windows Server System Magazine
.NET Magazine | Enterprise Architect | XML & Web Services Magazine
VSLive! | Thunder Lizard Events | Discussions | Newsletters | FTPOnline Home