common error is to implement startApp( ) to execute instructions that are only intended to be executed once during MIDlet execution. The correct implementation is to include in startApp( ) those instructions which can and should be executed each time the MIDlet changes from the Paused state to the Active state. The same logic should be applied to pauseApp( ).
The code sample below shows implementation of using startApp( ). startApp( ) performs operations for the initial launch of the MIDlet as well as any operations that need to take place each time the MIDlet changes state from Paused to Active. Booleans are used to determine whether the MIDlet has started and whether it’s in the Active state. These Booleans can also be used by other MIDlet threads to determine state.
Using startApp()
package midp.demo;
import javax.microedition.midlet.MIDlet;
public class Demo extends MIDlet {
//The MIDlet has been started already private boolean isStarted = false;
//The MIDlet is in active state
public | boolean isActive = false; |
// (in | most cases these booleans are used by other threads) |
protected void destroyApp(boolean unconditional){ isActive = false;
}
protected void pauseApp(){ isActive = false;
}
protected void startApp(){ isActive = true; if (!isStarted){
//...Use getDisplay(), setCurrent(),
//and other initial actions isStarted = true;
}
}
The MIDP specification of javax.microedition.midlet allows for some latitude in the implementation, therefore, it cannot be assumed that all MIDlets are perfectly compatible with all devices. Some MIDlets may execute flawlessly on desktop simulators such as Sun’s Wireless Toolkit and contain a gain/loose focus mechanism such that the MIDlet transitions between the Paused and Active states and startApp() and pauseApp() are called.