Understanding J2ME Application Models

by Eric Giguere

The management of an application - how it's started and stopped, when it can access system
resources, how it discovers its initialization parameters - is shared between the operating
system (or other system-level software) and the application itself. The application
model defines how an application is managed and how management responsibilities are
divided between the application and the underlying system.

The Traditional Application Model

The simplest is the traditional application model. The entry point to the application is a static
method called main(), as in this example:

public class MyClass {

public static void main( String[] args ){
// application starts here
}
}

The class that defines this method is usually referred to as the main class. To start the
application, the Java Virtual Machine loads the main class and invokes its main() method. The
application runs until it terminates itself by calling System.exit() (if the security manager allows
the call) or until all non-daemon threads (including the one that started the application) have
terminated. For example, the following application can be stopped only by the operating
system, because it spawns a foreground thread that never terminates:

public class NeverEnding extends Thread {

public void run(){
while( true ){
try {
sleep( 1000 );
}
catch( InterruptedException e ){
}
}
}

public static void main( String[] args ){

NeverEnding ne = new NeverEnding();
ne.start();
}
}

1|P a g e
Although the operating system can terminate the application without notice at any time, the
application effectively has complete control over its life-cycle - when it terminates and when it
acquires or releases system resources. The application is really an unmanaged application;
the operating system participates only in its activation. If the operating system suddenly
terminates the application, the application may not have the chance to save its state or
release the system resources it has acquired.

For many purposes, the traditional application model works very well. Most interactive J2SE
and PersonalJava applications are unmanaged, terminating only at the user's direction. This
model works because the user can move or minimize application windows in order to access
other applications without having to shut down or pause the current application to free
system resources.

On the J2ME platform, the traditional application model is supported by both the Connected
Device Configuration (CDC) and the Connected Limited Device Configuration (CLDC),
although individual profiles may not support it. For example, the Personal Basis Profile and
the Personal Profile do, but the Mobile Information Device Profile and the Personal Digital
Assistant Profile don't.

2|P a g e
The MIDlet Model
A MIDlet is a Mobile Information Device Profile (MIDP) application. A MIDlet is a managed
application, it is managed by special-purpose application-management software (AMS) built
into the device. External management of the application makes sense in this context because
it may be interrupted at any point by outside events. It would be poor behavior, for example,
for a running application to prevent the user from answering incoming phone calls.

The MIDlet Life-Cycle

A MIDlet's main class extends javax.microedition.midlet.MIDlet . The main class defines three life -
cycle notification methods: startApp(), pauseApp(), and destroyApp().

There are three possible states in a MIDlet's life-cycle:

 paused: The MIDlet instance has been constructed and is inactive.

 active: The MIDlet is active.

 destroyed: The MIDlet has been terminated and is ready for reclamation by the
garbage collector.

Note that there is no equivalent to an applet's loaded state, because there is no initialization
method. Normally, a MIDlet initializes itself the first time its startApp() method is invoked.

MIDlets are created by the AMS, typically in response to a user request. For example, the
AMS may list all the MIDlets installed on the system and let the user select one.

A MIDlet's initial state is paused. Like an applet, a MIDlet should perform little or no
initialization in its constructor, because its operating context has not yet been set.

At some point after construction, the AMS activates the MIDlet and invokes
its startApp() method. After performing any necessary initialization, startApp() creates and
displays the application's user interface. After it returns from startApp(), the MIDlet's state
changes from paused to active. If the MIDlet cannot initialize itself for any reason, it must
throw a javax.microedition.midlet.MIDletStateChangeException - at which point it immediately shifts to
the destroyed state.

Deactivation occurs on any transition from the active state to the paused state. The MIDlet
is not destroyed, of course, but it should release as many system resources as possible. If
deactivation is initiated by the AMS, the MIDlet's pauseApp() method is invoked. If the MIDlet
deactivates itself, using the MIDlet's operating context, pauseA pp() is not called.

Destruction occurs when the MIDlet changes to the destroyed state from
either active or paused. If destruction is initiated by the AMS, the
MIDlet's destroyApp() method is invoked. A boolean parameter passed to the method indicates

3|P a g e
whether the destruction is unconditional (it must occur) or optional. The MIDlet can refuse
optional destruction by throwing a MIDletStateChangeException. If the MIDlet destroys
itself, destroyApp() isnot called.

The code for a basic MIDlet looks like this:

import javax.microedition.midlet.*;

public class BasicMIDlet extends MIDlet {

public BasicMIDlet(){
// constructor - don't do much here
}

protected void destroyApp( boolean unconditional )

throws MIDletStateChangeException {
// called when the system destroys the MIDlet
}

protected void pauseApp(){

// called when the system pauses the MIDlet
}

protected void startApp()

throws MIDletStateChangeException {
// called when the system activates the MIDlet
}
}

The MIDlet Context

The javax.microedition.midlet.MIDlet class also defines methods that let a MIDlet interact with its
operating context: getAppProperty() returns initialization property values; resumeRequest() asks
the AMS to reactivate the MIDlet; notifyPaused() shifts the MIDlet to the paused state;
and notify Destroyed() shifts the MIDlet to the destroyed state.

MIDlet initialization properties are name-value pairs in the MIDlet's application descriptor or in
its manifest. The application descriptor is a separate text file that lists important information
about a set of MIDlets packaged together into a single JAR file (a MIDlet suite).
The manifest is the standard JAR manifest packaged with the MIDlet suite.
When getAppProperty() is invoked, it searches the application descriptor first, then the manifest.
(Note that MIDP 2.0 introduces the concept of trusted suites, in which
case getAppProperty() searches only the manifest.)

The remaining methods directly affect the MIDlet's life -cycle. A paused MIDlet
calls resumeRequest() to be reactivated. An active MIDlet calls notifyPaused() to be deactivated. A
paused or active MIDlet calls notify Destroyed() to be destroyed. Note that resumeRequest() merely
asks the AMS to reactivate the MIDlet; the AMS decides whether and when to reactivate the

4|P a g e
MIDlet. Reactivation invokes the MIDlet's startApp() method. By
contrast, notifyPaus ed() or notifyDestroyed() causes an immediate transition to the new state; as a
consequence, neither pauseApp() nor destroyApp() is invoked.

The code for a better basic MIDlet looks like this:

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

public class BetterMIDlet extends MIDlet {

private Display display;

public BetterMIDlet(){
}

protected void destroyApp( boolean unconditional )

throws MIDletStateChangeException {
exitApp(); // call cleanup code
}

protected void pauseApp(){

// add pause code here
}

protected void startApp()

throws MIDletStateChangeException {
if( display == null ){
initApp(); // perform one-time initialization
}
// add per-activation code here
}

private void initApp(){

display = Display.getDisplay( this );
// add initialization code here
}

public void exitApp(){

// add cleanup code here
notifyDestroyed(); // destroys MIDlet
}
}

Unlike the BasicMIDlet class, BetterMIDlet defines an initApp() method for one-time initialization
(called the first time startApp() is invoked) and an exitApp() method for centralized resource
cleanup.

5|P a g e