Wireless Java
  • Alternative view 1 of Wireless Java
  • Alternative view 2 of Wireless Java

Wireless Java

by Qusay H. Mahmoud, H. Qusay Mohmoud, H. Qusay Mohmoud, Robert Eckstein
     
 

Learning Wireless Java is for Java developers who want to quickly come up to speed and create applications for the Micro Edition audience. This book covers the Connected, Limited Device Configuration and the Mobile Information Device Profile (MIDP), both currently available from Javasoft. The CLDC contains APIs for small devices that are constrained by both

Overview

Learning Wireless Java is for Java developers who want to quickly come up to speed and create applications for the Micro Edition audience. This book covers the Connected, Limited Device Configuration and the Mobile Information Device Profile (MIDP), both currently available from Javasoft. The CLDC contains APIs for small devices that are constrained by both memory and processing power. MIDP builds on top of the CLDC and adds APIs specifically for devices such as mobile phones and pagers, allowing programmers to create MIDlet applications.

This book offers a solid introduction to J2ME and MIDP, including an explanation of the J2ME Wireless Toolkit, the MIDlet lifecycle methods, the Java application manager, and the CLDC and MIDP constraints. In addition, we cover the javax.microedition.io, javax.microedition.rms, javax.microedition.lcdui, and javax.microedition.midlet classes, as well as the modified java.lang, java.io, and java.util classes. Discussion centers around building safe, compact applications with the sophisticated graphical interface, database, and networking capabilities that the J2ME supports. In addition, this book also shows you how to download your applications to the latest J2ME-enabled devices, including the Motorola i50x and i85s phones and upgraded Palm handhelds.

Editorial Reviews

bn.com
The Barnes & Noble Review
Quietly, Java Virtual Machines have found their way into an enormous number of wireless devices. Using Java 2 Micro Edition, it's now possible to build some extremely powerful and flexible enterprise applications. It's just a matter of time -- and now's the time to prepare. If you want to leverage your hard-won Java skills in tomorrow's wireless environments, here's the book to get you started.

Learning Wireless Java assumes you know your way around Java but assumes no wireless programming experience. Qusay Mahmoud starts with an overview of the J2ME platform and Sun's "Honey, I Shrunk the JVM and APIs" approach to wireless development. He presents in-depth explanations of the key elements of the J2ME application runtime environment: the Connected Limited Device Configuration (CLDC), Sun's stripped-down KVM virtual machine, and the Mobile Information Device Profile (MIDP) APIs, which provide for user interfaces, persistence, networking, storage, and other essential features of wireless applications.

