Programming of Handheld and Mobile Devices

1
Programming of Handheld and Mobile Devices

• Lecture 12 lcdui
• Rob Pooley rjp_at_macs.hw.ac.uk

2
The Screen

• The central abstraction of the MIDPs UI is a
  screen.
• A screen is an object that encapsulates
  device-specific graphics rendering user input.
• Only one screen may be visible at a time, and the
  user can only traverse through the items on that
  screen.
• The screen takes care of all events that occur as
  the user navigates in the screen, with only
  higher-level events being passed on to the
  application

3
Categories of Screen

• There are three categories of screens
• Screens that encapsulate a complex user interface
  component (e.g., classes List or TextBox). The
  structure of these screens is predefined, and the
  application cannot add other components to these
  screens.
• Generic screens (i.e., class Form) that the
  application can populate with text, images, and
  simple sets of related UI components.
• Screens that are used in context of the low-level
  API (i.e., subclasses of class Canvas).
• Each screen, except the low-level Canvas, can
  attach a Ticker.

4
Class Display

• The class Display acts as the display manager
  that is instantiated for each active MIDlet and
  provides methods to retrieve information about
  the devices display capabilities.
• A Screen is made visible by calling the
  setCurrent() method of Display.

5
Use of Screen types

• List is used when the user should select from a
  predefined set of choices.
• TextBox is used when asking textual input.
• Alert is used to display temporary messages
  containing text and images.
• A special class Form is defined for cases where
  screens with a predefined structure are not
  sufficient.

6
Using Form

• Form is designed to contain a small number of
  closely related UI elements.
• These elements are the subclasses of Item
  ImageItem, StringItem, TextField, ChoiceGroup,
  and Gauge.
• The classes ImageItem and StringItem are
  convenience classes that make certain operations
  with Form and Alert easier.
• If the components do not all fit on the screen,
  the implementation may either make the form
  scrollable or implement some components so that
  they can either popup in a new screen or expand
  when the user edits the element.

7
Rules of use

• getDisplay() is callable from startApp() until
  destroyApp() is returned.
• The Display object is the same until destroyApp()
  is called.
• The Displayable object set by setCurrent() is not
  changed by the application manager.

8
Roles of MIDlet functions

• startApp - The application may call setCurrent()
  for the first screen.
• The application manager makes Displayable really
  visible when startApp() returns.
• Note that startApp() can be called several times
  if pauseApp() is called in between.
• This means that initialization should not take
  place, and the application should not
  accidentally switch to another screen with
  setCurrent().
• pauseApp - The application may pause its threads.
  
• Also, if starting with another screen when the
  application is re-activated, the new screen
  should be set with setCurrent().
• destroyApp - The application may delete created
  objects

9
Event handling

• There are four kinds of UI callbacks
• Abstract commands that are part of the high-level
  API
• Low-level events that represent single key
  presses and releases (and pointer events, if a
  pointer is available)
• Calls to the paint() method of a Canvas class
• Calls to a Runnable objects run() method
  requested by a call to callSerially() of class
  Display
• All UI callbacks are serialized, so they will
  never occur in parallel.

10
Abstract Commands

• MIDP applications define Commands, and the
  implementation may manifest these via either
  abstract buttons, menus, or whatever mechanisms
  are appropriate for that device.
• Commands are installed to a Displayable (Canvas
  or Screen) with a method addCommand of class
  Displayable.
• The Command objects have three constructor
  parameters
• Label Shown to the user as a hint.
• CommandType The meaning of the command. One
  often used hint would be BACK which causes the
  application to go back to a previous state. Most
  phone designs have standard policy on which
  button is used for this operation. The
  commandType hint allows the implementation to
  take advantage of that policy.
• Priority Provided to the implementation for
  better mapping to device capabilities.

11
CommandListener

• The handling of events in the high-level API is
  based on a listener model. Screens and Canvases
  may have listeners for commands.
• An object willing to be a listener should
  implement an interface CommandListener that has
  one method
• void commandAction(Command c, Displayable d)
• There is also a listener interface for state
  changes of the Items in a Form.
• The method
• void itemStateChanged(Item item)
• defined in interface ItemStateListener is called
  when the value of an interactive Gauge,
  ChoiceGroup, or TextField changes.

12
Class Summary

• Interfaces
• Choice Choice defines an API for a user interface
  components implementing selection from predefined
  number of choices.
• CommandListener This interface is used by
  applications which need to receive high-level
  events from the implementation.
• ItemStateListener This interface is used by
  applications which need to receive events that
  indicate changes in the internal state of the
  interactive items within a Form screen.
• Classes
• Alert An alert is a screen that shows data to the
  user and waits for a certain period of time
  before proceeding to the next screen.
• AlertType The AlertType provides an indication of
  the nature of alerts.
• Canvas The Canvas class is a base class for
  writing applications that need to handle
  low-level events and to issue graphics calls for
  drawing to the display.
• ChoiceGroup A ChoiceGroup is a group of
  selectable elements intended to be placed within
  a
• Form .
• Command The Command class is a construct that
  encapsulates the semantic information of an
  action.
• DateField A DateField is an editable component
  for presenting date and time (calendar)
  information that may be placed into a Form.

• Display Display 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 The Font class represents fonts and font
  metrics.
• Form A Form is a Screen that contains an
  arbitrary mixture of items images, read-only
  text fields, editable text fields, editable date
  fields, gauges, and choice groups.
• Gauge The Gauge class implements a bar graph
  display of a value intended for use in a form.
• Graphics Provides simple 2D geometric rendering
  capability.
• Image The Image class is used to hold graphical
  image data.
• ImageItem A class that provides layout control
  when Image objects are added to a Form or to an
  Alert .
• Item A superclass for components that can be
  added to a Form and Alert .
• List The List class is a Screen containing list
  of choices.
• Screen The common superclass of all high-level
  user interface classes.
• StringItem An item that can contain a string.
• TextBox The TextBox class is a Screen that allows
  the user to enter and edit text.
• TextField A TextField is an editable text
  component that may be placed into a Form .
• Ticker Implements a "ticker-tape," a piece of
  text that runs continuously across the display.