Helping You Pass the Sun Certified Mobile Application Developer Certification

Although configurations are at the heart of Java 2 Micro Edition (J2ME), it's the profiles that are of real interest. Profiles define the application programming interfaces (APIs) that are required to write useful applications for a particular group or family of J2ME devices. The Mobile Information Device Profile (MIDP) defines a Java runtime environment for cellphones, interactive pagers, and similar mass-produced, resource-constrained handheld devices.

Mobile Information Devices

MIDP is targeted at a class of devices known as mobile information devices (MIDs). These are devices that have the following minimal characteristics:

• Enough memory to run MIDP applications (see below)
• A bit addressable display at least 96 pixels wide by 56 pixels high, either monochrome or color.
• A keypad, keyboard, or touch screen.
• Two-way wireless networking capability.

Almost any wireless device built these days fits the definition of a MID, including low-end cellphones. Personal digital assistants (PDAs) can also be considered to be MIDs because wireless networking is now an option for most PDAs, but MIDP doesn't target these devices specifically: PDAs have more memory, larger screens, and interesting information management capabilities that are more effectively exploited using other profiles.

The MIDP Specification

There are two versions of the Mobile Information Device Profile, both defined using the Java Community Process (JCP). MIDP 1.0, known as Java Specification Request (JSR) 37, was released in September 2000. MIDP 2.0, JSR 118, is currently in proposed final draft form, the final step before formal release as a final specification. No devices yet support MIDP 2.0, but there are many devices currently on the market that support MIDP 1.0. We'll concentrate solely on MIDP 1.0 for now, deferring discussion of MIDP 2.0 until later in this series.

The MIDP 1.0 specification was defined by an expert group consisting of all the major players in the wireless and handheld device arena, including familiar names like Motorola, Nokia, Ericsson, Research in Motion, and Symbian. It has a lot of support in the telecommunications industry, and handset manufacturers like Motorola and Nokia in particular are devoting a lot of development effort to supporting MIDP in a wide range of their devices.

The configuration used by MIDP is the Connected Limited Device Configuration (CLDC), which we've already discussed in a previous article in this series. The CLDC has the small footprint required to run on low-end devices. Devices that are capable of running the other configuration, the Connected Device Configuration (CDC), can also run MIDP, of course, since the CDC is a superset of the CLDC.

The MIDP adds APIs in a number of areas to the very basic APIs defined by the CLDC. The new features include:

• Support for application lifecycle management similar to the way applets are defined in Java 2 Standard Edition.
• Persistent storage of data.
• HTTP-based network connectivity based on the CLDC's Generic Connection Framework.
• Simple user interface support, with enough flexibility to build games or business applications.

The MIDP specification is silent about a number of things, however. For example, in MIDP 1.0 there is no standard way to interface to the device's phonebook, if it has one, in order to initiate voice calls. There are no standard facilities for data synchronization, even if the device supports the feature. Device manufacturers can and do provide their own device-specific APIs for these kinds of features, though, but using them limits your application's portability.

Note that the MIDP specification is particularly silent in one area: how MIDP applications are loaded onto a device and how they are activated or deactivated. As such, different devices will do these in different ways. The MIDP specification basically concerns itself with what the application does once it's running, not how it's activated.

MIDlets and MIDlet Suites

As mentioned, MIDP defines an application lifecycle model similar to the applet model. In fact, MIDP does not support the running of traditional applications that use a static main method as their entry point. Nor can MIDP applications call the System.exit method in order to terminate. MIDP applications must follow specific packaging rules.

A MIDP application is referred to as a MIDlet. Its entry point is a class that extends the javax.microedition.midlet.MIDlet class, much in the same way that an applet extends the java.applet.Applet class. This class is referred to as the MIDlet's main class. The MIDlet class defines abstract methods that the main class implements: these methods are called by the system to notify the MIDlet that its state is changing. For example, whenever the MIDlet is being activated its startApp method is called. Again, this is very similar to the way applets behave.

Here is the code for a very basic MIDlet, drawn from Chapter 3 of Mobile Information Device Profile for Java 2 Micro Edition:

