10. How is navigation between screens in the application managed?
In this case, the entire application navigation is abstracted over three
packages with the main management being the responsibility of the
Navigator class. The point is to provide both a custom-drawn
menu system using only the low-level graphics routines in MIDP 2.0
and a more advanced menu system using the Scalable 2D Vector
Graphics API (JSR-226) where supported.
The game design consists of the logical subsystems shown in Figure 8.4.
APPLICATION CONTROL + NAVIGATION
Figure 8.4 High-level game design
The AMS and the MIDlet together represent the interface between
the application and the outside world, i.e. the operating system. The
application itself is designed on a Model-View-Controller (MVC) pattern,
where the Controller class manages application view changes and
navigation using the active menu system. Its primary role is to respond
to lifecycle events from the operating system and to drive the application
framework. To a large extent, the controller is not aware that is a 'game'
so to speak. It owns a GameController instance that it notifies when
events occur. Other than that, the controller remains independent of the
Figure 8.5 shows the application's main classes and their relationships.
As you can see from the names, most of the classes are designed for re-use
and have little to do with the particular game being built.
8.4.3 Menus and Navigation
This game uses a relatively heavy UI layer in the form of three packages.
This is not necessarily recommended practice - it has been done this
way to demonstrate how you can support two different menu system
implementations and select the one to use at run time based on the
target device (see Section 4.4). Both the SVG and LCDUI subpackages