J2ME Programming Best Practices screen navigation

In addition to the game program, in the usual MIDP applications, there will usually be a lot of screen or canvas, these screens generally rely on commands to switch, such as users click "Next" should jump to the next screen, click "Back" should return to the previous screen. When the number of screens is considerable, it's worth considering how to navigate between the screens.

The classic MVC pattern can be used for screen navigation, model for storing application data, and view is the individual Displayable object, controller needs a separate class implementation. Because the MIDlet class itself has only one instance in its lifecycle, the MIDlet class is ideal for controller. Sun has a very complex MVC application in the Blueprints sample program Smartticket that can fully meet the navigation needs of MIDP applications, but it can be seen that the drawbacks are obvious:

One is that each event requires a unique identifier, and the Switch-case statement increases as the screen increases, controller becomes difficult to maintain. The second is that controller references all of the view, which are initialized at the start of the program, resulting in a large memory overhead, regardless of whether they will be displayed or not. Thirdly, the large number of model objects and exception handling make the logic of the whole application greatly complicated.

In fact, many of the screens of MIDP applications do not require complex controller and model, and our goal is to meet basic flexibility while maintaining a simple structure. Therefore, the other two navigation methods are the binary tree and the stack implementation, here we only discuss the MIDP navigation framework implemented using a stack, with the basic idea of putting the next screen on the next screen and then displaying it, and then popping the current screen off the stack when you go back to the previous screen. Then remove the previous screen from the stack and display it. Therefore, each screen only needs to specify the next screen to be displayed, without remembering the previous screen. This kind of stack navigation model is especially suitable for the regular "forward" and "back" screens.

Since there is only one instance of the MIDlet class runtime, it is quite appropriate to use the MIDlet class as a controller. In addition, we save the MIDlet instance in a static variable, making access MIDlet more convenient:

public class ControllerMIDlet extends MIDlet {
　　 private static ControllerMIDlet instance = null;
　　 private Display display = null;
　　 private Stack ui = new Stack();
　　 public ControllerMIDlet() { instance = this; }
　　 protected void startApp() {}
　　 protected void pauseApp() {}
　　 protected void destroyApp(boolean unconditional) {}
　　 public static void goBack() {
　　 instance.ui.pop();
　　 Object obj = instance.ui.peek();
　　 instance.display.setCurrent((Displayable)obj);
　　 }
　　 public static void forward(Displayable next) {
　　 instance.ui.push(next);
　　 instance.display.setCurrent(next);
　　 }
　　 }

Let's look at some of the possible screen jumps in the actual application in more detail. The simplest case is to move from one screen to another and return to the original screen, which fully conforms to the FIFO features of the stack, and can call Controllermidlet's forward and GoBack methods directly. For example, to display a help screen:

Another scenario for a networked application is a temporary wait screen. Here is a screen to view the pictures online: