On-screen navigation of best practices for j2-based Programming

In addition to game programs, there are usually many screens or canvases in the MIDP applications. These screens are usually switched by commands, for example, when you click "Next", you should jump to the Next screen and click "Back" to return to the previous screen. When the number of screens is quite large, it is worth considering how to navigate between screens.

The classic MVC mode can be used for screen navigation. The Model is used to store application data, while the View mode is a Displayable object. The Controller needs to implement a class separately. Because the MIDlet class has only one instance in its lifecycle, The MIDlet class is very suitable for Controller. SUN applies a very complex MVC in the blueprints sample program SmartTicket, which can fully meet the navigation needs of the MIDP application. However, it can be seen that the disadvantages are obvious:

First, each event requires a unique identifier. The switch-case statement increases with the increase of the screen, making it difficult to maintain the Controller. Second, the Controller references all views. Initialization of these views at program startup results in high memory overhead, regardless of whether they will be displayed. Third, a large number of Model objects and Exception Handling make the logic of the entire application much complicated.

In fact, many screens of the MIDP application do not need complicated controllers and models. Our goal is to ensure basic flexibility while keeping the structure simple. Therefore, the other two navigation methods are implemented using binary trees and stacks. Here we only discuss the MIDP navigation framework implemented using stacks. The basic idea is: Whenever you move forward to the next screen, press the next screen on the stack and then display it. When the screen is returned, the current screen is displayed from the stack, and a screen is taken from the stack and displayed. Therefore, each screen only needs to specify the next screen to be displayed without remembering the previous screen. This stack navigation model is especially suitable for regular "Forward" and "backward" screens.

Because the MIDlet class has only one instance at runtime, it is quite appropriate to use the MIDlet class as the controller. In addition, we saved the MIDlet instance in a static variable to make it easier to access the MIDlet:

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 take a closer look at several screen jumps that may occur in actual applications. The simplest case is to move from one screen to another and return to the original screen, which fully complies with the FIFO feature of the stack, you can directly call the forward and goBack methods of ControllerMIDlet. For example, to display a help screen:

For a networked application, there is a temporary waiting screen. The following is a screen for online Image Browsing:

Unlike the above case, if the user selects "return" On Screen 3, the user should return to screen 1 instead of screen 2. Therefore, for switching between screen 2 and Screen 3, we can't forward. We use replace to discard screen 2, so that screen 3 can directly goBack to screen 1:

public static void replace(Displayable next) {
instance.ui.pop();
instance.ui.push(next);
instance.display.setCurrent(next);
}

Stack changes are as follows:

For some more complex situations, such as the logon process, if you are allowed to select automatic logon, the screen jump is as follows:

If you do not select automatic logon, the screen jump is as follows:

In this case, the LoginUI screen is pushed to the stack even if the user selects Automatic Logon. Therefore, we define another forward (Displayable d1, displayable d2) method, which pushes d1 and d2 to the stack sequentially, but only displays d2. If the user cancels the response, it is returned to LoginUI. In short, you can implement various operations by defining multiple navigation methods.

This stack-based navigation model is very suitable for regular "Forward" and "back" screens, and only generates new screens as needed. You do not need to care about the screen status, because the status of the previous screen is completely stored in the stack when the screen is returned.

The disadvantage of the stack model is that data is processed by different screens. For some processes, data on each screen may need to be transmitted to the next screen in sequence, the larger the screen, the more parameters the constructor may have.

We will provide a complete solution for multi-thread wait screen scenarios such as online operations, and integrate it into the stack navigation framework, so that the application itself does not involve multi-threaded online operations, just focus on its own logic.