A MIDlet is either in the active state or the paused state. When it is first loaded by the MIDP runtime environment, it will be in the paused state. The runtime will generally call the method startApp() to signal that the MIDlet should now activate itself. Whenever the application is idle, the runtime can, in principle, put the MIDlet back into the paused state. When it is paused, the application will not receive user interface events. On a mobile phone, for example, the runtime may pause a MIDlet if an incoming telephone call is detected. The runtime will call pauseApp() to indicate that it has done this. The developer should use startApp() and pauseApp to allocate and release resources that the application needs whilst it is running.

When the operator is finished with the MIDlet, the runtime will destroy it. Before it does this, it calls the method destroyApp() method. The MIDlet must deallocate resources here as it does when it enters the paused state. However, this deallocation should not be done carelessly, as a MIDlet can be destroyed when it is in the paused state, as well as the active state. In the MIDP documents, `destroyed' is described as being one of the states that the MIDlet may be in. This terminology raises a philosophical problem: if something is destroyed, it no longer exists; how can something that doesn't exist have a state? Apart from the philosophical issue, `destroyed' is not really a state, because the MIDlet cannot leave the destroyed state and enter any other state.