WT pptameya

8/6/2019 WT pptameya

1/90

Introduction to J2ME:

Programming the Small Devices


2/90

2

Mobile Applications

Developing wireless applications using WAP

technologies is similar to developing web

pages with a markup language because it is

browser based.

Another approach to developing wireless

applications is to use the Mobile Information

Device Profile (MIDP).


3/90

3

Mobile Devices Constraints

Memory Restricted

Heap memory

Record Management System

Memory Fragmentation

Display & Colour

208x320 ,

176x208 with 128 colours


4/90

4

Mobile Device Constraints

Different Phone Interfaces & Different

Features


5/90

5

Programming for Mobiles

Languages Used

Java

C++

C# .NET

Python

Technologies Used

Java ME

BREW


6/90

6

Java for mobile devices (Java ME)

Java is served in 3 Editions

Java EE Enterprise Edition for Enterprise / ServerClass of Applications (formerly J2EE)

Java SE Standard Edition for desktop class ofApplications (formerly J2SE)

Java ME Micro Edition for small devices(formerly J2ME)

Each of the Edition is meant to manageavailable resources like Memory, CPU,Display power and UI suiting the application.


7/90

7

Java ME in the Java Space


8/90

8

Enter Java ME

Most mobile applications use the Java Micro

Edition (Java ME) platform, which was

developed for small devices like mobile

phones and set-top boxes.

Java ME uses scaled down subsets of Java

SE components, virtual machines and APIs.

It defines APIs that are specifically targeted

at consumer mobile and embedded devices.


9/90

9

Why not AWT?

The AWT is designed for desktop computers andnot optimized for small devices.

The AWT is designed to work with a pointingdevice such as a mouse; however many handheld

devices have only a keypad for user input. While the AWT has a rich feature set for managingwindows. The window and layout managers withinthe AWT are not required for handheld devices dueto paucity of resources.

AWT-based applications use event objects. Thelimited CPU and memory of handheld devicescannot handle this behavior.


10/90

10

Java ME elements

The Java ME technology is based on three

elements

a configurationprovides the most basic set of

libraries and virtual machine capabilities for a

broad range of devices,

a profile is a set of APIs that support a narrower

range of devices, andan optional package is a set of technology-

specific APIs.


11/90

11

Java ME

The micro edition consists of two so-calledconfigurations and two virtual machines.

The two configurations are

CDC (Connected Device Configuration) and

CLDC (Connected, Limited Device Configuration),

The two virtual machines are

JVM (Java Virtual Machine) and

KVM (K Virtual Machine).

CDC and JVM are aimed at desktops and higher-end mobile devices

CLDC and KVM are for limited and small devices.


12/90

12

Device Hardware

Layered Structure of Java ME

Java ME forms a layered structure

JVM KVM

CDC CLDC

Personal

Profile

MID

Profile

CLDC BasedCDC Based


13/90

13

What is a Configuration?

A configuration is a specification that describes avirtual machine and some set of APIs, targeted at aspecific class of devices.

A configuration, for example, might be designedfor devices that have less than 512 KB of memoryand an intermittent network connection.

The virtual machine is either a full Java VirtualMachine (as described in the specification) or somesubset of the full JVM. The set of APIs is

customarily a subset of the Java SE APIs. Identifies the low level features and low level

facilities to use the resources of the device

CDC and CDLC are configurations


14/90

14

CDC and CDLC

Connected Device Configuration (CDC) is fordevices with much greater memory, processingpower and network connectivity such as smartphones, set-top boxes, and embedded servers anddevices.

Connected Limited DeviceConfiguration(CLDC) is for devices with less memory andprocessing power than CDC-based devices.

MIDP is based on CDLC, and together they provide thestandard Java runtime environment and a rich set ofAPIs for most popular mobile devices


15/90

15

CLDC

CLDC is a specification and it is positioned on topof the KVM.

It specifies APIs for devices with less than 512 KBof RAM for the Java system and a limited and

intermittent network connection. The APIs on this level define the core of the J2ME

language, and are rarely used by programmers.

The specification of the KVM is included in the

CLDC. There are currently two versions of CLDC, version

1.0 and 1.1.


16/90

16

CLDC Characteristics

CLDC provides the lowest common denominatorfor small and resource-constrained devicescharacterized as follows:

160 kB to 512 kB of totally memory budget

available for the Java platform. a 16-bit or32-bit processor.

