This chapter is from the book
This chapter is from the book
This chapter is from the book
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() 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 no-argument 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 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.