A User Interface Designer’s Guide to J2ME and MIDP2
From MobileDesign
We updated our guide to understanding J2ME and MIDP to cover MIDP 2 in honor of the publication of our [User Interface Guidelines for J2ME MIDP 2.0]. MIDP2 adds access to device-local information, location services, camera, and incoming text messages. Incoming messages can launch background processes even when no MIDlet is running. The Form layout manager is far more sophisticated. MIDP2 also provides sophisticated graphics control for games by creating sprites and tiles.
Here we provide an overview of the elements in J2ME MIDP, with a focus on what a UI designer needs to know for successful design. If you want more detail, go to [Sun's wireless site]. I found much of the information available on the web quite bewildering. After review and analysis, however, it became quite simple. Here is the simple version.
The programming language is J2ME, but the most relevant description of the environment you are designing for is MIDP, a version of J2ME that runs on mobile information devices like phones and lower-end PDAs. There are other versions of J2ME, including one other that runs on CLDC, that are not relevant for mobile UI designers. Some high-end PDAs support PersonalJava, which has more capabilities than J2ME.
Applications in J2ME on MIDP devices (MIDlets) consist of a series of screens. There are three major classes of screens:
- High-level screens, pre-built for common situations. These are List, Alert, and TextBox screens.
- Forms. You can put all sorts of elements on a Form. New in MIDP2 are CustomItems, which allow you to design every behavior and appearance you want as items on a Form.
- Low-level screens, where you get control over key input and pixels. These are Canvas and GameCanvas screens. Note that a CustomItem, which resides on a Form, has most of the characteristics of a Canvas.
To each type of screen (except an Alert) you can add "abstract commands." There are several types of these, including Screen, Item, Back, Help, Stop, and Exit. Different devices render abstract commands differently. Palm devices show as many commands as will fit along the bottom of the screen, and relegates the remaining into the menu structure. Phones will generally pick the first one and put it on the primary softkey, and relegate the rest to the second softkey. The only control the developer has over the situation is suggestions in the form of command type and priority. New in MIDP2, commands may optionally have short and long labels, allowing you to specify a short form for button or softkey display, and a more verbose form for menu display.
Note that the different methods of rendering commands means that if you have two commands that are logically adjacent (such as Reply and Reply All), there is no way to ensure that they will be adjacent on all devices.
Contents |
[edit] List screens
May be mutually exclusive (radio button), multiple choice (check box), or implicit (each item executes an action - a menu). Use Implicit lists for all your menu. Note that some devices will display list elements on forms as a list screen (for mutually exclusive or multiple choice or both).
[edit] Alert screens
For brief communication with the user, either timed or with an "OK" button. You can't add any commands. Keep your message short and use the default time for timed alerts.
[edit] TextBox screens
Used to allow the user to enter information. But you'll usually use a form instead. Note that some devices will display an input element on a form as a textbox screen.
[edit] Forms
You can put lots of stuff on these, but you can't really control how it's rendered. Each item has (optionally) a label. Items can be strings, input fields, choice groups, images, date fields, and gauges. You have two ways to influence layout: order of items, and newline characters. Devices will have algorithms describing how a form is displayed, and some items are automatically displayed on new lines and some are not. A newline character might be respected by the device.
Actually, MIDP2 completely redesigned the Form layout process. Form items will go onto the same line until either there is no more room or there is some type of new-line control. Plus items have minimum and preferred sizes: form items are allocated to lines based on their minimum size, but are expanded up to their preferred size after the number of items on the line is determined. Similar controls define the height of a line. Before designing a MIDP2 Form, you need to learn all about the layout manager. You can find information at [Sun] or in our new book, [User Interface Guidelines for J2ME MIDP 2].
[edit] What you don't control for any of the high-level screens:
- Font
- Layout (there is some layout control in Forms)
- Whether an element is controlled inline (inline editing is the norm for MIDP2, but not required)
- Exact command position on the screen
- Etc.
[edit] What you do control:
- Content of each screen
You may be inclined to use the Canvas class to create standard components such as menus so that you have more control over the display. Don't do it without good reason (like designing games). Working with the Canvas class means working with pixels and keys, or scaled images and game actions. It means designing for, and testing on, every MIDP device your users might be using. Even if you have the time now, you won't in the future. Understand that the lack of control over layout is one of the constraints of working with MIDP.
[edit] Canvas
You have lots of control over this screen, but if you want the user to use something beyond up, down, left, right, select/fire, A, B, C, D, and the DTMF keys (0-9, *, #), you'll have to test on every target device. So you won't be doing this in most cases. If possible, use scaled layout and graphics that resize themselves based on screen size; otherwise, you'll have to have different versions of the graphics for different screen sizes. You'll have to manually implement a touch event handler so folks with PDAs can use your application easily. In short, use this screen only when you need interactive graphics. New in MIDP2 is tiles and sprites. Tiles let you quickly and inexpensively build and swap backgrounds; sprites let you create things that move along the background. Sprites have built-in collision detection, making game development far easier.
[edit] Definitions
- MIDP
- Mobile Information Device Profile
- CLDC
- Connected Limited Device Configuration
- KVM
- Kilobyte Virtual Machine
- J2ME
- Java 2, Micro Edition
