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


Become a Cross-platform Wireless UI Expert : Page 7

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.

Figure 9: The search screen while a search is performed.

User Input
To search for a book, the application uses a TextField into which you enter a search term. Navigation is simple; on the search screen the only commands available are to exit or to begin the search.

After beginning a search users can cancel the current search or exit the application. Canceling the search returns the user to the search screen.

Figure 10: A single search result is returned.

If the search finds an exact match for the query string then the application displays the detail information screen for that one result immediately, saving users the trouble of clicking the item.

When a search returns more than one result, the application displays the first five results as items in an implicit List. The user can drill down into a result by selecting it, exit the application, conduct a new search, or move to the next or previous set of results.

Finally, when users are on an information screen they see an exit button, a new search button, or, if there are more results, a back button.

Figure 11: Multiple search results are returned and a scroll button is added.

With the design reasonably complete, you can start coding UI functionality; the backend development can proceed separately. Start by creating self-contained classes derived from Form. For example, the SearchForm displays a TextField for data entry and prepares commands and titles as appropriate for this form.

Create instances of Commands that you've identified as shareable. Make them available in a centralized location. This centralized location will also hold more general Commands such as Exit or New Search. Although you can create a separate class, the sample application handles centralized behavior in the MIDlet's main class.

In general, forms that contains more than three Commands are potentially confusing to users. The multiple result list screen in this project is an example, of keeping a complicated set of commands down to three (see Figure 11).

To make the user aware of more results than the application can display at one time, the application displays the current result list position (i.e. page 1 of 4) in the Form's default Ticker item. Placing it in the Ticker guarantees that the information is visible somewhere on the form, and because it iterates it will attract users' attention.

The network search is a time-consuming process, so a class derived from Runnable performs the search in a separate thread. The doSearch method of the SearchActionForm creates the thread and starts it. A non-interactive gauge tells users how much time is left before the search times out—and the animation shows them that the application is not frozen. Note that a StringItem displays the actual value of the Gauge.

Nothing is more frustrating than being unable to cancel an action, so the application includes a Command to cancel the search. The doCancel method of the SearchActionForm sets the worker thread and the timer task to null, which lets the garbage collector know that it's OK to release those objects resources and return some memory. The method also sets any unused forms that will not be used to null; otherwise, the VM may keep the resources associated with those forms in memory.

Comment and Contribute






(Maximum characters: 1200). You have 1200 characters left.