Programming Tutorials Browser Tutorials Articles Struts Tutorials Hibernate Tutorials

  Tutorial: Big designs for small devices

Big designs for small devices

Tutorial Details:

Big designs for small devices
Big designs for small devices
By: By Ben Hui
Four J2ME design patterns simplify interactive content development
ava 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).
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 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.
Fortunately, we can create a reusable and maintainable menu system. Another popular pattern, the Model-View-Controller (MVC) pattern, can shed some light on this situation. The MVC pattern offers maintainable and reusable user interfaces by separating the responsibilities of the model, view, and controller. The model is a data structure that represents the content behind the user interface application. The view is a visual component that displays content and receives user input. The controller serves as a bridge between model and view by implementing the logic and workflow to update the model and view.
The Cascading Menu pattern is a scaled-down version of the MVC pattern. We identify the menu hierarchy as this formula's model. We must implement a view component that can adapt to an arbitrary complex data model and reflect the model's current state. In other words, we build and maintain the menu model independently from the view component. The view component renders the menu screens based on the current menu model. The view component updates the screens when the menu model updates. Any changes to the menu hierarchy will automatically modify the presentation. Rearranging the menu system is just a matter of updating the menu tree data model.
Figure 2. Cascading Menu UML diagram
Figure 2 is the Cascading Menu pattern's UML diagram. The MenuElement class is our data model implementation. We use MenuElement to create a menu tree structure. Each MenuElement instance represents a node in this tree, and there are two node types: parent nodes (or menu containers) and child nodes (or menu items). For example, Main Menu (in Figure 1) is a parent node (or menu container). Shops, Restaurants, and Attractions are the Main Menu's child nodes (or menu items). We establish this relationship using the addChild() method.
Listing 1 shows how Figure 1's menu hierarchy is built. Once the data model is created, we feed it into our view component, MenuList . MenuList is a subclass of MIDP List and is responsible for displaying menu items as a list. MenuList can be reused in many menu-based applications because its behavior is driven by the menu data model. The showMenu() method instructs MenuList to display the Main Menu. MenuElement handles navigation logic. When a menu item is selected, the current MenuElement determines the item's associated object during addChild() . If the associated object is another menu screen (i.e., another MenuElement object), it replaces the current menu with the later one using MenuList.showMenu() .
A user will eventually reach a menu item that triggers some action. We can create this link by adding a MenuElement associated with a MDisplayable object. The interface method onDisplay() is called when a user selects that menu item. We can perform the necessary action with onDisplay() . Listing 2 shows an onDisplay() implementation.
Listing 1. Build a menu hierarchy with MenuElement
// Create three menus.
// Use MenuElement for a menu container and
// use MenuElement also for menu item in the container.
// Link each menu item to a sample Mdisplayable.
MenuElement menu3 = new MenuElement( "Attractions" );
menu3.addChild( new MenuElement( "Museum"), new SampleMenuAction() );
menu3.addChild( new MenuElement( "Art Galleries"), new SampleMenuAction() );
menu3.addChild( new MenuElement( "Exhibitions"), new SampleMenuAction() );
MenuElement menu2 = new MenuElement( "Restaurants" );
menu2.addChild( new MenuElement( "Bakeries"), new SampleMenuAction() );
menu2.addChild( new MenuElement( "Coffee Shop"), new SampleMenuAction() );
menu2.addChild( new MenuElement( "Diner"), new SampleMenuAction() );
MenuElement menu1 = new MenuElement( "Shops" );
menu1.addChild( new MenuElement( "Automotives"), new SampleMenuAction() );
menu1.addChild( new MenuElement( "Books"), new SampleMenuAction() );
menu1.addChild( new MenuElement( "Fashions"), new SampleMenuAction() );
// Create the Main Menu,
// and link the menu item to the menu containers created above.
MenuElement main = new MenuElement( "Main Menu" );
main.addChild( new MenuElement( "Shops"), menu1 );
main.addChild( new MenuElement( "Restaurants"), menu2 );
main.addChild( new MenuElement( "Attractions"), menu3 );
// Show the Main Menu, this will make the Main Menu as the current screen
menulist.showMenu( main );
Listing 2. onDisplay() implementation
public class SampleMenuAction extends TextBox implements MDisplayable
{
public void onDisplay( MenuElement e )
{
this.setString( "You have selected menu item "+e.text );
// Sample implementation that takes different action
// based on different menu item being selected
if ( e.text.equals("Museum") )
{
//
// Code to retrieve Museum directory
// and display it in this text box
//
} else if ( e.text.equals("Art Galleries") )
{
//
// Code to retrieve Art Galleries directory
// and display it in this text box
//
} else if ( e.text.equals("Exhibitions") )
{
//
// Code to retrieve Exhibitions directory
// and display it in this text box
//
}
}
}
Different MenuElement s are associated with different MDisplayable implementations so that specific actions perform accordingly. MenuList is responsible for the visual rendering of all menu screens. Using MenuElement and various MDisplayable implementations, we can build a scalable menu system while keeping the structure clean and easily maintainable.
Wizard Dialog pattern
Many desktop applications use wizards in installation tools or configuration tools. In a wizard application, users are prompted through a series of screens. Each screen asks one or two questions. Two actions are allowed in wizard applications: Next and Back actions. Users press the Next button to proceed to the next screen. Users press the Back button to return to the previous screen and alter a previous answer. On mobile devices, wizard-style interaction involves a wireless application asking a series of questions to gather user input before performing an action. This is essentially a replacement for a Web input form, which doesn't fit well on mobile devices.
Let's look at an example?a local restaurant's search tool. This search tool uses city names and keywords as search criteria. The wizard application is implemented in tw


 

