Provides the functions of the runtime management of MIDlets and suites in conjunction with the javax.microedition.midlet package.

For security purposes the MIDletStateHandler is the anchor of trust internally for the MIDP API, restricted methods obtain the MIDletStateHandler for a MIDlet suite in order to check the properties and actions of a suite. Because of this, there MUST only be one a MIDlet suite per MIDletStateHandler.

## MIDlet State Handing

The MIDletStateHandler handles state transitions for a MIDlet. MIDP Optimized Implementation software has more states than those listed in the MIDP Specification (which are paused, active, and destroyed). The additional states are active pending, pause pending, and destroy pending. The state processing for a MIDlet is described in the table and illustrated in figure below.

State | Description
--- | ---
Active Pending | The starting state. For MIDlets in this state, the MIDlet state handler moves the MIDlet to the active state, and calls the MIDlet's startApp method.
Active | For MIDlets in this state, the MIDlet state handler does nothing. A MIDlet leaves the active state because of an event outside the MIDlet state handler, such as the user exiting the MIDlet.
Pause Pending | For MIDlets in this state, the MIDlet state handler moves the MIDlet to the paused state and calls the MIDlet's pauseApp method.
Paused | For MIDlets in this state, the MIDlet state handler does nothing. A MIDlet leaves the active state because of an event outside the MIDlet state handler, such as the MIDlet requesting its reactivation.
Destroy Pending | For MIDlets in this state, the MIDlet state handler moves the MIDlet to the destroyed state and calls the MIDlet's destroyApp method.
Destroyed | The final state. For MIDlets in this state, the MIDlet state handler removes the MIDlet from the list of running MIDlets.

Note - To save CPU time, if all of the running MIDlets are in either the paused or active state, the MIDletStateHandler stops and waits for a state change.

### Pausing a MIDlet

A MIDlet can be placed in paused state by either the system or itself, as indicated by the figure above. A MIDlet pauses itself by calling its pauseNotify method. However, as of MIDP 2.0 there is no longer any reason for this to happen for the following reasons:

- A MIDlet does not need to pause itself to give up resources like CPU time or the display. To give up the display a MIDlet should call the Display.setCurrent method with an null argument. To give up CPU time the MIDlet only has to end or block the threads it started. Another option is for the MIDlet to ask the system to start it in the future using the Alarm API. See the Push API in the MIDP Specification for information.
- MIDlets that use a Canvas object suspend and resume threads it created based on the Canvas or CustomItem class's hideNotify and showNotify methods. They must not depend on startApp and pauseApp because the hideNotify and showNotify methods also get called when a MIDlet is paused and activated.

MIDlet can be paused if desired by a device manufacture by using the MIDletProxy class or the native application manager API. The common reasons for customizing a system to pause MIDlets are:

- The system allows the user to launch more than one MIDlet but only has the resources to run one MIDlet. In this case, the system pauses the MIDlets that do not have the physical display until the current MIDlet gives up the display.
- The OS is about to suspend the CPU time for the VM process (as opposed to ending the process). In this case, the system pauses all of the MIDlets and activates them again when the OS resumes CPU time for the VM process.