Java 2 Micro Edition

1
Java 2 Micro Edition

• Dean W. Andreakis
• April 27, 2001
• SE690

2
Objectives

• Review J2ME LCDUI API in more depth
• Demonstrate the features and use of the J2ME
  Wireless Toolkit
• Update on my idea of extending the LCDUI to
  include a simple layout manager

3
J2ME Overview

• Java 2 Micro Edition defines a small footprint
  version of Java for resource constrained devices.
  Specifically, code space of lt512K and RAM (for
  java heap) of 64KBytes or more.
• The Connected Limited Device Configuration (CLDC)
  defines the minimum required complement of Java
  technology components and libraries for small
  connected devices. Java language and virtual
  machine features, core libraries, input/output,
  networking and security are the primary topics
  addressed by this specification.
• The Mobile Information Device Profile (MIDP)
  defines an additional set of APIs on top of the
  Connected Limited Device Configuration (CLDC) for
  small handheld devices such as PDAs and cellular
  phones. These include UI, Persistence,
  Networking, Timers, and Application Lifecycle.

4
LCDUI API

• The LCDUI (Liquid Crystal Display User Interface)
  provides basic user interface control to the
  midlet writer.
• A straight subclass of AWT or Swing was not
  implemented due to the high number of short lived
  objects (such as event objects etc.) that are
  created. This would cause a significant
  performance penalty due to garbage collection to
  the already resource constrained device.
• The LCDUI API is split into a High-level API and
  a Low-level API.
• The High-level API provides for pre-defined
  screens and forms. The form allows addtion if
  items such as text fields and buttons but they
  are added in a strict vertical fashion. No
  fine-grained control over positioning within the
  form is provided.
• The Low-level API provides complete control over
  the physical display area for games etc. that
  require this level of control.

5
LCDUI Structure

• The LCDUI API is broken into two levels of
  abstraction The High-Level API and the
  Low-Level API.
• The central concept behind the High-Level API is
  a Screen.
• Screens organize the UI into logical sections.
• Each application has a Display for which a single
  Screen is shown.
• The application can then apply the necessary
  Screen to the Display depending upon the state of
  the application.
• The Low-Level API uses a Canvas to draw low-level
  graphics objects.

6
LCDUI Structure
7
LCDUI High-Level API

• The High-Level API provides the maximum
  portability of applications across devices.
• This is achieved with a high-level of abstraction
  combined with minimum control over look and feel.
• Basic interactions such as navigation and
  scrolling are performed by the device and as such
  the application is not aware of them.
• Applications cannot access low-level input events
  such as key presses etc.
• The application only receives generic pre-defined
  events. It registers for these events via a
  listener event model.
• The Screen is the central concept of the
  high-level API. Each screen can have a title,
  multiple commands, and a Ticker.
• The main four screens are List, Textbox, Alert,
  and Form.

8
List Screen

• The List screen provides for a list of choices.
• Each choice has a string associated with it along
  with an icon or image.
• The user may traverse or scroll thru the List but
  this action is handled by the device. The
  application is unaware of these actions.
• The application is notified of a generic command
  event via the CommandListener of the Screen.
• There are three types of Lists Implicit,
  Exclusive, and multiple choice.
• Implicit lists are for quick selections when the
  user selects only one element.
• Exclusive Lists are shown as radio buttons are
  provide for selection of a single element.
• Multiple choice lists are check boxes that allow
  the user to select zero or more elements.

9
List Screen Example
10
TextBox Screen

• The TextBox screen allows the user to enter text
  and to edit text.
• Input constraints are defined for ANY, NUMERIC,
  PASSWORD, URL, EMAILADDR, and PHONENUMBER. These
  constraints can be used to limit the valid
  characters entered but does not insure proper
  form or syntax.

11
TextBox Screen Example
12
Alert Screen

• The Alert screen displays a message to the user
  along with an optional image for a pre-defined
  amount of time.
• AlertTypes can be defined to indicate the nature
  of the information. They are Alarm,
  Confirmation, Error, Info, and Warning. Sounds
  can be associated with each alert type if desired.

13
Alert Screen Example
14
Ticker

• A Ticker is made of a string that scrolls
  continuously across the display
• Tickers can be put on any Screen such as Form,
  Alert, List, and TextBox.
• An example of a Ticker added to a List

15
Form Screen

• A Form is a screen that can contain any
  combination of Items.
• Items include Strings, Images, TextFields,
  DateFields, Gauges, and ChoiceGroups.
• All Items are added in a vertical fashion and all
  scroll together vertically. No control over exact
  placement of Items is provided.

16
Form Screen Examples
17
LCDUI Low-Level API

• The Low-Level API provides for exact control of
  low-level graphics primitives such as drawing
  text, images, lines, arcs, rectangles, etc. to a
  Canvas.
• Low-level events such as keypad events are
  accessible. The Midlet writer would override and
  implement the Canvas methods keypressed,
  keyreleased, keyrepeated.
• The Canvas and Graphics classes make up the
  Low-Level API for LCDUI.

18
Low-Level API Some Specifics

• Midlet writer would subclass Canvas and implement
  the paint method to use the Graphics class
  methods.
• The screen is repainted on demand by calling the
  repaint() method of the Canvas object.
• Coordinate system has the origin at upper left of
  display. Positive X goes to the right. Positive Y
  goes top to bottom.
• Methods are provided for defining a clipping
  region and for translating the origin.
• Color is handled as a 24-bit value representing a
  raw RGB value.
• Lines can be solid or dotted.
• Font sizes, faces, and styles can be requested.
  Ex small, med, large size, proportional,
  monospace, system, face, plain, bold, italic,
  underlined styles.

19
Low-Level API Example
20
J2ME Wireless Toolkit

• Developed by SUN to aid in development of MIDP
  compliant applications
• Implements the MIDP 1.0 APIs on WIN32
• Includes ability to automatically create JAR file
  (including manifest) and JAD file
• Comes with Graphics of color and grayscale cell
  phone and pager.
• Can trace method calls, garbage collection, class
  loading, and exceptions.

21
LCDUI Simple Layout Manager for Low-Level API
import javax.microedition.lcdui. public class
ManyCanvas extends LayoutCanvas public
ManyCanvas()setLayout(new BorderLayout()) prote
cted void paint(LayoutGraphics g) // Draw the
frame g.setColor(0xffffff) add((g.drawString
(" Balls")), North)
//original call g.drawString(" Balls", 5,
height-14, 0)
22
LCDUI Simple Layout Manager for Low-Level API

• Status Skeleton source exists for this idea in
  Together Control Center model.
• Plan is to get simple BorderLayout manager
  implemented and running on J2ME Wireless Toolkit
  for June 2nd Symposium.

23
Further Resources

• J2ME Wireless Toolkit v1.0.1 available at
  java.sun.com/products/j2mewtoolkit/
• java.sun.com search on J2ME for many whitepapers
  etc. related to J2ME MIDP and CLDC APIs.

24
References Acknowledgements

• Some of the code examples and screenshots for
  this presentation were from an upcoming
  Addison-Wesley book on J2ME by Mark Vandenbrink
  of Motorola and other co-authors from SUN.
• CLDC 1.0 Specification at java.sun.com
• MIDP 1.0 Specification at java.sun.com