Featured White Papers

• Utilizing Fast Testing to Transform Java Development
• Do You Really Get Classloaders?
• Pragmatic Continuous Delivery with Jenkins, Nexus, and LiveRebel
• Your Next Java Web App: Less XML, No Long Restarts, Fewer Hassles
• Coding with JRebel, Java Forever Changed
• 2012 Developer Productivity Report: Java Tools, Tech, Devs, and Data

Sponsored Links

• Graph databases are 1000x faster than relational.

  Learn More!

• Career opportunities at Harman- Careers That'll Rock Your Socks Off.

  Learn More!

• Developer-friendly Java PDF libraries by Qoppa Software

  Live Demos

• Stop blaming your app! Diagnose Java performance issues.

  Free tool >

• UrbanCode: Go From Continuous Integration to
  Continuous Delivery

  Learn More!

Sponsored Links

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

Big designs for small devices

Four J2ME design patterns simplify interactive content development

By Ben Hui, JavaWorld.com, 12/13/02

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.

Cascading Menu pattern

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).

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 10 different List subclasses (Menu1Class, Menu2Class, 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.