> 6.2 | MIDlet Life Cycle

> The MIDlet life cycle defines the protocol between a MIDlet and its environment through a simple well-defined state machine, a concise definition of the MIDlet’s states and APIs to signal changes between the states. A MIDlet has three valid states:

> • | Paused – The MIDlet is initialised and is quiescent. It should not be holding or using any shared resources.

> • | Active – The MIDlet is functioning normally.

> • | Destroyed – The MIDlet has released all of its resources and terminated. This state is only entered once.

> State changes are controlled by the MIDlet interface, which supports the following methods:

> • | pauseApp() – the MIDlet should release any temporary resources and become passive.

> • | startApp() – the MIDlet starts its execution, needed resources can be acquired here or in the MIDlet constructor.

> Note: Take care that the startApp() method is always properly terminated before calling the destroyApp() method. For example, avoid that threads launched by startApp() enter a closed loop, and be sure that all code was entirely executed. This is especially important for OTAP, which needs to call destroyApp().

> • | destroyApp() – the MIDlet should save any state and release all resources

> Note: To destroy only the Java application without switching off the module, the destroyApp() method can be called explicitly. To destroy the Java application and switch off the module at the same time, it is sufficient to send the AT^SMSO command from somewhere in your code, because this procedure implies calling the destroyApp() method. Likewise, resetting the module with AT+CFUN=x,1 also implies calling the destroyApp() method. Note that AT+CFUN=x,1 will restart the module – to restart Java afterwards either use the autostart mode configured with AT^SCFG or restart Java with AT^SJRA.
> From this you can see that the commands AT^SMSO and AT+CFUN=x,1 should never be sent within the destroyApp() method. It is good practice to always call the notifyDestroyed() method at the end of your destroyApp method. And use the destroyApp method as single exit point of your midlet.

> • | notifyDestroyed() – the MIDlet notifies the application management software that it has cleaned up and is done.

> Note: the only way to terminate a MIDlet is to call notifyDestroyed(), but destroyApp() is not automatically called by notifyDestroyed(). You must not terminate your midlet (i.e. having no threads left) and not calling notifyDestroyed() before.

> • | notifyPaused() – the MIDlet notifies the application management software that it has paused

> • | resumeRequest() – the MIDlet asks application management software to be started again.

> Table 9: | A typical sequence of MIDlet execution

> Application Management Software | MIDlet
> The application management software creates a new instance of a MIDlet. | The default (no argument) constructor for the MIDlet is called; it is in the Paused state.
> The application management software has decided that it is an appropriate time for the MIDlet to run, so it calls the MIDlet.startApp method for it to enter the Active state. | The MIDlet acquires any resources it needs and begins to perform its service.
> The application management software no longer needs the application be active, so it signals it to stop performing its service by calling the MIDlet.pauseApp method. | The MIDlet stops performing its service and might choose to release some resources it currently holds.
> The application management software has determined that the MIDlet is no longer needed, or perhaps needs to make room for a higher priority application in memory, so it signals the MIDlet that it is a candidate to be destroyed by calling the MIDlet.destroyApp method. | If it has been designed to do so, the MIDlet saves state or user preferences and performs clean up.