You'll start writing code quickly, then master each key aspect of MIDlet programming. There's a full chapter on wireless user interface development (and why you can't just use your AWT or Swing classes); detailed coverage of screen navigation and event handling; and example-rich coverage of J2ME networking (including security). The book ends with a closer look at J2ME on the Palm OS wireless platform and a quick API reference to four javax.microedition packages you'll be working with constantly. (Bill Camarda)

Bill Camarda is a consultant, writer, and web/multimedia content developer with nearly 20 years' experience in helping technology companies deploy and market advanced software, computing, and networking products and services. He served for nearly ten years as vice president of a New Jersey–based marketing company, where he supervised a wide range of graphics and web design projects. His 15 books include Special Edition Using Word 2000 and Upgrading & Fixing Networks For Dummies®, Second Edition.

Product Details

ISBN-13:
9780596002435
Publisher:
O'Reilly Media, Incorporated
Publication date:
01/08/2002
Edition description:
New Edition
Pages:
266
Product dimensions:
6.92(w) x 9.28(h) x 0.69(d)

Read an Excerpt

Chapter 5: MIDP GUI Programming

User interface requirements for handheld devices are different from those for desktop computers. For example, the display size of handheld devices is smaller, and input devices do not always include pointing tools such as a mouse or pen input. For these reasons, you cannot follow the same user-interface programming guidelines for applications running on handheld devices that you can on desktop computers.

The CLDC itself does not define any GUI functionality. Instead, the official GUI classes for the J2ME are included in profiles such as the MIDP and are defined by the Java Community Process (JCP). You'll note that the GUI classes included in the MIDP are not based on the Abstract Window Toolkit (AWT). That seems like a major issue, which brings us to the following question. Why Not Reuse the AWT?

The MIDP Expert Group decided not to subset the existing AWT and Project Swing classes for the following reasons:

  • AWT is designed for desktop computers and optimized for these machines.
  • AWT assumes certain user interaction models. The component set of the AWT is designed to work with a pointing device such as a mouse; however, many handheld devices, such as cell phones, have only a keypad for user input.
  • AWT has a rich feature set, and includes support for functionality that is not found or is impractical to implement on handheld devices. For example, the AWT has extensive support for window management, such as resizing overlapping windows. However, the limited display size of handheld devices makes resizing a window impractical. Therefore, the window and layout managers within the AWT are not required for handheld devices.
  • When a user interacts with an AWT-based application, event objects are created dynamically. These objects exist only until each associated event is processed by the application or system, at which time the object becomes eligible for garbage collection. The limited CPU and memory of handheld devices, however, cannot handle the burden.

The MIDP GUI APIs

Because of the issues outlined earlier, the MIDP contains its own abbreviated GUI, which is much different from AWT. The MIDP GUI consists of both high-level and low-level APIs, each with their own set of events. This chapter discusses and shows examples of using objects from both the high-level and low-level APIs. Handling events from APIs, however, is deferred to the next chapter.

The high-level API is designed for applications where portability between mobile information devices is important. To achieve portability, the API employs a high-level abstraction and gives you little control over its look and feel. For example, you cannot define the visual appearance (shape, color, or font) of the high-level components. Most interactions with the components are encapsulated by the implementation; the application will not be aware of them. Consequently, the underlying implementation does the necessary adaptation to the device's hardware and native user interface style. Classes that implement the high-level API all inherit the javax.microedition.lcdui.Screen class.

The low-level API provides little abstraction. It is designed for applications that need precise placement and control of graphic elements, as well as access to low-level input events. This API gives the application full control over what is being drawn on the display. The javax.microedition.lcdui.Canvas and javax.microedition.lcdui.Graphics classes implement the low-level API. However, we should point out that MIDlets that access the low-level API are not guaranteed to be portable, because this API provides mechanisms to access details that are specific to a particular device.

The MIDP GUI Model

Here's how the MIDP model works, in a nutshell. In order to show something on a MIDP device, you'll need to obtain the device's display, which is represented by the javax.microedition.lcdui.Display class. The Display class is the one and only display manager that is instantiated for each active MIDlet and provides methods to retrieve information about the device's display capabilities.

Obtaining the device's display is easy. However, this object by itself isn't very interesting. Instead, the more interesting abstraction is the screen, which encapsulates and organizes graphics objects and coordinates user input through the device. Screens are represented by the javax.microedition.lcdui.Screen object and are shown by the Display object by calling its setCurrent( ) method. There can be several screens in an application, but only one screen at a time can be visible (or current) in a display, and the user can traverse only through the items on that screen. Figure 5-1 shows the one-to-many relationship between the display and its screens.

There are three types of screens in the MIDP GUI:

  • Screens that entirely encapsulate a complex user interface component, such as a List or TextBox component (the List component is shown in Figure 5-8 and the TextBox component is shown in Figure 5-15). The structure of these screens is predefined, and the application cannot add other components to these screens.
  • Generic screens that use a Form component. The application can add text, images, and a simple set of related UI components to the form, which acts as a container.
  • Screens used within the context of the low-level API, such as a subclass of the Canvas or Graphics class.

The lcdui Package

All MIDP GUI classes are contained in the javax.microedition.lcdui package. This package contains three interfaces and twenty-one classes, as shown in Table 5-1 and Table 5-2.

Table 5-1: lcdui interfaces

Interface

Description

Choice

Defines an API for a user interface component that implements a selection from a predefined number of choices

CommandListener

Used by applications that need to receive high-level events from implementations

ItemStateListener

Used by applications that need to receive events that indicate changes in the internal state of the interactive items

Table 5-2: lcdui classes

Class

Description

Alert

A screen that shows data to the user and waits for a certain period of time before proceeding to the next screen.

AlertType

A utility class that indicates the nature of the alert.

Canvas

The base class for writing applications that need to handle low-level events and to issue graphics calls for drawing to the display.

ChoiceGroup

A group of selectable elements intended to be placed within a Form.

Command

A construct that encapsulates the semantic information of an action.

DateField

An editable component for presenting calendar data and time information that may be placed into a Form.

Display

A utility that represents the manager of the display and input devices of the system.

Displayable

An object that has the capability of being placed on the display.

Font

A utility that represents font and font metrics.

Form

A screen that contains an arbitrary mixture of items (images, text, text fields, or choice groups, for instance).

Gauge

A utility that implements a bar graph display of a value intended for use in a form.

Graphics

A utility that provides a simple two-dimensional geometric rendering capability.

Image

A utility that holds graphical image data.

ImageItem

A utility that provides layout control when Image objects are added to a form or alert.

Item

A superclass for all components that can be added to a Form or Alert.

List

A screen containing a list of choices.

Screen

The superclass of all high-level user interface classes.

StringItem

An item that can contain a String.

TextBox

A screen that allows the user to enter and edit text.

TextField

An editable text component that can be placed into a Form.

Ticker

A ticker-type piece of text that runs continuously across the display. It can be attached to all screen types except Canvas.

The class diagram in Figure 5-2 shows the major classes and the relationships between them.

The High-Level MIDP APIs

Now, let's see how the various classes in the high-level API can be used to create GUI components. We will cover two parts of this process: working with screens and the components that subclass them, and working with forms and the components that can be arranged in them.

Working with Screens

Having seen an example of a screen, a few questions immediately come to mind: how do you manage screens, how do you navigate through them, and how do you manage the display and the input devices? The answer is that all this functionality is implemented by the Display class, which includes methods for requesting that objects be displayed on the device, and for retrieving properties of the device.

Display

A reference to the device's display can be obtained by providing a MIDlet reference to the static getDisplay( ) method.

public static Display getDisplay(MIDlet c);

This is typically done in the startApp( ) method of a MIDlet, as follows:

public class MyMIDlet extends MIDlet {
 
   Display display = null;
 
   public MyMIDlet(  ) { // constructor
   }
 
   public void startApp(  ) {
      display = Display.getDisplay(this);
   }
 
   // other methods
}

TIP:   The getDisplay( ) method should be called after the beginning of the MIDlet's startApp( ) method, as shown earlier. It should never be called from the MIDlet's constructor, as per the MIDP specification, as it may not be properly initialized by the application manager at that time.

After you obtain a reference to the device's display, you simply need to create a GUI component to show. Note that all of the GUI components in Figure 5-2 implement the Displayable abstract class. You can pass the GUI component you create to one of Display's two setCurrent( ) methods:

public void setCurrent(Displayable d);
public void setCurrent(Alert alert, Displayable d);

The second method is used when you want to show a temporary alert message followed by the displayable GUI element. We'll discuss alerts later on in this chapter.

To find out what is currently being displayed on the device, use the getCurrent( ) method, which returns a reference to the Displayable object that is currently being displayed....

Meet the Author

Qusay H. Mahmoud is an independent contractor for Sun Microsystems. He has written several articles for the Java Developer Connection that cover J2ME, including the MIDP and the CLDC APIs. He has also presented tutorials on developing wireless applications at a number of international conferences worldwide. He is the author of Learning Wireless Java (O'Reilly), and Distributed Programming with Java (Manning Publications).

Customer Reviews

Average Review:

Write a Review

and post it to your social network

     

Most Helpful Customer Reviews

See all customer reviews >