As mobile phones increase in capability, MIDlets tend to grow in size in order to hold an increasing number of images, sounds and other resources. For example, the maximum JAR size for the T610 is about 500KB, while newer phones like the K500 series and the K700 series can install and run MIDlets with JAR sizes that are megabytes in size.

More space for images and sounds paves the way for greater game experiences, but downloading large MIDlets may be restricted. The restriction is controlled by the network, not by the phone. The maximum size of a transfer through the network is often restricted to <200KB for GSM/GPRS networks and slightly higher for 3G networks. Stated in another way, larger JAR files simply won't download on some networks.

While it's recommended to keep your games within specific size limits, MIDP 2.0 offers a way to work around such restrictions. What you need to do is take advantage of the fact that when you replace a MIDlet with another one with the same name, the first MIDlet's RMS database can be kept untouched; provided the user accepts it when prompted. This capability allows the installation of an updated version of a MIDlet without losing any previously stored user data.

What we'll do is split our big MIDlet into two and use the same name for both. The second MIDlet is the actual game code, minus some memory consuming resources. These resources are instead put in the first MIDlet. This first MIDlet's only function, besides carrying the resources, is to put the resources into the RMS and then call

public final boolean MIDlet.platformRequest(String URL);

with the parameter URL set to the JAD of the second MIDlet. After this call, the MIDlet should be stopped. The JavaDoc for platformRequest states that this might be needed: "On some platforms, the currently running MIDlet suite MAY need to be stopped before any installations can occur". A call to

public final void notifyDestroyed()

will take care of this.

These two calls will stop the first MIDlet and start the download of the second one. Upon installation, the user must confirm that he wants to replace the MIDlet with a new one with the same name and then answer "Yes" to a security prompt: "The new version may be from another source. Trust Source?"

The second MIDlet will then replace the first one, but when running, it can still use the resources stored in the RMS created by the first MIDlet.

This technique requires a way to store resources as bytes in the RMS and a way to recreate the resource from these raw bytes. A quick look at the Javadoc for Image gives us the two useful methods:

public int GetRGB(...);
public createRGBImage(...);

The first method can be used to transform an image in the first MIDlet to a series of bytes that can be stored in the RMS and the second method can be used by the second MIDlet to do the opposite, that is, create an image from the stored bytes.

In the downloadable .zip file there is an example of this technique. The first MIDlet stores a PNG image in the RMS and then installs the second MIDlet. The second MIDlet simply reads the RMS and displays the PNG image on the screen.

To run the example: Put the second MIDlet on a web server. Edit the first MIDlet's Java file (TwoJarMIDlet1.java) and change the line:

private static String  PLACE_OF_SECOND_JAD = "http://myWebServer/TwoPartJarMIDlet.jad ";

to point to the second MIDlet's JAD. Build, install and run the first MIDlet.

If you don't have access to a web server, you can still run the example. First transfer the first MIDlet to the phone using USB cable, Bluetooth or infrared, then start the MIDlet but answer "No" when the phone wants to access the Internet. Then transfer the second MIDlet and start it. Obviously this will not test the JAD file.

Download Two-Part MIDlet example>>