A little experience in the process of J2ME learning

Process | experience

1. About the life cycle of MIDlet

When MIDlet was successfully initialized by the application manager, it began to expand its lifecycle.

Basically, the MIDlet has three states: the Stop State (paused), the activation state (active), and the Extinction State (destroyed).

The lifecycle of the MIDlet is entirely controlled by the Application manager, and the related function is invoked only when the application manager considers that the state of the MIDlet must change.

MIDlet must first go into the stop state, then the application manager converts him to the activation state, and then calls Startapp ().

In the active state, the application manager converts the MIDlet to the activation state before calling Startapp (). The application Manager first invokes Pauseapp () or Destroyapp (), and then converts midlet to a stop state or to a state of extinction. This is the active no passive (the end of the word without ED), and paused and destroyed are passive (the word tail plus ed) the true meaning.

If MIDlet call these functions on their own, there is usually no error, but it does not cause a state change (the lifecycle of the MIDlet is entirely controlled by the application manager), only as a simple function call.

STARTAPP () is invoked by the application Manager every time the activation state is returned from the stop state. So the action that needs to be initialized once is not suitable to be placed in Startapp (), the initialization action should be done with the constructor.

In addition to being able to control the lifecycle of MIDlet by the application Manager, the MIDlet itself can determine its own state in a soft way, but not by itself to change its state, but rather midlet invoke the corresponding request state change function (Resumerequest ()-Request activation, Notifypaused ()--Notification stops, notifydestroyed ()--Notification elimination--these functions send a message to the application manager, asking it to help change the state, but the decision is not guaranteed to be feasible in the application manager.

It is not the same that the request state change function is called by MIDlet itself and the application Manager requires a change of state.

In the case of a stop state: When the application manager asks for a stop, Pasueapp () is invoked, and MIDlet calls Notifypaused (), Pauseapp () is not invoked, but both causes the MIDlet to enter a stop state. So it's best to call Pauseapp () MIDlet yourself when you call Notifypaused (). The same situation also occurs in notifydestroyed () and Destroyapp (). Unless the system forces the MIDlet to shut down, it is best midlet to invoke Destroyapp () and then call Notifydestroyed (), and the application Manager will help us turn the midlet to the elimination state and finally end the midlet operation. It is no use simply midlet yourself to call Destroyapp ().

From here we can see that Startapp (), Pauseapp (), and Destroyapp () are not functions that control the MIDlet lifecycle, they are just a place where we initialize resources to release resources!