low power consumption, often operating withbattery power.

connectivity to some kind of network, often with awireless connection and with limited (often 9600bps or less) bandwidth.


17/90

17

CLDC Versions

CLDC 1.0 : does not support floating pointnumbers, operation and datatype/class. Allfloating point operation are done through 3rd

party class implementation, which cannot beaccurate for large numbers

CLDC 1.1 : supports floating point data typeout from the box, making floating point

operation much more faster and moreaccurate than using 3rd party floating pointnumber class implementation


18/90

18

What is a Profile?

A high level abstraction of all resources for a classof devices which can be used by an application.

A profilebuilds on a configuration but adds morespecific APIs to make a complete environment for

building applications. While a configuration describes a JVM and a basic set of

APIs, it does not by itself specify enough detail to enableyou to build complete applications.

Profiles usually include APIs for application lifecycle, user interface, and persistent storage.

MIDP is a profile for small footprint devices, likemobiles.


19/90

19

Optional Package

An optional packageprovides functionality

that may not be associated with a specific

configuration or profile.

One example of an optional package is the

Bluetooth API , which provides a

standardized API for using Bluetooth

networking. This optional package could beimplemented alongside virtually any

combination of configurations and profiles.


20/90

20

Configurations, Profiles, PackagesConfigurations

JSR30 CLDC 1.0 Connected, Limited DeviceConfiguration

JSR 139 CLDC 1.1 Connected, Limited DeviceConfiguration 1.1

JSR36 CDC Connected Device Configuration

JSR 218 CDC 1.1 Connected DeviceConfiguration 1.1

Profiles

JSR37 MIDP 1.0 Mobile Information DeviceProfile

JSR 118 MIDP 2.0 Mobile Information DeviceProfile 2.0

JSR 75 PDAP PDA Profile

JSR46 FP Foundation Profile

JSR 219 FP 1.1 Foundation Profile 1.1

JSR 129 PBP Personal Basis Profile

JSR 217 PBP 1.1 Personal Basis Profile 1.1

JSR 62 PP Personal Profile

JSR 215 PP 1.1 Personal Profile 1.1 JSR 195 IMP Information Module Profile

JSR 228 IMP-NG Information Module Profile -Next Generation

Optional Packages

JSR 75 PDAOptional Packages for the J2ME Platform JSR 82 Java APIs forBluetooth

JSR 120 Wireless Messaging API

JSR 205 Wireless Messaging API 2.0

JSR 135 Mobile Media API

JSR 164 JAIN SIMPLE Presence

JSR 165 JAIN SIMPLE Instant Messaging

JSR 172 J2ME Web Services

JSR 177 Security and Trust Services API for J2ME

JSR 179 Location API for J2ME JSR 180 SIPSIP API for J2ME

JSR 184 Mobile 3D Graphics API for J2ME

JSR 186 JAIN Presence

JSR 187 JAIN Instant Messaging

JSR 190 Event Tracking API for J2ME

JSR 209 Advanced Graphics and User Interface

JSR 211 Content Handling API

JSR 213 Micro WSCI Framework for J2ME

JSR 214

Micro BPSS for J2ME Devices JSR 226 Scalable 2D Vector Graphics API

JSR 229 Payment API

JSR 230 Data Sync API

JSR 232 Mobile Operational Management

JSR 234 Advanced Multimedia Supplements

JSR 238 Mobile Internationalization API

JSR 239 Java Bindings for OpenGL ES

JSR 246 Device Management API

JSR 253 Mobile Telephony API (MTA)


21/90

21

MIDP

The Mobile Information Device Profile (MIDP)adds APIs for application life cycle, user interface,networking, and persistent storage.

Developers using MIDP can write applicationsonce, then deploy them quickly to a wide variety ofmobile information devices.

MIDP has been widely adopted as the platform ofchoice for mobile applications.

It is deployed globally on millions of phones andPDAs, and is supported by leading integrateddevelopment environments (IDEs).


22/90

22

MIDP Characteristics

MIDP adds an additional layer on the top of

the CLDC providing APIs for a specific class

of devices:

128KB of non-volatile memory for the MIDP

implementation

32KB of volatile memory for the runtime heap

8KB of non-volatile memory for persistent data Input capacity (screen, keyboard, touch)

Screen size of at least 96x54 pixels


23/90

23

CLDC Wireless Platform

