The lifecycle of the MIDlet application

1: In addition to the application administrator to control the life cycle of MIDlet, MIDlet itself can determine their own state, but not their own change of state, but MIDlet first call the corresponding state change function. These functions send a message to the application administrator to help change the state of the MIDlet, but the decision is not guaranteed to be feasible by the application administrator. The state change function is shown in Figure 11:



Diagram MIDlet state change function diagram

In contrast to these two state-related graphs, for example, you might be more clear: suppose today if it is MIDlet initiative to change the state of MIDlet from operation to stop state, then the direct call Pauseapp () function will only execute the program code in Pauseapp (). and cannot change the state of MIDlet. MIDlet must call Notifypaused () to notify the application administrator that the application administrator is notified before the MIDlet is allowed to enter a stop state.

However, there is a difference between the MIDlet call Notifypaused () and the application administrator's active request to stop. They are primarily when the application administrator proactively asks for a stop, Pauseapp () is called, and notifypaused () is invoked by MIDlet, and Pauseapp () is not invoked. But both will let MIDlet into the stop state. So before MIDlet calls Notifypaused (), it's better to call Pauseapp () yourself first.

The same situation also occurs in notifydestroyed () and Destroyapp (). Unless the system forces the MIDlet to shut down, it is best MIDlet first call Destroyapp () and then call Notifydestroyed (). Ask the application administrator to help convert the MIDlet to a destructive state and finally end the operation of MIDlet. It is no use simply midlet yourself to call Destroyapp ().

Destroyapp () has a Boolean value as a parameter, according to the MIDP specification, if passed true, then midlet no matter how to release all the resources unconditionally, and then let the application administrator end the MIDlet operation, which is the case when the system or hardware forcibly shuts down the midlet. If the consumer calls notifydestroyed () to end the MIDlet, it is best to pass false when calling Destroyapp (), which means that this is not a system or hardware forced shutdown, and if MIDlet does not want to end execution, Then it can tell the person who called it by throwing out the midletstatechangeexception: "I don't want to be wiped out yet, please come back later." ”

Here you can see that Startapp (), Pauseapp (), and Destroyapp () are not functions that control the MIDlet lifecycle, they are just a place to provide initialization resources and release resources.

According to the MIDP specification, even if the midlet is in a stopped state, it can still handle asynchronous events (asynchronous event), such as timer events or other callback functions (Callback). This will involve the use of resumerequest (). Resumerequest () returns MIDlet from the stop state to the operating state and invokes Startapp (). Because the MIDlet was in a stopped state, it was necessary to rely on asynchronous events to bring the MIDlet back to operation.

In some sample programs, we often only call notifydestroyed () instead of calling Destroyapp () because the example typically does not have the need to release resources, so you can not call. However, if it is a regular program, it is advisable to remember that calling Destroyapp (false) is better.   2: Describe a midlet lifecycle in which MIDlet's lifecycle is completely controlled by jam, that is, when midlet to change from one state to another, jam invokes the corresponding function, and if an error occurs when the state transitions, Then Jam will throw out midletstatechangeexception anomalies. The related functions are invoked only when Jam believes that the state of the MIDlet must change, and jam changes midlet state after the function call succeeds. Therefore, if midlet call these functions themselves, there will be no error, but will not cause the state of conversion, but a simple function call it. STARTAPP () is likely to be invoked not only once, but every time from the stop state to the running state. Jam Therefore, variables that need to be initialized only once are not suitable for initialization in Startapp (), and can be initialized using constructors instead. In fact, MIDlet itself can control their own state, but, not their own change of state, but first call the corresponding state change function, and then send information to inform jam, let it to help change the state of MIDlet. For example: Suppose today is MIDlet initiative to change the state of MIDlet from run state to stop state, then we simply call the Pauseapp () function, only run the code in Pauseapp (), but not the state of the MIDlet, Therefore, after the call to Pauseapp (), MIDlet calls Notifypaused () to notify Jam,jam of the notification that the MIDlet will not be allowed to enter the stop state. From here we can see that Startapp (), Pauseapp (), Destroyapp () are not functions that control the MIDlet lifecycle, they are just a place to provide us with initialization resources and releasing resources. According to the MIDP1.0 specification, even though MIDlet is in a stopped state, it can still handle asynchronous events, such as timer events or other callback functions. As long as the midlet into the elimination of State, can not go back. However, depending on the specification, we cannot call System.exit () or runtime.exit () directly in the MIDlet to end the program running, and if so, it can cause Java.lang.SecuritYexception exception. MIDlet must first call Destroyapp (), and then call Notifydestroyd (), let jam to help us convert midlet to the elimination state. Destroyapp () has a Boolean value as an argument, and, depending on the MIDP specification, if passed in true, then MIDlet should unconditionally release all resources, and then let Jam end the MIDlet run. If False is passed in, and MIDlet does not want to end the run, it can throw a midletstatechangeexception exception to tell the caller: I don't want to be wiped out yet.