RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


Become a Cross-platform Wireless UI Expert : Page 4

Writing a user interface for your app that runs on all of today's mobile devices can be a huge challenge. Among the things you need to consider: diverse appearances, functionality, memory, screen real estate, and persistent storage availability. This article describes the many pitfalls of developing a user interface for diverse devices and tells you how to devise a plan that will save you time and headaches.

The concrete class Form adds to the Screen class the ability to append Items, and provides the ability to create Form-like screens for devices. The MIDP specification describes how a device should lay out items on a form. For more recommendations, you should check out the MIDP 1.0a Style Guide. Links to both documents are available at the end of this article. Although the suggestions are general they can help developers and UI designers construct usable forms. The specifications state that:

  • Items appear on the Form from top to bottom in the same order in which the internal list maintains the items.
  • Forms can scroll vertically but not horizontally. Items that exceed the form's width will be wrapped if possible, as in a string item, or clipped, as in an image item. Scrolling is device dependent and could be implemented as a scroll bar, as up and down arrows, as in the case of a Palm device, or as a small arrow near the bottom of the screen to indicate that more items exist below the visible area.
  • All items appear on a line of their own except for StringItem and ImageItem.
  • All items can have an associated label and if one is provided the label is displayed somewhere near the item and may be rendered in a way that distinguishes it from the item.
  • Multiple StringItems or ImageItems in succession that do not have Labels associated with them are laid out horizontally whenever possible. If there is insufficient room the items are broken and word wrapped or clipped.
  • If a StringItem contains a line break, the line break is displayed.

Form Items
The high-level UI API provides a variety of Items that you can add to forms. You'll have to add code to provide your user with interactivity but you'll find that for most basic UI data entry and display requirements these items will do the job.

The high-level UI API provides a variety of Items that you can add to forms. You'll have to add code to provide your user with interactivity but you'll find that for most basic UI data entry and display requirements these items will do the job.

All Items are descendents of the abstract Item class, which means that they all have an associated label. The High-level UI API provides the following items:

  • StringItem. A string item displays a non-editable string and its associated label. You can change the text programmatically with the StringItem's setText method and retrieve its value via the getText method.
    Figure 2: Notice the difference in how the label is rendered on a cell phone in contrast to how the Palm OS renders it.

  • ImageItem. Displays an image and its associated label, or an alternate string if the image cannot be displayed. The image must be immutable and can be set using setImage. You can provide layout hints to the application to specify how the image item should be laid out (see the documentation for the layout hints).
  • TextField. This displays text in an editable field. You can specify a pre-existing value through the constructor or with the setString method. The text field can be a single or multi-line text field, although how each device handles this varies. Some allow multi-line editing directly on the containing form, while others require a separate screen. You can specify how the field will handle data entered by the user, or constraints, but devices are not required to provide all of these. These constraints provide the user some guidance for what data to enter and potentially ease data entry. The following constraints are available:
    • ANY - Allow the field to contain any character
    • EMAILADDR - Contrains the input to any characters valid in an email address
    • NUMERIC - Restricts the input to numeric characters only
    • PASSWORD - Doesn't restrict character entry but tells the device to use any password protection facilities available for user input such as not echoing back characters or replacing characters with asterisks.
    • PHONENUMBER - Constrains the field to valid phone number formats or characters
    • URL - Restricts the field values to those available for Uniform Resource Locators such as http://, ftp:// etc.
    Figure 3: The cell phone renders both interactive and non-interactive gauges without specifying the current value, while the Palm OS renders the current value for interactive gauges.

    A TextField notifies ItemListeners (see the next section for details) later) of content changes provided by user input but not about content changes made programmatically.
  • TextBox. Provides text input somewhat like a TextField but a TextBox takes up the full screen and does not notify ItemListeners of content changes.
  • DateField. Allows user input of a date and/or time value. Internally, MIDP holds the value as a java.util.Date object. You can specify an initial date or accept the default null date value. How the device handles and renders user input is device dependent and may be anything from a simple text entry to a complicated calendar or clock widget. The DateField notifies ItemListeners of any changes.
  • Gauge. You use a gauge to display a continuous value over a specified range. The gauge can be interactive, letting users change the value manually, or non-interactive, appropriate for tasks such as a progress bar.
  • ChoiceGroup. Provides a list of alternative choices to the user and allows one or more choices to be selected. ChoiceGroups can be EXCLUSIVE, like a radio group in standard desktop applications, or MULTIPLE, allowing multiple item selection. ChoiceGroups notify ItemListeners of changes when the state of a choice (selected or not selected) changes, but not when focus changes from one choice to another.
  • List. A list behaves in the same manner as a ChoiceGroup but provides the list in a separate screen and adds the IMPLICIT selection mode in addition to MULTIPLE and EXCLUSIVE. The implicit mode sends a List.SELECT_COMMAND to an associated CommandListener when a user selects an item from the list.

Figure 4. On the left, the choice group in exclusive mode lists all available choices on the form while the Palm implementation renders the same group as a drop down.
Figure 5. A list is almost like a ChoiceGroup except that it takes up the entire screen.

The preceding interface items are guaranteed to be available on all devices supporting MIDP. With only these basic building blocks to work with you have to keep in mind that data entry and navigation can be difficult on some devices. Plan your application to help the user navigate successfully and easily through your application.

Close Icon
Thanks for your registration, follow us on our social networks to keep up-to-date