J2ME user interface development is similar to Swing development. Applications are structured around a series of screens. The main user interface elements are strings and images to convey information, and text input fields and choice groups (similar to radio buttons) to gather information. All of these elements are placed on a Form, a class similar to JPanel. Unlike Swing, where there are several different layout managers, in MIDP, there is exactly one. This layout adds elements to the screen, each in their own row. If absolute control over drawing the screen is important, the Canvas and Graphics classes, which according to the MIDP 1.0 specification, are “designed for applications that need precise placement and control of graphic elements and access to low-level input events.”

Since the user interface is limited, it is a good idea to ease information entry whenever possible. Do not use a text field, which forces users to enter letters and numbers using the keypad, when a choice group, which lets users select one option among many, will work. Do not present a choice group when there is only one valid choice. Specify constraints for text fields when possible.^[14] Do not make the screens too large, as then users will have to scroll. However, balance this against the number of screens needed to collect data and try to attain a happy medium. Provide sane defaults whenever possible--commonly selected options or example values can make the application easier to use. Find out what parts of the application are most important to the user and make them prominent.

Softbuttons with multiple actions associated

A typical cell phone has two soft buttons, used to handle high level actions (as opposed to low level events like keypad button releases). More than one action can be associated with a softbutton, but doing so means a more complex navigation, as shown above. Use softbuttons wisely--minimize the number of actions associated with them.

J2ME user interface issues are similar to those of other software environments, but requirements are more stringent. The MIDP 1.0 spec suggests a screen size of at least 96x54 pixels, which does not give application developers much room for mistakes. In addition, the “consumer device” nature of most cell phones means that usability expectations of installed applications are high--unlike a computer, where training is the expectation, I feel that most people expect to pick up a cell phone and be able to use installed programs.

In order to flow from one screen to another and enable users to return to previous states in the application, a stack can be used. Whenever a user chooses to go to a different state, the current form is pushed on to the stack. If the user returns to the previous state, the application pops the stack and brings back the previous form. This design is Model 1. Each screen knows the transitions available to the user. This architecture is a simple solution, easy to understand, and keeps the client small. Having a central configuration and controller, like many web frameworks, is overkill for a typical J2ME application.

Since applications like the traffic congestion application depend so heavily on real time data access, networking is important. Networking access in J2ME requires understanding threads. As in Swing, in J2ME there is a system thread responsible for redrawing the screen. This thread should not block for any reason, including waiting for I/O or network access. In some emulators, the blocking behavior is not emulated correctly, but the flaw is apparent when an application is running on a real phone: the phone locks up. Why? Many phones require user permission for an application to access the network--and if the system thread is busy trying to access said network, it cannot respond to the user's permission granting; deadlock ensues.

Separate threads access the network but what will the communication between the cell phone and the intermediary server look like?

In the end, a custom XML format was chosen. When processing the XML, a third party library was used^[17], and the strings were decoded into java objects. These java objects were then passed on to the user interface. Javabeans with synchronized getters and setters and the producer consumer pattern were used to ensure that the user interface did not display information until it had been retrieved from the network. Below is s a sample network interaction explained in the context of the traffic congestion service.

Sequence Diagram for Retrieving And Displaying Information From the Network

First, the user enters an address. The User Input Form object creates the Wait object, which displays a 'Waiting for Data' message to the user. The Wait object starts a new thread, the Logic object, that is responsible for retrieving and processing the data, and passes itself to the Logic object as a reference. The Wait object is pushed onto the display stack maintained by the Controller object, by the User Input Form, which then causes the Wait object to be drawn on the screen. Meanwhile, in the Logic object, network access is deferred to yet another thread, the Network Worker. The Logic object communicates with the Network Worker through one or more Transfer objects, which are simply beans with synchronized get and set methods to which both the Logic and Network Worker objects have references. The Network Worker connects to the network, and receives an XML input stream containing information regarding the traffic jams around the address the user entered, which it puts in the Transfer object (see Example 2, “Network Connection Code” for code). The Logic object has been waiting for this input stream, and processes it by parsing the XML into domain objects (see Example 3, “XML Parsing Code” for code). These objects are then passed back to the Wait state, which then creates a new Form object, passing the retrieved data to the new Form in its constructor. Then the Wait object passes control to the new Form by pushing it onto the stack. This then causes the Form to be drawn on the device, displaying whatever data has been retrieved from the network and perhaps prompting the user for more data.

1   hc = (HttpConnection) Connector.open(urlst);
2   if (null != sessionCookie) {
3      hc.setRequestProperty("cookie", sessionCookie);
4   }
5   if (post) {
6      hc.setRequestMethod(HttpConnection.POST);
7      hc.setRequestProperty("Content-Type", "application/x-www-form-urlencoded");
8      hc.setRequestProperty("Content-Length", Integer.toString(message.length()));
9      out=hc.openOutputStream();
10     if (null != out){
11        out.write(message.getBytes());
12     }else{
13        Log.logError("couldn't write post data to output stream");
14     }
15  } else {
16     hc.setRequestMethod(HttpConnection.GET);
17  }
18  hc.setRequestProperty("Connection", "close");
19  is = hc.openInputStream();
20  t1.setPayload(is);

1   while ((event = parser.read()).getType() != Xml.END_DOCUMENT) {
2      int type = event.getType();
3      if ( (type == Xml.START_TAG) && (event.getName().equals("INTERSECTION"))) {
4          String name = event.getName();
5          IdDescriptionPair intersection = new IdDescriptionPair();
6          intersection.id = event.getValue("code");
7          intersection.desc = event.getValue("description");
8          returnVector.addElement(intersection);
9      }
10  }

Networking code has some phone specific peculiarities. In particular, the header handling has been different between phones. On some Motorola phones, when there is more than one cookie, the later ones are not seen. In addition, handling cancel events means communicating back to the network accessing thread; this communication can only happen at certain times (not when the thread is blocking on network access). Also, most phones ask users if an application can access the network, since doing so costs the user money. If the user says no, a security exception is thrown, and must be handled by the application. These issues, as well as the deadlock issue mentioned above, make it clear that testing on as many real phones and emulators as possible helps smoke out non standard behavior that will adversely affect the user experience.

Cell phone applications exhibit decent network performance. The user experience has depended greatly upon the cell phone network--some carriers simply have higher data transfer rates than others. This is not a rigorous analysis, but while demoing applications, I have never seen it take more than ten seconds or so to download ten KB of information from the network.

Mobile phones are lost, stolen or misplaced more easily than laptops. Anything that needs to be secure should not be on a cell phone; if data needs to be secure and must reside on the cell phone, look at encrypting it. In the case of the traffic congestion client, sensitive data, including authentication tokens to remote databases, could be kept on the server.

Cell phones have static memory which J2ME exposes via the recordstore API, using classes in the javax.microedition.rms package. Recordstores are an array of byte arrays. The store is easier to work with if treated as a persistent hashtable.^[18]

Images that are downloaded from the network and then displayed can be cached in the recordstore for a performance increase. However, doing so requires storing the raw byte[] array before displaying the image. Such a a byte[] array can be easily turned into an javax.microedition.lcdui.Image object, displayable on a screen. However, there is no way to turn an Image object into a byte[] array after it has been created.