The Lightweight UI Toolkit library helps you create appealing graphical user interface (GUI) applications for mobile phones and other devices that support MIDP 2.0. Lightweight UI Toolkit supports visual components and other user interface (UI) ingredients such as theming, transitions, animation and more.

The Lightweight UI Toolkit is a lightweight widget library inspired by Swing but designed for constrained devices such as mobile phones and set-top boxes. Lightweight UI Toolkit supports pluggable theme-ability, a Component and Container hierarchy, and abstraction of the underlying GUI toolkit.

The below figure shows the widget class hierarchy

LWUIT strives to enable great functionality on small devices that might be incapable of anti-aliasing at runtime, or might choke under the weight of many images. To solve these problems the LWUIT library ships with an optional resource file format that improves resource utilization.

The below code is a simple hello world example written on top of MIDP.

import com.sun.lwuit.Display;

import com.sun.lwuit.Form;

import com.sun.lwuit.Label;

import com.sun.lwuit.layouts.BorderLayout;

import com.sun.lwuit.plaf.UIManager;

import com.sun.lwuit.util.Resources;

public class HelloMidlet extends javax.microedition.midlet.MIDlet {

public void startApp() {

//init the LWUIT Display

Display.init(this);

// Setting the application theme is discussed

// later in the theme chapter and the resources chapter

try {

Resources r = Resources.open("myresources.res");

UIManager.getInstance().setThemeProps(r.getTheme("mytheme"));

} catch (java.io.IOException e) {

}

Form f = new Form();

f.setTitle("Hello World");

f.setLayout(new BorderLayout());

f.addComponent("Center", new Label("I am a Label"));

f.show();

}

public void pauseApp() {

}

public void destroyApp(boolean unconditional) {

}

}

The very first line of code for any application using the Lightweight UI Toolkit library must register the main class with the display. This behavior is tool-specific. In MIDP there is not much you can do without a reference to the parent MIDlet, so this operation must be performed in the beginning of the application.

For increased compatibility, the Lightweight UI Toolkit library completely handles and encapsulates UI threading. It has a single main thread referred to as the "EDT" (inspired by the Event Dispatch Thread in Swing and AWT). All events and paint calls are dispatched using this thread. This guarantees that event and paint calls are serialized and do not risk causing a threading issue.

It supports several widgets like Component, Container, Form, Label, Button, Radio Button, Button Group, Check Box, Combo Box, TextArea, Tabbed Pane and Dialog Boxes. Usage is similar to their swing counterparts.

Usage of the List widget is similar to the usage of JList of swing. It uses DefaultListModel and ListCellRenderer too.

It also supports layout managers . Like swing, it has BorderLayout, BoxLayout, FlowLayout, GridLayout and GroupLayout. It also has supports for fonts and themes.

There is also support for packing images to minimize memory usage. Images can occupy a great deal of memory in runtime. For example, a background image scaled to a phone with 320x240 resolution with 1.6 million colors would take up 320x240x4 bytes (307200 bytes = 300 kilobytes)! Some devices have barely 2mb of RAM allocated to Java, yet feature high resolutions and color depths, leaving very little space in which the application can function. Packed images work on the tried and true concept of using a palette to draw. Rather than store the image as a set of Alpha, Red, Green, Blue (ARGB) values, the packed image relies on the notion that there are no more than 256 colors in an image (if there

are more, the Ant task tries to gracefully reduce the color count, resulting in lost details). An image with 256 colors or less can be represented using an array of bytes and an array of integers (no bigger that 256x4=1kb) thus saving approximately 70 percent of the RAM required for the image!

Transition between forms is also supported. When a new form is displayed to can be faded in or slided in.

Touch screens are supported out of the box, however, designing a UI for finger operation is very different from designing a UI for general use. Finger operations expect everything to be accessible via taps (not keys). A touch interface expects widgets to be big enough to fit the size of a human finger.

This is somewhat counter-intuitive because normally you might want to cram as much UI detail as possible into a single screen to avoid scrolling. Component sizes can be easily customized globally using the theme. Simply set the default padding attribute to a large enough value (e.g. 5, 5, 5, 5) and all widgets “grow” to suit finger navigation. It is also a good practice to use buttons for touch devices and avoid menus where possible.

---

Add this page to your favorite Social Bookmarking websites