A title[2] string set with the setTitle method that is presented to the user in a standard place, for example, as a header text for the Displayable [2] In MIDP Specification version 2.0,
Trang 1[ A ] [ B ] [ C ] [ D ] [ E ] [ F ] [ G ] [ H ] [ I ] [ J ] [K] [ L ] [ M ] [ N ] [ O ] [ P ] [ R ] [ S ] [ T ] [ U ] [ V ] [ W ] [ X ]
Trang 2Like the book? Buy it!
Trang 3[A] [ B ] [ C ] [ D ] [ E ] [ F ] [ G ] [ H ] [ I ] [ J ] [ K ] [ L ] [ M ] [ N ] [ O ] [ P ] [ R ] [ S ] [ T ] [ U ] [ V ] [ W ] [ X ]
Trang 4[ A ] [B] [ C ] [ D ] [ E ] [ F ] [ G ] [ H ] [ I ] [ J ] [ K ] [ L ] [ M ] [ N ] [ O ] [ P ] [ R ] [ S ] [ T ] [ U ] [ V ] [ W ] [ X ]
Trang 5[ A ] [ B ] [C] [ D ] [ E ] [ F ] [ G ] [ H ] [ I ] [ J ] [ K ] [ L ] [ M ] [ N ] [ O ] [ P ] [ R ] [ S ] [ T ] [ U ] [ V ] [ W ] [ X ]
CANCEL 2nd
Canvas 2nd [See also canvas]3rd [See also canvas]4th [See also canvas]
adaptation to device user interface style
class:Canvas: [See also Canvas]2nd [See also Canvas]3rd [See also Canvas] canvas
Trang 8[ A ] [ B ] [ C ] [D] [ E ] [ F ] [ G ] [ H ] [ I ] [ J ] [ K ] [ L ] [ M ] [ N ] [ O ] [ P ] [ R ] [ S ] [ T ] [ U ] [ V ] [ W ] [ X ]
Trang 9[ A ] [ B ] [ C ] [ D ] [E] [ F ] [ G ] [ H ] [ I ] [ J ] [ K ] [ L ] [ M ] [ N ] [ O ] [ P ] [ R ] [ S ] [ T ] [ U ] [ V ] [ W ] [ X ]
Trang 10[ A ] [ B ] [ C ] [ D ] [ E ] [F] [ G ] [ H ] [ I ] [ J ] [ K ] [ L ] [ M ] [ N ] [ O ] [ P ] [ R ] [ S ] [ T ] [ U ] [ V ] [ W ] [ X ]
Trang 11[ A ] [ B ] [ C ] [ D ] [ E ] [ F ] [G] [ H ] [ I ] [ J ] [ K ] [ L ] [ M ] [ N ] [ O ] [ P ] [ R ] [ S ] [ T ] [ U ] [ V ] [ W ] [ X ]
drawing
gray levels
[ Team LiB ]
Trang 12[ A ] [ B ] [ C ] [ D ] [ E ] [ F ] [ G ] [H] [ I ] [ J ] [ K ] [ L ] [ M ] [ N ] [ O ] [ P ] [ R ] [ S ] [ T ] [ U ] [ V ] [ W ] [ X ]
Trang 13[ A ] [ B ] [ C ] [ D ] [ E ] [ F ] [ G ] [ H ] [I] [ J ] [ K ] [ L ] [ M ] [ N ] [ O ] [ P ] [ R ] [ S ] [ T ] [ U ] [ V ] [ W ] [ X ]
Trang 14ITEM 2nd 3rd
Item Commands Item layout
ItemCommandListener ItemStateListener ITU-T keypad
[ Team LiB ]
Trang 15[ A ] [ B ] [ C ] [ D ] [ E ] [ F ] [ G ] [ H ] [ I ] [J] [ K ] [ L ] [ M ] [ N ] [ O ] [ P ] [ R ] [ S ] [ T ] [ U ] [ V ] [ W ] [ X ]
Trang 16[ A ] [ B ] [ C ] [ D ] [ E ] [ F ] [ G ] [ H ] [ I ] [ J ] [ K ] [L] [ M ] [ N ] [ O ] [ P ] [ R ] [ S ] [ T ] [ U ] [ V ] [ W ] [ X ]
Trang 17[ A ] [ B ] [ C ] [ D ] [ E ] [ F ] [ G ] [ H ] [ I ] [ J ] [ K ] [ L ] [M] [ N ] [ O ] [ P ] [ R ] [ S ] [ T ] [ U ] [ V ] [ W ] [ X ]
Trang 19[ A ] [ B ] [ C ] [ D ] [ E ] [ F ] [ G ] [ H ] [ I ] [ J ] [ K ] [ L ] [ M ] [N] [ O ] [ P ] [ R ] [ S ] [ T ] [ U ] [ V ] [ W ] [ X ]
Trang 20[ A ] [ B ] [ C ] [ D ] [ E ] [ F ] [ G ] [ H ] [ I ] [ J ] [ K ] [ L ] [ M ] [ N ] [O] [ P ] [ R ] [ S ] [ T ] [ U ] [ V ] [ W ] [ X ]
Trang 21[ A ] [ B ] [ C ] [ D ] [ E ] [ F ] [ G ] [ H ] [ I ] [ J ] [ K ] [ L ] [ M ] [ N ] [ O ] [P] [ R ] [ S ] [ T ] [ U ] [ V ] [ W ] [ X ]
Trang 23[ A ] [ B ] [ C ] [ D ] [ E ] [ F ] [ G ] [ H ] [ I ] [ J ] [ K ] [ L ] [ M ] [ N ] [ O ] [ P ] [R] [ S ] [ T ] [ U ] [ V ] [ W ] [ X ]
Trang 24[ A ] [ B ] [ C ] [ D ] [ E ] [ F ] [ G ] [ H ] [ I ] [ J ] [ K ] [ L ] [ M ] [ N ] [ O ] [ P ] [ R ] [S] [ T ] [ U ] [ V ] [ W ] [ X ]
Trang 25stack maps
standardization CLDC
J2ME 2nd MIDP
STOP 2nd
StringItem 2nd class:StringItem synchronization
UI
System Screens system software MIDP
system sounds [ Team LiB ]
Trang 26[ A ] [ B ] [ C ] [ D ] [ E ] [ F ] [ G ] [ H ] [ I ] [ J ] [ K ] [ L ] [ M ] [ N ] [ O ] [ P ] [ R ] [ S ] [T] [ U ] [ V ] [ W ] [ X ]
Trang 27[ A ] [ B ] [ C ] [ D ] [ E ] [ F ] [ G ] [ H ] [ I ] [ J ] [ K ] [ L ] [ M ] [ N ] [ O ] [ P ] [ R ] [ S ] [ T ] [U] [ V ] [ W ] [ X ]
Trang 28[ A ] [ B ] [ C ] [ D ] [ E ] [ F ] [ G ] [ H ] [ I ] [ J ] [ K ] [ L ] [ M ] [ N ] [ O ] [ P ] [ R ] [ S ] [ T ] [ U ] [V] [ W ] [ X ]
Trang 29[ A ] [ B ] [ C ] [ D ] [ E ] [ F ] [ G ] [ H ] [ I ] [ J ] [ K ] [ L ] [ M ] [ N ] [ O ] [ P ] [ R ] [ S ] [ T ] [ U ] [ V ] [W] [ X ]
Trang 30[ A ] [ B ] [ C ] [ D ] [ E ] [ F ] [ G ] [ H ] [ I ] [ J ] [ K ] [ L ] [ M ] [ N ] [ O ] [ P ] [ R ] [ S ] [ T ] [ U ] [ V ] [ W ] [X]
Trang 31The Java programming language was initially targeted towardsconsumer devices, especially the interactive TV market
However, over time the Java platform evolved more and moretowards the needs of desktop and enterprise computing
Enterprise applications generally require rich library
functionality, and over time the Java libraries grew larger andmore comprehensive to cater better to the needs of the
enterprise market and large server-side applications However,this evolution made the libraries too large and unsuitable forthe majority of small, resource-constrained devices
In January 1998, the Spotless project was started at Sun
Microsystems Laboratories (Sun Labs) to investigate the use ofthe Java programming language in extremely resource-
constrained devices The research goal of the project was tobuild a Java runtime environment that would fit in less than
one-tenth of the typical size At the implementation level, thegoal was to build a Java virtual machine with the following
memory available for applications Portability, ease of use, andthe readability of the source code are equally important Mostembedded device manufacturers need to support dozens or
Trang 32devices
Even though the Spotless effort was initially a research project,the project group established active contacts with external
customers early on External customers, especially Motorola,played a significant role in convincing Sun to turn the Spotlesssystem from a research project into a commercial product Theproduct version of the Spotless virtual machine is known today
as the K Virtual Machine (KVM) The Spotless system is
documented in the Sun Labs technical report The Spotless
System: Implementing a Java System for the Palm Connected Organizer (Sun Labs Technical Report SMLI TR-99-73).
Trang 33Zero or more Commands for application specific user
operations on the Displayable
A CommandListener (set by the application with the method
setCommandListener[1]) that gets notified when the userselects any of the Commands
[1] Note that only a single CommandListener can be added because of the
unicast listener model is used in the lcdui API.
A title[2] string (set with the setTitle method) that
is presented to the user in a standard place, for example, as
a header text for the Displayable
[2] In MIDP Specification version 2.0, the title and Ticker properties were added to class Displayable, which means that they are also available in class Canvas.
In MIDP 1.0, these properties were only available in the Screen classes.
A Ticker object (set with the setTicker method) that
provides automatically scrolling text attached to the
Trang 34Displayable When user selects a command, the commandlistener of the Displayable is activated The listener typicallychanges the Displayable by calling the method setCurrent ofclass Display
Trang 35to request the application manager to kill such an erroneousapplication
An application can also implement Displayable changes in
Canvas as actions resulting from low-level events, such as keyevents In addition, nothing prevents an application from
automatically changing its Displayable, for example, using atimer or thread A possible scenario for such usage is when anapplication wants to continue its execution from a progress barview[3] after a long network transaction has finished Generallythese types of automatic displayable changes should be usedwith care
[3] This kind of a view could be implemented, e.g., using an Alert (MIDP 2.0 only) or
Form with a non-interactive Gauge item These user interface structures are discussed
later.
Displayable classes that form the high-level API are called
Screens The use of different Screens is described in Chapter
9, "MIDP High-Level User Interface Screen." The Canvas class
Trang 36A Ticker can be added to any instance of Displayable with themethod addTicker, and it can be removed with the method
setTicker(null) Applications should not use Ticker on Alert
screens because some devices present Alerts as pop-up
dialogs that may not have space for the Ticker The same
Ticker may be shared by several Displayable objects
Setting a Ticker often affects the size of the
area available for contents of Displayable For
sizeChanged method Also, the getHeight and
getWidth methods of class Canvas report
smaller sizes
In a typical usage scenario, an application uses the same
Ticker on all of its Displayables When the application
switches between two Displayables that have the same
Ticker, the desirable consequence is for the Ticker to be
displayed at the same location on the display and to continuescrolling its contents at the same position This gives the illusion
of the Ticker being attached to the display instead of
separately to each Displayable
Trang 37Displayable For example, a Ticker can be added to a List
and the Ticker can be running while the List is being
Trang 38The following sections provide an overview to the MIDP userinterface API (javax.microedition.lcdui) The remainder ofthis chapter and the following two chapters concentrate on thehigh-level parts of the API The low-level user interface APIfeatures are detailed in Chapter 11, "MIDP Low-Level User
Interface Libraries."
The separation of high-level and low-level API is often not veryclear-cut There are many classes that are used both in low-level and high-level APIs For example, classes Image and Font
are used both in high-level Screen components and low-levelgraphics drawing Also, in MIDP 2.0 the new CustomItem classmakes it possible to mix low-level graphics and high-level
components within a Form object
Display on which a single Displayable object is shown Theapplication sets and resets the current Displayable object onthe Display for each step of the task, based on user
interactions The user tasks (interactions with the user
Trang 39application is notified automatically when a Command is selected
by the user As a result of these notifications the applicationoften changes the current Displayable to some other
Displayable The device software manages the sharing of thephysical display between the native applications and the MIDPapplications
The rationale behind the displayable-oriented approach is based
on the wide variations in display and keypad configurations
found in MIDP devices Each device provides a consistent lookand feel by handling the component layout, painting, scrolling,and focus traversal If an application needed to be aware ofthese details, portability would be difficult to achieve, and
smooth integration with the look and feel of the device and itsnative applications would place a heavy burden on applicationdevelopers
There is a hierarchy of Displayable subclasses called Screens
in the lcdui API Each Screen is a functional user interfaceelement that encapsulates device-specific graphics renderingand user input handling Figure 8.1 shows the hierarchy of theuser interface classes
Figure 8.1 MIDP user interface class hierarchy
(all classes not shown)
Trang 40Canvas: low-level objects that allow the application to
provide the graphics and handle input
Screen: high-level objects that encapsulate complete userinterface components (classes Alert, List, TextBox, orForm)
Any application may use combinations of Screens and Canvases
to present an integrated user interface For instance, in a gameapplication, Lists and Forms can be used to select or configurethe options of a game, while Canvas (or GameCanvas) can beused for the interactive game components
The Command class is used for implementing the application
specific operations For example, the navigation between
different application Displayables is implemented using
Commands Details of Commands are described in Section 8.5,
Trang 418.2.2 Low-Level User Interface
The low-level user interface API for Canvas is designed for
applications that need precise placement and control of graphicelements as well as access to low-level input events Typicalexamples are a game board, a chart object, or a graph Usingthe low-level user interface API, an application can
control what is drawn on the display,
handle primitive events such as key presses and releases,and
access concrete keys and other input devices
Applications that are programmed with the low-level API can beportable if the application uses only the standard features;
applications should stick to the platform-independent part ofthe low-level API whenever possible This means that the
Painting using the CustomItem class is done
similarly to painting to Canvas via the Graphics
Trang 42The low-level API is described in detail in Chapter 11, "MIDPLow-Level User Interface Libraries," and in Chapter 12, "MIDPGame API."
8.2.3 High-Level User Interface
The high-level user interface API is designed for business
applications whose client components run on mobile informationdevices For these applications, portability across devices is
important To achieve such portability, the high-level user
interface API employs a high level of abstraction and providesvery little control over look and feel This allows devices to use
the native user interface look and feel for the high-level MIDP
user interface API components This means that when an
application is written with the high-level API, its look and feelautomatically uses the look and feel of the device in which theapplication is currently running For the end users this providesseamless user interaction: the MIDP application works the sameway as the other (native) applications on the device
The high-level user interface components described in this
section behave consistently with the in-built user interfaces andapplications of a device More specifically, when using the high-level API:
Drawing to the display is performed by the device's systemsoftware Applications do not define the visual appearance(such as shape, color, and so forth) of the components
Navigation, scrolling, and other primitive interactions withthe user interface components are performed by the device.The application is not aware of these interactions
Trang 43in Chapter 9, "MIDP High-Level User Interface Screen."
The class Form is defined for cases where a screen with a singlefunction is not sufficient Class Form is designed to contain asmall number of closely related user interface elements, or
Items For example, an application might have two TextFields,
or a TextField and a simple ChoiceGroup If all the Items of a
Form do not fit on the screen, the implementation might makethe Form scrollable, expand each Item automatically when theuser edits it, or use a "pop up" representation Each Form cancontain a combination of the following Item subclasses:
StringItem, used for static text display, or as a button orhyperlink
Trang 44TextField, used for textual input with constraints
DateField, used for display or input of time and date
values
Gauge, used as a progress indicator or as a numeric inputfrom a specific range
ChoiceGroup, used for single or multiple selections from aset of elements
CustomItem (MIDP 2.0), used to create applicationspecific items; drawing is done with low-level Graphics API
Spacer (MIDP 2.0), used to create empty spaces for layoutpurposes
Although the Form class allows the creation of arbitrary
combinations of components, developers should keep in mindthe limited display size and make Forms simple and functional
Chapter 10, "MIDP High-Level User Interface Form" discussesthe various Form classes in detail