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.
|