Size Does Matter: Optimizing J2ME Applications - Java 2 Micro Edition Application Development - page 200

This issue was especially problematic with early versions of the SUN KVM. The SUN KVM now
provides a compacting garbage collector, so this problem seems less important. However, some
KVM implementations may not provide a compacting garbage collector for some reason, so you
should at least know about the characteristics of the problem.
The reason for the discrepancy between the return value of Runtime.freeMemory() and the
ability to allocate a certain block of memory is usually a fragmentation problem: Lots of memory
is available, but only in very small pieces. Runtime.freeMemory() reports the total amount of
memory available, but the largest continuous block of memory may be much smaller.
The garbage collection for J2SE is usually implemented using a compacting algorithm—all
memory blocks that can be reclaimed are compacted to a single large block of memory. In the
KVM, free memory blocks are reclaimed, but the compaction step may be omitted for
performance and complexity reasons. Thus, a fragmentation problem may occur when a lot of
small memory blocks are allocated. Even if most of the small blocks can be reclaimed during
garbage collection, the remaining blocks may fragment the free memory into several small pieces.
Although no general solution exists for the fragmentation problem, it may help to call the garbage
collector explicitly at some points in the program. Explicit calls of Runtime.gc() will force a
garbage collection before all the memory is used up. Thus, only part of the memory is fragmented.
New memory allocations are served from the small chunks before the remaining block is touched.
Please note that explicit calls to Runtime.gc() may help, but will not do so in all cases,
depending on the concrete memory consumption behavior of the application and on the total
amount of memory available on the device.
User Interface Issues
Compared to the desktop, the screen space available on MIDP devices or even PDAs is very
limited. This limited space requires a careful user interface design. Also, the situations in which
mobile devices are used are different. Whereas desktop applications are normally used for a longer
period of time, mobile applications are usually used for just a few seconds, but more frequently.
Thus, access to the desired information should be fast and navigation as simple as possible.
It should also be possible to leave the application at any point without loss of data. The reason is
that in mobile application scenarios, the user may want to switch or leave applications quickly—
for example, to answer an incoming call, when the subway reaches the destination station, or when
the airplane pilot asks passengers to switch off all electronic devices during landing. Thus, nested
dialogs should be avoided.
The built-in Palm Pilot applications provide very good examples for appropriate PDA user
interface design. Before designing your own applications, it makes sense to look at some other
typical PDA or MIDP applications, in order to get a feel for their design.
MIDP
The MIDP UI was designed for limited screens from the beginning, so it's difficult to give general
hints for improvements that don't depend on the individual application.
Because of the limited screen size, you'll often need to distribute the user interface to several
screens. Although commands provide one possibility to switch between forms, an important
alternative for selecting actions is to use a List in the IMPLICIT mode. Selecting a command
may require going to a submenu if the key mapping is not sufficient, but the list is always