Combines CLDC with theMobile Information DeviceProfile (MIDP) to provide acomplete Java application

environment for mobilephones and other deviceswith similar capabilities.

With the configuration andprofiles, the actual

application then resides anduses the different availableAPIs in the profile


24/90

24

Development Toolkits

The Sun Java Wireless Toolkit providescomplete development support for developingMIDP applications, and works in combinationwith today's leading IDEs.

Sun ONE Studio, Mobile Edition is a Java-technology IDE for developing applications thatcan be deployed to Java technology-enabledmobile devices.

Java ME SDK 3.0 combines both the above..

Netbeans Mobility ( 5.0 with Mobility pack, or6.x which includes the mobility pack )


25/90

25

Sun Java Wireless Toolkit CDLC

The Sun Java Wireless Toolkit CLDC (formerlyknown as Java 2 Platform, Micro Edition (J2ME)Wireless Toolkit) is a toolbox for developingwireless applications that are based on Java ME

platform's Connected Limited Device Configuration(CLDC) and Mobile Information Device Profile(MIDP),

Designed to run on cell phones, mainstreampersonal digital assistants, and other small mobile

devices. Toolkit includes the emulation environments,

performance optimization and tuning features,documentation, and examples


26/90

26

MIDP Features- Rich UI capabilities

MIDP applications provide the foundation forhighly graphical and intuitive applications.

The GUI is optimized for the small display size,varied input methods, and other native features of

modern mobile devices. MIDP provides intuitive navigation and data entry

by taking full advantage of phone keypads, extrabuttons such as arrow keys, touch screens, andsmall QWERTY keyboards.

MIDP applications are installed and run locally, canoperate in both networked and unconnected modes,and can store and manage persistent local datasecurely.


27/90

27

MIDP Features-Extensive Connectivity

MIDP enables developers to exploit the native data

network and messaging capabilities of mobile

information devices.

It supports leading connectivity standards,includingHTTP, HTTPS, datagrams, sockets,

server sockets, and serial port.

MIDP also supports the Short Message Service

and Cell Broadcast Service capabilities of GSM

and CDMA networks, through the Wireless

Messaging API (WMA) optional package.


28/90

28

MIDP Features- Multimedia & Game

Functionality Support

MIDP is ideal for building portable games andmultimedia applications.

A low-level UI API complements the high-level UIAPI, giving developers greater control of graphics

and input. A game API adds game-specific functionality, such

as sprites and tiled layers, which take advantage ofdevices' native graphics capabilities.

Built-in audio provides support for tones, tonesequences, and WAV files.

In addition, developers can use the Mobile MediaAPI (MMAPI) optional package to add video andother rich multimedia content to MIDP applications.


29/90

29

Mobile Devices : A listBrand Model Profiles Configuration

BlackBerry 6710 MIDP-2.0 CLDC-1.1



LG B2000 MIDP-2.0 CLDC-1.0

LG B2100 MIDP-2.0 CLDC-1.0

LG C1300i MIDP-2.0 CLDC-1.1

LG CU515 MIDP-2.0 CLDC-1.1

LG G5500 MIDP-1.0 CLDC-1.0

LG KF310 MIDP-2.0 CLDC-1.1

Motorola C385 MIDP-2.0 CLDC-1.0

Motorola C550 MIDP-1.0 CLDC-1.0

Motorola E1 ROKR MIDP-2.0 CLDC-1.1

Motorola K3 MIDP-2.0 CLDC-1.1

Motorola MOTORAZRmaxxV3 MIDP-2.0 CLDC-1.1

Motorola MOTOROKR E6 MIDP-2.0 CLDC-1.1

Nokia 3100 MIDP-1.0 CLDC-1.0

Nokia 3110c MIDP-2.0 CLDC-1.1




Nokia E60-1 MIDP-2.0 CLDC-1.1


30/90

30

Mobile Devices List contd:

Brand Model Profiles Configuration

Nokia N-Gage MIDP-1.0 CLDC-1.0

Nokia N70 MIDP-2.0 CLDC-1.1

Nokia N91 MIDP-2.0 CLDC-1.1

Nokia N93-1 MIDP-2.0 CLDC-1.1

Panasonic X200 MIDP-1.0 CLDC-1.0



Sagem my300X MIDP-2.0 CLDC-1.1

Sagem my501X MIDP-2.0 CLDC-1.1

Samsung GT-S7330 MIDP-2.0 CLDC-1.1