Read Tutorial at: Click here to view the tutorial

Rate Tutorial:
Big designs for small devices

View Tutorial:
Big designs for small devices

Related Tutorials:

Program Java devices -- An overview - JavaWorld July 1999
Program Java devices -- An overview - JavaWorld July 1999
 
Java memory management
Java memory management
 
Program your Palm in Java, Part 1: The PalmOS Emulator - JavaWorld November 1999
Program your Palm in Java, Part 1: The PalmOS Emulator - JavaWorld November 1999
 
Program your Palm in Java, Part 1: The PalmOS Emulator - JavaWorld November 1999
Program your Palm in Java, Part 1: The PalmOS Emulator - JavaWorld November 1999
 
Alternative deployment methods, Part 1: Beyond applets - JavaWorld May 2000
Alternative deployment methods, Part 1: Beyond applets - JavaWorld May 2000
 
WAP for Java developers - JavaWorld June 2000
WAP for Java developers - JavaWorld June 2000
 
J2ME: The next major games platform? - JavaWorld March 2001
J2ME: The next major games platform? - JavaWorld March 2001
 
Build database-powered mobile applications on the Java platform
Build database-powered mobile applications on the Java platform
 
Java's secret weapon
Java's secret weapon
 
J2ME devices: Real-world performance
J2ME devices: Real-world performance
 
Big designs for small devices
Big designs for small devices
 
High-availability mobile applications
High-availability mobile applications
 
Develop state-of-the-art mobile games
Develop state-of-the-art mobile games
 
Quaqua Look And Feel
Quaqua Look And Feel The Quaqua Look and Feel (Quaqua) is an implementation of Apple's Aqua Human Interface Guidelines in Java. Quaqua is not yet a self-contained look and feel. As Quaqua matures, it provides a steadily growing number of user elements
 
Getting Groovy with XML
XML sucks. Oh, wait, XML rocks. Well, it actually does a lot of both. It rocks because of all of the editors, validators, and tools written for it. XML has all but replaced any notion of a new custom text-based data language. But it also sucks because it\
 
J2ME Technology Turns 5!
In 2004 the Java 2 Platform, Micro Edition (J2ME) celebrated its fifth anniversary. This article presents where J2ME is today.
 
Getting Started With Composite Capabilities/Preference Profiles and JSR 188
This article presents Composite Capabilities/Preference Profiles for designing content once. JSR 188 allows users to access the same application or content from any device, and be confident that it will work on that device, and will accommodate their pref
 
Sun Researchers Unveil World's Smallest Secure Web Server
The Next Generation Crypto team at Sun Microsystems Laboratories has created this small secure web server, nicknamed Sizzle (from SSSL for "Slim SSL"). The coin-sized server is designed to be embedded in a wide array of tiny devices for secure monitorin
 
What is Persistence Framework?
What is Persistence Framework? What is Persistence Framework? A persistence framework moves the program data in its most natural form (in memory objects) to and from a permanent data store the database. The persistence framework manages the
 
Pure Java SSH Tool for J2ME
JSch is the pure Java SSH2 implementation developed by JCraft under revised BSD license. It has been already widely adopted by several open source projects, including Eclipse, Apache Ant, etc.,
 
Site navigation
 

 

Send your comments, Suggestions or Queries regarding this site at roseindia_net@yahoo.com.

Copyright © 2006. All rights reserved.