Tips for Writing MIDP Applications, Part 2

Part 1 of this article discussed several higher-level tips for writing MIDP applications. In this part, I thought I’d delve a little more deeply into the weeds for some specific tips on using various controls in the MIDP toolkit.

Sign Your Application

See my earlier post about application signing. If at all possible, sign your application with a Verisign code-signing certificate. JavaVerified is even better,
but is not realistically achievable for many applications.

Keep it Responsive

• Use a splash screen if your application takes more than a few seconds to load, and put complex initialization code in a separate thread.
• Use gauges for any operations that must complete before a user can proceed.
• Make sure those gauges appear within one second of the keypress that initiated the action.
• Put all blocking requests, or any request that might take some time to return, into a separate thread. By all means, keep them out of the event handling thread.

I try to keep abstraction to a minimum in MIDP applications, due to device constraints, but one area I always use abstract classes is network connections. For example, I commonly use a WebConnection abstract class that takes care of the details of creating and displaying a gauge, creating a thread, initiating a connection, handling the connection and any updates, closing the connection, handling stops, and passing off control. I extend this abstract class for any connection that is needed. This keeps the application both responsive and consistent.

Text Fields

• Don’t override a device’s native input method if the user is expected to enter anything but short text strings.
• Use constraints where appropriate: numeric, decimal, phonenumber, email, url.
• Use modifiers where appropriate: initial_caps_sentence, initial_caps_word, non_predictive, password, sensitive, uneditable.
• Use input modes where appropriate: is_latin_digits, midp_lowercase_latin, more.
• Rather than requiring text entry, allow users to select from a list, if at all possible.
• When using lists, offer the most popular choices near the top.
• If you are forced to use text boxes for data entry, provide a reasonable default value.
• Persist data within and between visits, and present that data as options to reduce input.

Titles and Labels

• Provide short and long command labels (just short if targeting MIDP 1.0).
• Keep your short labels one word long, and front-load them.
• Screen titles might be truncated, so put the most important characters at the beginning of the title.
• Make the first characters of your labels unique from other labels. This will enable users to easily differentiate among the commands available to them.

Alerts

• Only interrupt the user with a modal alert when you are bringing something to their attention that they must acknowledge.
• Keep text to a minimum on timed alerts.
• Use different screen designs for modal and timed alerts. Users will quickly learn (sometimes unconsciously) which screens require acknowledgement and which will dismiss themselves.
• Provide a command to dismiss all alerts. Give the command a type of ok or cancel.
• Use alert types appropriately: info for information, warning for potentially dangerous operations, error for error messages, alarm for notifications, and confirmation for confirmation prompts.

Commands

Use command types and priorities appropriately. This will help the implementation determine how commands should be presented to the user to maintain consistency. Unfortunately, it’s also common for related commands to be separated by one or more unrelated commands, and it generally takes a little trial and error to get things right.

The available command types are back, screen, item, ok, cancel, stop, help, and exit.

• BACK: action to move to the previous screen or state.
• SCREEN: action affects the entire screen.
• ITEM: action affects a single item on the screen.
• OK: action to positively acknowledge a query.
• CANCEL: action to negatively acknowledge a query.
• STOP: action to stop a process.
• HELP: action to get help.
• EXIT: action to exit MIDlet.

Conclusion

What, nothing earth-shattering? No, MIDP application development is surprisingly easy. The difficult part is deploying to multiple handsets. For the most part, use common sense, think like a task-based user, and pay attention to device constraints when developing UI’s for mobile applications, and you’ll largely avoid many common problems.

The MIDP API is small, and it pays to learn it thoroughly. Knowing things like available constraints, input modes, text wrapping, layout directives, and the like can really keep you out of trouble.

If you have any tips you’d like to add, please leave a comment or e-mail me directly.

Tags: J2ME, Java ME, mobile software, mobile development, MIDP, Java