Using Abstract Commands

Actions that are not built into screen components (as dismissing is built into modal alerts), and are not low-level phone pad or game actions, are abstract commands. For example, abstract commands include actions such as restarting a game, selecting a movie from a list, or getting help.

app Developers

Strongly Recommend: Give each screen at least one command that enables the user to move to the next screen or to exit the app.

Although the MIDP specification permits an app to have screens without abstract commands, app developers should not create them. Such an app would be unusable; its users would be stuck on the screens that have no abstract commands.

MIDP Implementors

Recommend: Give users a way to quit an app that has a screen without an abstract command. One way to do this is to add a command of type EXIT to each screen.

Determine the Abstract Commands for Each Screen

For example, SmartTicket is made up, in part, of the Splash screen, the screen that lists the high-level tasks users can do, and the screen for choosing a movie. The abstract commands associated with those screens are shown in Table 12.3.

Table 12.3. Screen Mock-ups and Abstract Commands

app Developers

Strongly Recommend: For each screen, select a type for each abstract command first, then prioritize the commands within each type. Resist the temptation to prioritize first. MIDP implementors map abstract commands by type, and consider priority a suggestion.

Consider: For each screen, ensure that commands of the same type have different priorities. Assigning commands the same type and priority does not help MIDP implementors with the layout of your abstract commands: commands with equal type and priority can appear in any order. The exception to giving every command associated with a screen a unique type/priority pair is paired actions—actions that work together, often to toggle some behavior. (See "Paired Commands" on page 181 for more information.)

For example, some MIDP implementors map the most important command within a type to a button, and place the rest on a menu. If multiple commands in a command type have top priority, then the MIDP implementor has no way to know which command to map to the button. Table 12.2 and Table 12.1 show the abstract commands associated with the Movie-Choosing screen of SmartTicket, and their priorities. Note that the two commands of type SCREEN have different priorities. Also note that the ITEM command for the screen is a lower priority than the item-specific commands. This ensures that if your MIDlet runs on a device that orders ITEM commands strictly by priority (instead of separately sorting item-specific and item commands, as recommended), your item-specific command will still appear more prominently.

Minimize Abstract Command Instances

Abstract commands can be used by multiple screens. The app would have less code, and possibly fewer maintenance issues, if screens that had the same abstract commands shared abstract command instances. For example, assume you have decided to update your MIDlet code to change the label of an abstract command present on several screens. If the screens all used the same abstract command instance, you would only have to change the code in one place.

app Developers

Consider: As you implement your app, use the same Command instance for abstract commands on different screens if they share the same type, label, and priority. Sharing commands across screens reduces the size of your app. This is an advantage unless sharing commands compromises your user-interface design.

If you would naturally give the commands on different screens different values, for example the same type and label but different priorities in relation to other commands of the same type, then create multiple Command instances. Note that it is not the absolute value of the command that is important, but its relationship to the other abstract commands of the same type on the screen.

Test on Multiple Devices

It is tempting, if an app is tested on a particular MID, to design for that layout. This can lead to problems because of the variation in MIDs' user interfaces.

app Developers

Consider: Test your MIDlets on multiple platforms to ensure that your app is usable and does not violate user-interface conventions.

Recommend: Become familiar with the user-interface conventions of common MIDs so that you can design and create apps that integrate cleanly into the native user interface of the device.

Paired Commands

Paired actions work together, often to toggle some behavior. The members of a paired action do not appear on the screen at the same time. For example, Pause and Resume are paired actions. When the user is running the app the Pause command would be available. If the user pauses the app, the Pause command would no longer be available; Resume would be available instead. Ideally, when the user selects the visible command of a paired action, the other member of the pair would appear in the same place in the user interface. That is, one command of the pair should seem to take the place of the other. Screenshot shows an example of a paired action in an older version of the SmartTicket app. Table 12.4 shows that the abstract commands in this paired action have the same type and priority.

Screenshot Paired Actions in an Earlier Version of SmartTicket

app Developers

Recommend: To create a paired action, create two abstract commands that have different labels but the same types and priorities. You cannot create a single command and change its label because an abstract command is immutable: once created it cannot be changed. Immutable objects have a number of advantages, as detailed in Effective Java Programming Language Guide (Java Series) [15]. It also means that when you design a paired action, you create two abstract commands.

Recommend: Make sure that other commands on the paired action's screen, which have the same type as the paired action, have different priorities from it. This, in addition to giving the paired action's commands equal types and priorities, should enable MIDP implementors to replace one member of a paired action with the other.

For example, Table 12.4 shows that the priorities of the commands on the screen in Screenshot have the same priority.

Table 12.4. Abstract Commands in SmartTicket, Organized by Screen