1. Trang chủ
  2. » Công Nghệ Thông Tin

Addison wesley programming wireless devices with the java 2 platform micro edition 2nd edition jun 2003 ISBN 0321197984

491 83 0

Đang tải... (xem toàn văn)

Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống

THÔNG TIN TÀI LIỆU

Thông tin cơ bản

Định dạng
Số trang 491
Dung lượng 4,2 MB

Các công cụ chuyển đổi và chỉnh sửa cho tài liệu này

Nội dung

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 2

Like 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 14

ITEM 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 25

stack 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 31

The 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 32

devices

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 33

Zero 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 34

Displayable 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 35

to 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 36

A 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 37

Displayable For example, a Ticker can be added to a List

and the Ticker can be running while the List is being

Trang 38

The 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 39

application 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 40

Canvas: 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 41

8.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 42

The 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 43

in 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 44

TextField, 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

Ngày đăng: 26/03/2019, 17:07

w