Calling DestroyApp (Boolean Unconditional) or PauseApp () method in Active Status enables MIDlet to enter the Destroyed or PAUSE state. It is worth mentioning that the destroyApp (Boolean Unconditional) method, many developers don't understand the unconditional parameters, in fact, when the destroyApp () method is called, the AMS notifies the MIDlet to enter the Destroyed state. The MIDlet in the DESTROYED state must release all resources and save the data. If UNCONDITIONAL is false, the MIDlet can throw MIDletStateChangeException after receiving the notification, if set to TRUE, you must go to the DESTROYED state immediately. - Mingjava column
DESTROYXLET (Boolean Unconditional) This method notifies the XLET to end running, transfer to the removal state. Xlet should release all resources. The parameter Unconditional is set by the manager, indicating whether it is necessary to remove the XLET unconditionally. If UNCONDITIONAL is false, Xlet can throw a StateChangeException exception, indicating that you don't want to be removed - but whether you accept the XLET request is ultimately decided by the manager. That is, although Xlet has the right to legally throw the StateChangeException exception, it will eventually determine its fate or manager. If the manager accepts the request for the Xlet requirements, it will call the Xlet for some time, and then call the Destory () method again, this time the unconditional is typically set to TRUE. When the unconditional parameter is TRUE, the manager will ignore any xletStateChangeException, once the DestoryXLet () returns to the Xlet directly. There are two exceptions thrown from the life cycle method: XletStateChangeException, unpreciated RuntimeException or error. If the lifecycle method throws an unprocessed RuntimeException or error, the manager will immediately call the Xlet's DestoryXlet (TRUE) method to remove the Xlet. Therefore, the XLET should capture all "normal" (why known) runtimeException or errors, avoiding the runtimeException directly to the manager to cause the xlet to be removed. Relatively, XletStateChangeException can be intentionally thrown by Xlet, indicating that the XLET has not been prepared to change. - CCID