Samsung SGH-A801 MIDP-2.0 CLDC-1.1

Samsung SGH-D510 MIDP-2.0 CLDC-1.1

Siemens AF51 MIDP-1.0 CLDC-1.0

Siemens C75 MIDP-2.0 CLDC-1.1

Siemens M81 MIDP-2.0 CLDC-1.1

SonyEricsson Z500i MIDP-2.0 CLDC-1.1

SonyEricsson W710i MIDP-2.0 CLDC-1.1


31/90

31

MIDlets

An application written for MIDP is called a MIDlet.

MIDlets are portable across compatible mobile

devices that support the same optional APIs that theMIDlet itself uses.

MIDlets are designed to support a particular MIDP

version and are guaranteed to work properly with

mobile devices that support that version


32/90

32

MIDlets

A MIDlet suite consists of a Java Application

Descriptor file (.jad) and a Java Archive file

(.jar).

The JAD file includes the archive file name,

the names and classes for each MIDlet in the

suite, and more.

The JAR file contains the MIDlet classes andresource files.


33/90

33

MIDlets

In order to be classified as a MIDlet, a mobile Java

application must:

extend the MIDP-defined abstract class

javax.microedition.midlet.MIDlet, which controls theMIDlet lifecycle

be packaged and distributed in a Java Archive ( JAR) file.

include a MANIFEST.MF file contained within the .jar file.

include a Java Application Descriptor ( JAD ) file. have all .class files preverified before deployment. In

current Java ME tools, the preverification is done

automatically during the build process.


34/90


35/90

35

Toolkits

Sun Java Wireless Toolkit ( WTK )

Netbeans

Nokia SDK Samsung SDK

Motorola SDK


36/90

36

Java Development Environments

Java SE, JDK latest version

Java Wireless Toolkit ( WTK )

IDE, Eclipse with java Mobile plugin ( Eclipse ME )or Netbeans with Java Mobility pack

SDK supporting Java ME and MIDP SDKs for S60 and Series 40 Nokia mobile can be

downloaded from nokia site ( www.forum.nokia.com )

Supporting emulators for the devices

A mobile device and a means to connect it to your PCfor MIDlet testing purposes

Nokia PC Suite to enable the transfer to the physicalphone


37/90

Hands on WTK for Mobile Apps


38/90

38

The Development Cycle

Standard Development Cycle


39/90


40/90

40

Step 2

Installing Sun Java Wireless Toolkit

set of tools that make it easy to build and test

MIDP applications

a miniature IDE; it automates several of the tasksrelated to building MIDP applications

The files for the toolkit will go into c:\WTK23

unless you specify a different directory

Does not have an editor !!!


41/90

41

Step 3

Run the toolkit

Select the KToolbar shortcut


42/90

42

Step 3 contd

The Sun Java Wireless Toolkit works with

projects, where the end result of each project

is one MIDlet suite.

The toolkit works with one project at a time.

You can change properties of the current

project, build the project, and run the project

in a device emulator


43/90

43

Step 4

Create a new project

Click on New Project in the button bar.

The toolkit prompts you for a project name and

the name of a MIDlet class in the project. Fill inHelloSuite and HelloMIDlet as shown below.


44/90


45/90

45

Step 4 contd

Create a new project ( contd )

The toolkit stores each project in a

subdirectory of the apps directory .

name of the subdirectory is thesame as the name of the project

Each project subdirectory has a

standard structure:

The bin directory contains the

compiled MIDlet suite (a .jar file) and

the MIDlet suite descriptor (a .jad file).


46/90


47/90

47

Step 6

Build the project

Click on the Build button in KToolbar

Additional directories (classes, tmpclasses, and

tmplib ) are created as follows


48/90

48

Step 7

Run the MIDlet on the

emulator

Click on the RUN button.

You should see a mobilephone emulator pop up.

The emulator is showing a list

of MIDlets in the MIDlet

suite ( presently only one )


49/90

49

Step 8

Run in Emulator

click on the LAUNCH

soft button to start up

the MIDlet. It will display a simple

screen with the

response


50/90

50

Step 9

Exit

Click on EXIT to leave the MIDlet.

Close the emulator window or hit the Escape key

to end the emulator session.


51/90

51

Step 10

Other Emulators

The emulator you've just used is the Default

Color Phone.

