The MIDlet State Model

 
The MIDlet State Model
MIDlets transition to different states during their lifetime. The MIDP specification defines the
MIDlet state transition model. Table 3.1 lists the possible MIDlet states and their respective
descriptions.
Figure 3.5 shows a state transition diagram that represents these MIDlet states and the events that
cause transition from one state to another. The startApp(), pauseApp(), and destroyApp()
39
methods that you saw in Listing 3.1 allow a MIDlet to change its state. Technically, the device
application management software changes the state of a MIDlet by calling one of these methods
on the MIDlet. A MIDlet can't change its own state, although it can request a state change from
the AMS.
Figure 3.5. A MIDlet can be in one of three states. When the AMS first creates a
MIDlet, the MIDlet exists in the paused state.
Table 3.1. MIDlet States
MIDlet State
Name
Description
Paused The MIDlet is not executing. It can't execute again until it transitions to
the active state.
Active The MIDlet is either ready to run or running. The thread that controls the
MIDlet might not be in the run state, but the MIDlet is still active.
Destroyed The MIDlet isn't running and can no longer transition to other states.
The application management software first instantiates your MIDlet class by calling its noargument
constructor. It then places the instance in the paused state. Before the MIDlet can
execute, the AMS must place the MIDlet in the active state for the first time. It places the MIDlet
in the active state and then calls the MIDlet's startApp() method.
The application management software places a MIDlet in the paused state by calling its
pauseApp() method. A MIDlet can also petition the AMS for entry into the paused state by
calling its notifyPaused() method. A MIDlet can thereafter request that it be placed in the
active state by calling resumeRequest().
The AMS can signal to the MIDlet that it should clean up and prepare to be terminated by calling
the MIDlet's destroyApp() method. The MIDlet can signal its execution completion to the
40
AMS by calling notifyDestroyed(). Table 3.2 lists the methods in the
javax.microedition.midlet.MIDlet class that control the MIDlet state.
Table 3.2. MIDlet Class Methods That Control MIDlet State
MIDlet Class Method Name Description
protected abstract void
destroyApp()
The AMS signals the MIDlet to terminate. The
MIDlet enters the destroyed state.
void notifyDestroyed() The MIDlet requests to enter the destroyed state.
void notifyPaused() The MIDlet requests to be inactive and enter the
paused state.
protected abstract void
pauseApp()
The AMS signals the MIDlet to stop; the MIDlet will
enter the paused state.
void resumeRequest() The MIDlet requests to re-enter the active state.
protected abstract void
startApp()
The AMS signals the MIDlet that it is active.
Notice that the program in Listing 3.1 doesn't call System.exit(). MIDP applications differ
from J2SE applications in the way they terminate. To terminate your MIDlet, you only need to call
the MIDlet's notifyDestroyed() method. This signals the AMS that your MIDlet is done
executing. The AMS destroys the MIDlet instance and all of its objects. The VM still executes,
however.
You want the VM to continue executing so other MIDlets can run. A call to System.exit()
signals the VM to terminate. This behavior is undesirable in MIDP applications. Your applications
should not terminate the VM; in fact, they can't. If your application calls System.exit(), a
java.lang.SecurityException will always be thrown. You'll see a trace back that looks
something like the following:
java.lang.SecurityException: MIDP lifecycle does notsupport system
exit.
at java.lang.Runtime.exit(+9)
at java.lang.System.exit(+7)
at HelloWorld3$MyCommandListener.commandAction(+15)
at javax.microedition.lcdui.Display$DisplayAccessor.
commandAction(+99)
at com.sun.kvem.midp.lcdui.EmulEventHandler$EventLoop.run(+430)
There are two main reasons why a MIDlet should not shut down the VM. First, other applications
may be running; terminating the VM would destroy them. Second, you never start up the VM;
therefore, you should not shut it down. The AMS controls the VM. It starts it and terminates it
when it detects it's not needed, or if it needs to manage system resources.