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

}
}
public void setStringAt (String newText, int newIndex) {
try {
byte[] newData = newText.getBytes();
store.setRecord (newIndex+1, newData, 0, newData.length);
}
catch (Exception e) {
throw new RuntimeException (e.toString());
}
}
public int size() {
return size;
}
public void close() {
try {
store.closeRecordStore();
RecordStore.deleteRecordStore (storeName);
}
catch (Exception e) {
throw new RuntimeException (e.toString());
}
}
}
Distributing Functionality over Several Small MIDlets
Another way to save memory is to distribute the functionality of an application to two or more
smaller applications in the same MIDlet suite. This approach seems especially feasible if the
application consists of mostly independent building blocks, which only share their persistent data.
An example could be any loosely connected client application, mainly operating on a local
database, but synchronizing data with a server from time to time. Instead of integrating the
synchronization in the main application, it can be moved to a separate application. Thus, the size
of the main application can probably be reduced significantly. Other parts of the application, such
as configuration dialogs, can probably be spun off as well.
Please note that you can split MIDlets only if all the applications are stored in the same suite;
otherwise, they can't share their persistent data.
Fragmentation Problems
A frequent problem for J2ME applications that are running on a KVM implementation without
compacting garbage collection is a memory paradox: Runtime.freeMemory() reports lots of
free memory, but a memory allocation following immediately fails and causes an
OutOfMemoryException .