Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
Java 2 Platform, Micro Edition (J2ME) Mobile Information Device Profile (MIDP) is undoubtedly the dominant mobile phone programming platform today. The number of J2ME-enabled phones and J2ME applications continues to rapidly grow. However, working with J2ME is often complex. This isn't because J2ME is a sophisticated platform, but because J2ME is a constrained platform. Although MIDP is popular for building interactive applications, such as games, on mobile devices, it frequently exposes its weakness and limitations. Creating simple interactive content with MIDP is often complicated and requires repetitive programming tasks. This consequently burdens many developers.
After working on several MIDP projects, I found that many recurring problems could be solved with well-defined design patterns. I chose several design patterns that fit my problem scenarios and then tailored those patterns to comply with J2ME platform constraints (especially application size and performance constraints).
In this article, I examine four design patterns and strategies to implement interactive content on mobile devices. Each pattern has its unique role in creating a maintainable and reusable framework. You can download the source code for these patterns from Resources.
To understand this article's material, you should be familiar with MIDP's building blocks such as MIDlets,
Display, and high-level user interface components in the
javax.microedition.lcdui package. Readers also need basic Unified Modeling Language (UML) knowledge to read the design diagrams. If you are unfamiliar
with these technologies, now is a good time to get up to speed. Resources are provided below.
Let's start with the most interesting pattern: Cascading Menu. A menu is a fundamental way to navigate an application on constrained devices. A cascading menu has a long history on older electronic devices such as digital organizers and legacy terminals. System functionalities are organized in a hierarchy of nested menu options. Figure 1 is an example of a cascading menu for a city guide application. When users select a menu option, it takes them to a submenu with another list of available options. Users continue to navigate down the menu system until they hit the menu hierarchy's end node, which usually instructs the system to perform a function (e.g., retrieve relevant data).
Figure 1. A city guide application using Cascading Menu
This user interface format is commonly found in Wireless Application Protocol (WAP)-based content. By defining each menu option as an anchor (or link), Wireless Markup Language (WML) makes Cascading Menu a very simple system to implement. However, this is not the case in the MIDP world.
If you use MIDP's high-level (yet very constrained) user interface components, you might choose to implement several
List objects. Each
List object implements a menu screen with an options list. Upon a selection event, a
CommandListener, the controller, determines which menu option was selected and updates the screen with another
List object that represents the submenu. This solution is viable when you have only two or three choices in your menu system.
If you add more menu screens to the hierarchy (say, 10 menus), it becomes a complicated approach. You would need to create
List subclasses (
Menu3Class) for the corresponding menu screens. These menus are difficult to manage and maintain. The dispatching logic between menus
becomes a complex network of menu options and screens.