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


Become a Cross-platform Wireless UI Expert : Page 2

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.

Forget AWT and Swing in MIDP
Desktop Java programmers are familiar with AWT or Swing for building UIs, but you won't find either of those in a MIDP programming environment because of the size and memory constraints on the majority of handheld devices. At a more fundamental level, concepts such as windows, point-and-click, drag-and-drop and other desktop UI metaphors don't exist in MIDP either.

So, when programming user interfaces for CLDC profiles, you'll have to forget your reliance on layout managers, primitive component spacing, custom interface development, and assumptions about the look and feel, functionality, and execution of your interface elements. If you've worked with AWT you may be able to transfer some of that experience over to handheld device UI development.

J2ME's User Interface Facilities
For device portability, one segment of the J2ME API, called the "High-Level User Interface API," uses a high abstraction level to provide developers with a set of UI components. This high abstraction level lets applications maintain consistency in style and functionality with UI components provided natively by the device, but it's also a tradeoff because it leaves the J2ME application developer with little control over many aspects of the user interface. You'll need to plan accordingly to overcome the many obstacles that such limited functionality places on your development.

Fortunately, the J2ME specification also provides more direct control of the screen through the Low-Level UI API. This set of classes provides almost direct access to the screen space allocated to the application. For example, you can use the classes in this segment in applications such as games to draw primitives, including circles, squares, lines, images, to clip portions of the screen, etc.

You can't use both the high- and low-level interfaces together though, so if you need to use a standard UI control provided by the High-Level UI API while using the Low-Level UI API your only option is to reimplement such a control. Reimplementation might be appropriate for a specific application but might also be non-portable.

For the sample application we'll stick with the High-Level UI API for maximum portability.

Take a look at the UIDemo application provided by Sun's Wireless Toolkit while you read the next part of this article.

Close Icon
Thanks for your registration, follow us on our social networks to keep up-to-date