The Sun Java Wireless Toolkit has otheremulators as well. Try running HelloMIDlet on

some other devices to see how the user interface

adapts. Simply select the emulator you'd like in

the combo box in KToolbar, then click on RUNagain.


52/90

52

Nokia SDK

Third party SDKs also can be used


53/90

MIDlet Life cycle


54/90


55/90

55

AMS

When a mobile device user selects a MIDletfor execution, the AMS instantiates it bycalling the MIDlet's startApp method, which

starts the lifecycle of the MIDlet. The AMS maintains control over the MIDlet

lifecycle throughout its execution. There areno explicit restrictions to the number of

MIDlets that can run simultaneously, theAMS can release resources by terminatinginactive MIDlets or pausing active ones.


56/90

56

AMS

The AMS controls what is shown on the device

display using the concepts of foreground and

background.

Only one application is active at a time, and it is inthe foreground, with all the other running

applications relegated to background.

The AMS can send a MIDlet to the background or

bring it to the foreground either as a response touser initiated actions, actions initiated by other

applications, or other events ( like a phone call )


57/90

57

FG BG Switching

In a foreground MIDlet, calls

Display.setCurrent(null) to send the MIDlet to the

background. The next application getting the

foreground is determined by the platform. To activate a background MIDlet and set it to the

foreground, call Display.setCurrent(Displayable).

This causes view activation in the native operating

system, which results in the MIDlet being broughtto the foreground.


58/90


59/90

59

MIDLet Life cycle


60/90

60

MIDlet Structure

An application written for MIDP is called a MIDlet.

All MIDlets extend the MIDlet class:

public class MyMIDlet extends MIDlet { }

The MIDlet class provides methods for starting,

pausing, and terminating the MIDlet application:

startApp()

pauseApp()

destroyApp(boolean unconditional)


61/90

61

MIDlet Structure

Every MIDlet must have three methods:

startApp method is called when the MIDlet is

started. After startApp, the MIDlet is in Active

state and the AMS allows it to hold resources. Ifa runtime exception occurs during startApp, the

MIDlet will be destroyed immediately.


62/90

62

MIDlet Structure


pauseApp method is used to indicate actions

when the app is to be set to the paused state. By

default, pauseApp() isn't called but it can be setto be called with specific functions to handle

flipclose() type of operations

Even if pauseApp() is not called, it still needs to

be included as a null method


63/90

63

MIDlet Structure


destroyApp signals the MIDlet to terminate and places it

in Destroyedstate. During termination, all the MIDlet's

resources are released and objects deleted.

The MIDlet has five seconds to handle the destroyApp

call, after which the AMS closes the application itself.

A MIDlet can be closed in several different scenarios

an End key press

by AMS

memory card removal

out-of-memory situation


64/90

64

Complete MIDlet Example

import javax.microedition.midlet.*;

import javax.microedition.lcdui.*;

public class HelloMIDlet extends MIDlet {

public void startApp() {

TextBox textBox = new TextBox(My MIDlet", "Hello world:=)",15,0);

Display.getDisplay(this).setCurrent(textBox);

}

public void pauseApp() { }public void destroyApp(boolean unconditional) { }

}


65/90

MIDP API Programming


66/90

66

MIDP UI

The central abstraction of the MIDP UI is a

screen, which is an object that encapsulates

device-specific graphics rendering user input.

Only one screen can be visible at a time, andthe user can traverse only through the items

on that screen.

3 types of screens


67/90

67

MIDP UI There are three types of screens:

Screens that encapsulate a complex user interfacecomponent that involves a List or TextBox component.The structure of these screens is predefined, and theapplication 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 relatedUI components to the form.

Screens used within the context of the low-level API, suchas a subclass of the Canvas class.

The Display class is the display manager that provides

methods to retrieve information about the device'sdisplay capabilities.

A screen is made visible by calling theDisplay.setCurrent() method.


68/90

68

MIDP GUI objects

Organised as High Level API & Low Level API

Objects

The high-level API is designed for applications

whose client parts run on mobile informationdevices where portability is important.

Low Level API provides little abstraction. It is

designed for applications that need precise

placement and control of graphic elements andaccess to low-level input events .


69/90

69

High Level API

To achieve portability, the API employs a high-

level abstraction and gives you little control over its

look and feel.

Interaction with components is encapsulated by theimplementation

When you use the high-level API, the underlying

implementation does the necessary adaptation to the

