Home > Articles

  • Print
  • + Share This
This chapter is from the book

7.5 The Impatient User

The "anytime, anywhere" convenience is the biggest strength of mobile applications. However, it is a major challenge to implement a truly convenient solution for human users. Users treat mobile devices as personal belongings and have high expectations for their devices.

In this section, we discuss efficient and responsive UI designs, which are crucial to the adoption of mobile applications. Another aspect of personal devices is that users would like to customize them to fit their individual style. We discuss preference management as well in this section. Most issues we discuss in this section are covered in the Smart Ticket sample application (Chapter 5).

7.5.1 Take Advantage of the Rich UI

Rich UI is one of the great appeals of smart clients. We should make judicious use of advanced UI components, such as direct draw on canvas and animation sprites. In the Smart Ticket application, the use of raw canvas to draw seating maps is an excellent example of appropriate UI usage. Advanced UI widgets are supported in the MIDP v2.0 specification. Device vendors also often provide their own UI enhancement APIs.

As described in Section 7.3.3, the MVC pattern (see Chapter 5 Section 5.3.1) is a powerful tool to support multiple optimized UIs for different devices while reusing the same business logic components.

7.5.2 Use Threads Judiciously

UI lock-up is one of the most annoying problems users can experience. On PCs, users are used to crashes in a certain popular operating system, and they can just hit the reboot button. But the user's tolerance for malfunctioning mobile devices is much lower. We expect our cell phones to work out of the box like any other electronic household appliance. The best practice to avoid hang-ups in the main UI thread is to put all lengthy or potentially blocking operations in separate threads. In fact, the MIDP specification clearly states that the UI event handler (i.e., the CommandListener. commandAction() method) must "return immediately," which implies that proper UI threading is actually mandated by the specification. Listing 7.2 shows the use of threads.

Listing 7.2. The use of threads

public class DemoMIDlet extends MIDlet implements CommandListener {

  // other methods

  public void commandAction(Command command, Displayable screen) {
    if (command == exit) {
      // handle exit
    } else if (command == action) {
      WorkerThread t = new WorkerThread ();

  class WorkerThread extends Thread {

    void run () {
      // Do the work

In the Smart Ticket sample application, the use of threads is pushed one step further: Each worker thread also has a helper thread that displays an animated gauge to indicate the progress of the worker thread. This is especially useful to keep the user informed during lengthy network operations.

7.5.3 One Screen at a Time

Mobile users have relatively short attention spans. We should break up lengthy operations into small pieces to show one screen at a time and offer users options to pause or abort in the middle of the process. Smart clients are especially well equipped to handle the screen flow process, since on-device storage could cache information between screens. A good example of screen flow is the "buy a ticket" action in the Smart Ticket application.

7.5.4 Store User Preferences

Mobile devices become more personal and hence have more value if they are customized to fit the user's personal preferences. Advanced mobile applications should store its owner's preference data on device. As we see in the Smart Ticket application, the stored preferences also allow users to have smoother workflow experiences. For example, the user does not need to stop and enter her credit card information in the middle of the purchasing flow.

7.5.5 Use Deployment Descriptors

The mobile application can also be customized at the back end before the user downloads it. For example, when a user signs up on a Web site, the site automatically customizes the download package with the profile derived from the submitted forms. We can customize the application without rebuilding it through the deployment descriptors. The MIDP specification defined the format and usage of Java Application Descriptor (JAD) files. But for other J2ME platforms, we still need to embed property files and/or other nonstandard configuration files in the custom-generated JAR package.

  • + Share This
  • 🔖 Save To Your Account