Java Reference
In-Depth Information
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.
8.4.2 Design
The game design consists of the logical subsystems shown in Figure 8.4.
AMS
MIDlet
APPLICATION CONTROL + NAVIGATION
GAME UNIT
MENUS
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
particular application.
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