// A trivial MIDlet
package com.developer.j2me;

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

public class MyMIDlet extends MIDlet
                      implements CommandListener {

    private Display display;
    private Command exitCommand = new Command( "Exit",
                                               Command.EXIT, 1 );

    // Constructor, doesn't do anything really

    public MyMIDlet(){
        System.out.println( "MyMIDlet constructed" );
    }

    // Called when the system is destroying the MIDlet.

    protected void destroyApp( boolean unconditional )
                       throws MIDletStateChangeException {
        exitMIDlet();
    }
    
    // Called when the system is pausing the MIDlet.

    protected void pauseApp(){
        System.out.println( "MyMIDlet paused" );
    }
    
    // Called when the system is activating the MIDlet.

    protected void startApp() throws MIDletStateChangeException {
        if( display == null ){ // first time called...
            initMIDlet();
        }

        System.out.println( "MyMIDlet started" );
    }
    
    // Called to initialize the MIDlet. Executes only
    // once. Obtains the Display instance associated
    // with this MIDlet and creates a simple 
    // user interface for it.

    private void initMIDlet(){
        display = Display.getDisplay( this );
        display.setCurrent( new TrivialForm() );
    }
    
    // Called to exit the MIDlet. Centralizes all the
    // cleanup work.

    public void exitMIDlet(){
        notifyDestroyed();
        System.out.println( "MyMIDlet destroyed" );
    }

    // Event handling. Called by the system when the
    // user activates a command, normally by pressing
    // a button.

    public void commandAction( Command c, Displayable d ){
        exitMIDlet();
    }

    // A trivial UI screen. A titled blank screen
    // to which a single command is associated. The system
    // will map that command to a button or a menu item.

    class TrivialForm extends Form {
        TrivialForm(){
            super( "MyMIDlet" );
            addCommand( exitCommand );
            setCommandListener( MyMIDlet.this );
        }
    }
}

One or more MIDlets are packaged together into what is referred to as a MIDlet suite, which is basically a standard JAR (Java archive) file and a separate file called an application descriptor. All the user-defined classes required by the suite's MIDlets must be in the JAR file, along with any other resources (such as images) that the MIDlets require. The JAR file must also include a manifest with a number of MIDP-specific entries that describe the MIDlets in the suite. The application descriptor contains similar information, and is used by devices to obtain information about a MIDlet suite without having to download and install the MIDlet suite first.

Here is an example of the manifest that goes along with the simple MIDlet shown above:

MIDlet-1: MyMIDlet, MyMIDlet.png, com.developer.j2me.MyMIDlet
MIDlet-Name: MyMIDlet
MIDlet-Vendor: Eric Giguere
MIDlet-Version: 1.0
MicroEdition-Configuration: CLDC-1.0
MicroEdition-Profile: MIDP-1.0

And here is an example of an application descriptor for the same MIDlet:

MIDlet-1: MyMIDlet, MyMIDlet.png, com.developer.j2me.MyMIDlet
MIDlet-Jar-Size: 4238
MIDlet-Jar-URL: http://somewhere.foo.com/MyMIDlet.jar
MIDlet-Name: MyMIDlet
MIDlet-Vendor: Eric Giguere
MIDlet-Version: 1.0

These are only examples, of course, and we'll be discussing these in more detail as the series progresses.

Developing MIDP Applications

As the first J2ME profile to be released and to ship commercially, there are actually several MIDP programming tools available, often as add-ins for your favorite Java development environment. A development environment is not enough, however.

The reality of MIDP programming today is that the applications you can write are constrained in many ways. These constraints often require you to think about things that you wouldn't think of twice of with J2SE programming. Memory is a particularly scarce resource, for example. The early Motorola J2ME-enabled phones limited the size of a MIDlet suite to 50K (since raised to 100K on more recent models) and some Nokia phones limit them to even less, about 30K. Because MIDP 1.0 applications cannot share classes between suites, this really limits what you can do on the device. You'll find that placing part of your application in a web or application server (as a servlet, typically) that the MIDP application calls is almost a requirement for anything serious. This will change over time, of course, as memory limits are eased in newer devices.