Java Tips, Tricks & Code

It's quite common to have all small images used in a MIDlet put together as one big image that's loaded at the MIDlet startup. The smaller images are then extracted and used as individual images using code like:
 
Image smallImage1=bigImage.createImage(0,0,16,16);
Image smallImage2=bigImage.createImage(16,0,16,16);

Don't forget to release your resources
Most of the time, this is perfectly okay to do (see below for the exception) as long as you make sure that the big image is de-referenced as soon as all smaller images have been extracted and that the big image is no longer used. This will be done automatically when leaving the method where bigImage is declared, the problem being that such variables are often declared as instance variables and not inside any method. In this case you can easily de-reference it explicitly by the line
bigImage = null;

If you fail to do this, you will end up with your images allocating twice as much memory as is needed.

And what about the exception? The Sony Ericsson Z1010 and V800 phones have a specialized image memory of about 80Kb for the fastest possible access, which you can read more about in "Graphic memory on the Z1010".

What's important to know is that the phone won't try to optimize the usage of this memory area, meaning that it won't move images already stored in other memory areas to this fast area when, for example, the fast access area gains free space due to garbage collection. This can lead to the case were the big image is stored in the fast memory, but the area isn't big enough to also store the smaller images. They are then instead stored in the slower access memory. Even after the big image has been de-referenced and the garbage collected, the small images will stay in the slower access memory, resulting in unnecessary slow access time. On the other hand, if the big image is too large for the fast access area, it will be stored in the slower access area and the small images will end up in the fast memory.

More image optimization tips can be found in "Optimization of Z1010 image handling".

Manage the alpha channel
Transparency data in images are stored in the images' so called alpha channel. The alpha channel can be 1 or 8 bits per pixel, depending on the image format. If transparency only is used in a simple on/off fashion in the image, it's strongly recommended to save the image with 1-bit alpha, as it then draws much faster to the screen.

StartApp() can be called multiple times
StartApp() is not only called when the MIDlet is started, but also every time the MIDlet resumes from the paused state. This will for example, happen when a call that has interrupted the MIDlet ends. This means that you should be careful with your resource management in startApp and make sure that you don't reload resources and create objects you've already created. A simple check like this may be enough:

protected void startApp(){
  If (!started){
    // init objects, load resources
    started = true;
  }
  // do stuff that's neccesarry everytime startApp runs
}