The life cycle of J2ME learning diary--midlet

I've figured out how to use Eclipse to write basic midlet. The basic structure of MIDlet is also understood. But MIDlet how it works. What is the transition between the three states? These questions need to be solved at 1.1 o ' ...

Take the previous Hellomidlet procedure as an example, this time in order to understand the implementation of the procedure, add a few println. The specific code is as follows:

Import Javax.microedition.midlet.MIDlet;
Import javax.microedition.midlet.MIDletStateChangeException;
Import javax.microedition.lcdui.*;
/*
* Date Created 2005-10-5
*
* TODO to change the template for this generated file, go to the
* Windows-Preferences-Java-code styles-code templates
*/

/**
* @author Snail
*
* TODO to change the template for this generated type annotation, go to the
* Windows-Preferences-Java-code styles-code templates
*/
public class Hellomidlet extends MIDlet {
private display display;
Private form form;
/**
*
*/
Public Hellomidlet () {
TODO automatically generate constructor stubs
System.out.println ("constructor");
display = Display.getdisplay (this);
}

/* (non-Javadoc)
* @see Javax.microedition.midlet.midlet#startapp ()
*/
protected void startApp () throws Midletstatechangeexception {
TODO automatically generate method stubs
System.out.println ("startApp called");
form = new Form ("Hellomidlet");
Form.append ("Welcome to J2ME world!");
Display.setcurrent (form);

}

/* (non-Javadoc)
* @see Javax.microedition.midlet.midlet#pauseapp ()
*/
protected void Pauseapp () {
TODO automatically generate method stubs
System.out.println ("Pauseapp called");
form = new Form ("");


}

/* (non-Javadoc)
* @see Javax.microedition.midlet.midlet#destroyapp (Boolean)
*/
protected void Destroyapp (Boolean arg0) throws Midletstatechangeexception {
TODO automatically generate method stubs
System.out.println ("Destroyapp called:" + arg0);

}

}


Looking at the code carefully, I just added a flag to the construction method body and three methods respectively. It is convenient for us to understand the specific implementation of the program at runtime. Run the program to carefully observe Eclipse's console when the emulator appears in the Welcome interface. We see the following information:

Running via storage root Defaultcolorphone
Constructor
StartApp called

The system first calls the constructor method, which is paused after the construction completes, and then quickly transitions to the active state before calling the Startapp method. \ midlet Now the MIDlet is already active. But the application Manager will require a pause in some cases, such as a sudden phone call or a short message. In order to save more system resources, the application Manager first calls the Pauseapp method to free a portion of the MIDlet resource that is not necessary, and then transitions to a paused state. Therefore, it is generally necessary to add the required code for releasing resources within the Pauseapp () method. In the Pauseapp () method above

form = new Form ("");

You can simulate the release of the memory of a form. The WTK simulator can simulate the case where the system calls Pauseapp ().



When we paused to look at the console, it was already printed out "Pauseapp called". When the external event is processed, we return to MIDlet with the system MIDlet the paused state again to the active state, and then invoke the Startapp method to restore the resources required for MIDlet. Within the Startapp () method in the program

form = new Form ("Hellomidlet");
Form.append ("Welcome to J2ME world!");

You can restore the contents of the form again.

Check the console to print out "startApp called" again.

We see that the Startapp () method may be invoked more than once in a midlet. Therefore, we should note that the MIDlet initialization process and the main execution process are not written in the Startapp () method body. The initialization actions that are performed only once and are performed when the program is initialized should be placed within the construction method. Careful observation of console information should also be noted that the construction method is invoked only when initially initialized, and that only parameterless construction methods can be invoked automatically by the system. If the form's initialization work is done within the construction method, the contents of the form cannot be restored when MIDlet is restored from the paused state to the active state, and the Startapp () method is called again.

When we force close the emulator to terminate MIDlet, the console prints the following message:

Destroyapp Called:true
Execution completed.

At this point, the console prints true, that is, the argument for the incoming Destroyapp (Boolean arg0) is true. This means that the system terminates the program unconditionally and frees up all the resources it occupies. If False, MIDlet can send a request to the system by throwing a midletstatechangeexception exception. At this point it is possible to keep MIDlet in its current state.

In addition, the MIDlet itself can also actively request state transitions. Take the active state--> pause state as an example. MIDlet must call the Notifypaused () method to notify the application manager that I am suspending the operation, and then the application Manager will make a corresponding transition to midlet according to the situation. If MIDlet simply calls the Pauseapp () method, the system executes only the code in it, and no state transitions are made. However, Pauseapp () is not invoked when MIDlet calls Notifypaused (). It is best to call Pauseapp () before calling notifypaused (). The same is true when you manually close MIDlet, you should call the Destroyapp () method before calling the Notifydestroyed () method. These conditions are not mandatory, so the arguments passed in when the request is converted to the destroy state are best false.

It now appears that the Startapp () Pauseapp () Destroyapp () method that the state transitions need to invoke is just a place to provide initialization resources and release resources.

This concludes with a general understanding of the implementation and lifecycle of MIDlet.