Java ME Display and Portability
There have always been development options when creating GUIs for Java ME applications. The problem has been that none of the options have been great.
The CLDC/MIDP LCDUI high-level user interface API provides lowest common denominator capability. This gives applications maximum portability at the cost of smart displays. While the high-level API is functional and abstracts developers from low-level drawing details, it forces UIs into a pre-defined look and feel. Alternatively, MIDP LCDUI low-level API requires developers to "paint" graphical primitives (text, images, lines, rectangles, and arcs) to develop the application's UI. This painstaking work often results in more compelling UIs, but since the low-level API grants access to details that are specific to a device, it can result in less portable applications.
More recent Java ME specifications define optional Java ME support for Scalable Vector Graphics (SVG) and even some of the Java SE graphics and user interface capability (see JSR 209: Advanced Graphics and User Interface). However, as they are optional, developers are again handcuffed to a limited set of devices.
For the Connected Device Configuration (CDC) there is the full featured Abstract Windows Toolkit (AWT), but if an application needs to run across the CLDC and CDC, the same portability issue arises.
Of course, there are third-party libraries and tools such as J2MEPolish, Paxmodept, Twuik, or Nokia's eSWT. Cost, portability (especially across configurations), and standard support are issues when considering third-party libraries.
The display capability of mobile devices, while sometimes impressive given the size of the device, varies greatly from platform to platform. Finding a single, rich display, easy-to-use API that abstracts developers away from the low-level details while also porting to the multitude of mobile platforms has been hard, but it's exactly the purpose behind LWUIT.
Stated right in its documentation, LWUIT "tries to avoid the 'lowest common denominator' mentality." It achieves this goal by implementing its own set of abstracting component classes on top of the native system canvas.
Getting and Setting Up LWUIT
An early access release of the LWUIT, including the class library, documentation, tools and example code is available here under a Sun License Agreement. As of this writing, toolkit source code is not yet available (see LWUIT future below).
The early access release comes in the form of a single 5.25MB zip file. The LWUIT library jar (lwuit.jar) should be extracted from this zip file and made available to your Java ME project. Using NetBeans, this means adding the JAR to your project (see Figure 1). Using Sun Java Wireless Toolkit for CLDC, add the JAR to the tool's \lib\ext folder and bundle the JAR with the project (see Figure 2). The Sprint Wireless Toolkit version 3.3 has already been configured to work with LWUIT. When creating a project with the Sprint toolkit, simply choose to create a LWUIT project. As with any JAR, the API is available to the classes of the application via simple import.
Figure 1. Add LWUIT to a NetBeans Project: Select the Projects tab, right-click on Resources, choose Add Jar/Zip…. Locate the LWUIT JAR file using the browse window.
Figure 2. Adding LWUIT to a Wireless Toolkit Project: Click on the Settings… button on the WTK toolbar as shown. In the Settings dialog, pick the External APIs icon and make sure the LWUIT JAR is bundled with the project.
The LWUIT JAR is about 225KB. While not insignificant, the power LWUIT packs makes it well worth the space allocation.