Please note that as of October 24, 2014, the Nokia Developer Wiki will no longer be accepting user contributions, including new entries, edits and comments, as we begin transitioning to our new home, in the Windows Phone Development Wiki. We plan to move over the majority of the existing entries. Thanks for all your past and future contributions.
Midlet basic lifecycle and states
When a user clicks on the MIDlet icon the MIDlet begins execution.Following are the steps that follow:
- The AMS first calls the zero-argument constructor to create a new instance of the MIDlet.
- When the constructor returns, the AMS places the MIDlet in the Paused state.
- To shift the MIDlet to the Active state the AMS calls the midlet.startApp() method.
- The startApp is the method where the main application logic begins..like in a typical game a thread is started and the game loop begins.
- A transition from the Active state back to the Paused state occurs whenever the AMS calls midlet.pauseApp().
- The MIDlet may shift from Paused to Active or back any number of times during its execution, each time on a call to startApp() or pauseApp().
- The MIDlet may enter the Destroyed state from either Paused or Active, on a call to midlet.destroyApp().
- A MIDlet may voluntarily enter the Paused state by calling midlet.notifyPaused().
- In a similar fashion, it may call midlet.notifyDestroyed() to inform the AMS that the MIDlet can now be considered Destroyed. The destroyApp() method is actually called with a boolean argument. If this boolean is true, the MIDlet will be in the Destroyed state when destroyApp() returns. If this boolean is false, however, the MIDlet can request not to enter the Destroyed state by throwing a MIDletStateChangeException.
- Finally, a call to midlet.resumeRequest() will tell the AMS that the MIDlet is interested in entering the Active state. While it's idle in most ways, a MIDlet in the Paused state may handle asynchronous events such as timers and callbacks.