device's hardware and native user interface style.

The high-level API is implemented by classes that

inherit from the Screen class.


70/90


71/90


72/90


73/90

73

Low-Level MIDP GUI

Canvas

Raw input event

Command

CommandListener

http://developers.sun.com/tec

htopics/mobility/midp/articles/ui/


74/90

74

Low-Level MIDP GUI

http://developers.sun.com/techtopics/mobility/midp/articles/ui/


75/90

75

lcdui package

All MIDP GUI classes are in the lcdui

package. To use the GUI classes, your

MIDlets have to import this package as

follows:import javax.microedition.lcdui.*;

The lcdui package contains three interfaces

(Choice, CommandListener,ItemStateListener ) and twenty one classes


76/90

76

lcdui

Class diagram for lcdui class


77/90


78/90

78

RMS

Several applications need to storesome data in a permanent way (evenwhen the device is switched off)

This kind of data is called persistent

data and they are stored in adedicated memory part calledpersistent storage

MIDP defines a set of classes for

storing and retrieving persistent datacalledRecord Management System(RMS).


79/90

79

RMS

The basic storage

mechanism used by the

RMS is a Record

Store implemented as

a simple record-

oriented database

A Record Store can be

shared among differentMIDlets (only MIDP

2.0)


80/90

80

RMS

The MIDP RMS implementation ensures that all

individual record store operations are atomic,

synchronous, and serialized, so no corruption

occurs with multiple access. However, if your

MIDlets use multiple threads to access a record

store, we need to synchronize this access, or some

of the records might be overwritten.

When a MIDlet suite is removed from the devicethen all the record stores associated with it will also

be removed


81/90

81

RMS

To use the RMS, import the javax.microedition.rmspackage

Record stores (binary files) are platform-dependentbecause they are created in platform-dependentlocations.

MIDlets within a single application (a MIDlet suite)can create multiple record stores (database files)with different names.

The RMS APIs provide the following functionality:

Allow MIDlets to manipulate (add and remove) recordswithin a record store.

Allow MIDlets in the same application to share records(access one another's record store directly).

Do not provide a mechanism for sharing records between

MIDlets in different applications.


82/90

82

Deploy your MIDlet

Once the MIDlet has been run on an emulator, the

next step is to run it on the target device. There are

a number of ways to deploy a MIDlet to a device.

Over-the-Air (OTA),

Infrared,

installation over a serial cable,

Bluetooth,

e-mail, and MMS.


83/90

83

Serial Cable

If the device has a serial cable port and

connectivity software for a PC, the MIDlet

can be installed on the device over a serial

cable ( USB ). How the received MIDlet is handled when it

reaches the device will be device specific.

Nokia PC Suite handles it as a simpleapplication


84/90

84

IR / Bluetooth Deployment

IR or Bluetooth technology can be used to send the

MIDlet from a PC to another device.

These methods of deployment are dependent upon

having access to an IR pod or Bluetooth connectionsuport.

How the device handles the sent MIDlet will be

device specific. For example, the MIDlet may go

into the Messaging Inbox, the AMS may beautomatically or manually activated and handle the

MIDlet, etc.


85/90

85

E-mail and MMS

A JAR file could be included as an

attachment to an e-mail or within an MMS.

When the e-mail/MMS is opened, the AMS

will automatically be activated and providean option to install the sent MIDlet.

Trusted Source ????


86/90

86

Designing the user interfaces

Although it maintains a constrained profile, the

MIDP API provides a complete set of UI

elements. The following are some of the

most important ones: An Alert acts as a screen to provide

information to the user about an exceptional

condition or error. A Choice implements a selection from a

predefined number of choices.


87/90

87

A ChoiceGroupprovides a group of related

choices.

A Form acts as a container for the other UI

elements.

A Listprovides a list of choices.

A StringItem acts as a display-only string.

A TextBox is a screen that allows the user to

enter and edit text.


88/90

88

A TextField allows the user to enter and edit

text. Multiple TextFields can be placed in

a Form.

A DateField is an editable component for

presenting date and time information.A DateField can be placed in a Form.

A Tickeracts as a scrollable display of text.

Q & A


89/90

89

Q & A

Time for a few Questions

If none, . . . .

THANKS


90/90

THANKS

The greatest difficulty in the world is

not for people to accept new ideas but

to make them forget about their old

ideas.

- John Maynard Keynes

Documents

WT pptameya