AMS calls startAPP()
AMS calls pauseAPP()
Figure 2.2 MIDlet states
destroy an application at any time. Once a MIDlet has been instantiated,
it resides in one of three possible states (see Figure 2.2):
The MIDlet has been initialized but is in a dormant state. This state is
entered in one of four ways:
after the MIDlet has been instantiated; if an exception occurs, the
DESTROYED state is entered
from the ACTIVE state, if the AMS calls the pauseApp() method
from the ACTIVE state, if the startApp() method has been
called but an exception has been thrown
from the ACTIVE state, if the notifyPaused() method has been
invoked and successfully returned.
During normal execution, a MIDlet may move to the PAUSED state a
few times. It happens, for example, if another application is brought
to the foreground or an incoming call or SMS message arrives. In
these cases, the MIDlet is not active and users do not interact with it.
It is, therefore, good practice to release shared resources, such as I/O
and network connections, and to stop any running threads and other
lengthy operations, so that they do not consume memory, processing
resources, and battery power unnecessarily.
The MIDlet is functioning normally. This state is entered after the AMS
has called the startApp() method. The startApp() method can
be called on more than one occasion during the MIDlet lifecycle.
When a MIDlet is in the PAUSED state, it can request to be moved
into the ACTIVE state by calling the startApp() method.