PART 2  PART 1

As we have seen in Part 1, The Mobile Information Device Profile (MIDP) is layered over CLDC, Connected Limited Device Configuration (see table in Part 1). The run time engine is called the KVM, and is intended to support mobile phones and entry level PDAs. A device that has the KVM embedded is capable of executing java programs.

The Mobile Information Device Profile (MIDP) specification released by Sun Microsystems is implemented as a set of APIs for software developers who wish to develop applications for devices such as the mobile phone. These APIs are covered under the name Java 2 Platform Micro Edition or, simply, J2ME.

J2ME is a subset of the Java 2 Platform Standard Edition (J2SE). Since the small screen device has inherent 
limitations in terms of memory, processing power and persistent storage, the J2ME is a scaled down version of the standard edition, with a new set of classes of its own.

Like the standard Java, the APIs are rooted in the ubiquitous Object class, from which a hierarchy of classes 
branch out to cover the display, persistent storage, network connectivity and the utilities.

The word often heard in connection with J2ME is a 'midlet', and like the applet that brought java to the web front, midlets are the java equivalents of the small device applications.

What is a midlet?
A midlet is to a mobile device what an applet is to a web browser. But this definition needs some qualification. While an applet runs inside a browser, the midlet runs on top of the KVM embedded in the device. A midlet or a group of midlets can launch an application, or the entire application functionality can be embedded inside a midlet. A midlet's properties can be set in a text file that has a .jad extension. This jad file makes the midlet known to the KVM, the java runtime environment in the device.

Here is a typical .jad file, containing name-value pairs:

MIDlet-Name: MidletClassName
MIDlet-Version: 1.0
MIDlet-Vendor: JavaNook
MIDlet-Description: Javanook MIDlets
MIDlet-Jar-URL: javanookmidlet.jar
MIDlet-Jar-Size: 3215
MIDlet-1: MIDlet1,/image1.png, MIDlet1
MIDlet-2: MIDlet2,/image2.png, MIDlet2 

A midlet suite is built in this manner, and packaged as a jar file for deployment in a device. When the midlet 
application is packaged as, say, midlet.jar file, it stores a manifest file (a .mf file) that carries the following 
information:

MIDlet-Name: MidletClassName
MIDlet-Version: 1.0
MIDlet-Vendor: JavaNook
MIDlet-1: MIDlet1,/image1.png, MIDlet1
MIDlet-2: MIDlet2,/image2.png, MIDlet2
MicroEdition-Configuration: CLDC-1.0
MicroEdition-Profile: MIDP-1.0

We will look at more details as regards these files in Part 3. Suffice it to say that a midlet is the backbone of the device application, and relies onthe KVM to execute its content.

Take a look at the following code snippet:

import javax.microedition.midlet.*;
import javax.microedition.lcdui.*;

public class MidletClassName extends MIDlet implements CommandListener {

   public MidletClassName() {
   }

   public void startApp() {
   }

   public void pauseApp() {
   }

   public void destroyApp(boolean unconditional) {
   }

}

If you are familiar with the applet code, you will notice that a midlet has a similar structure, what is called a life cycle. You would also notice that the coding style is similar to any java class that you wrote. There are the import statements, the 'extends' and 'implements' keywords, the class itself and the listener - it's all there. That is the key. Programming to the small device is no different from programming in the large, except that you have to work with a different set of APIs designed especially to run in the KVM environment.

...Continued...