Introduction to J2ME: Programming the Small Devices

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).

Mobile Devices Constraints

Memory Restricted
Heap memory Record Management System

Memory Fragmentation Display & Colour

208x320 , 176x208 with 128 colours

Mobile Device Constraints

Different Phone Interfaces & Different Features

Programming for Mobiles

Languages Used
Java C++ C# .NET Python

Technologies Used
Java ME BREW
5

Java for mobile devices (Java ME)

Java is served in 3 Editions
Java EE Enterprise Edition for Enterprise / Server Class of Applications (formerly J2EE) Java SE Standard Edition for desktop class of Applications (formerly J2SE) Java ME Micro Edition for small devices (formerly J2ME)

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

Java ME in the Java Space

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

Why not AWT?

The AWT is designed for desktop computers and not optimized for small devices. The AWT is designed to work with a pointing device such as a mouse; however many handheld devices have only a keypad for user input. While the AWT has a rich feature set for managing windows. The window and layout managers within the AWT are not required for handheld devices due to paucity of resources. AWT-based applications use event objects. The limited CPU and memory of handheld devices cannot handle this behavior.
9

Java ME elements
The Java ME technology is based on three elements
a configuration provides 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, and an optional package is a set of technologyspecific APIs.
10

Java ME
The micro edition consists of two so-called configurations 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 higherend mobile devices CLDC and KVM are for limited and small devices.
11

Layered Structure of Java ME

Java ME forms a layered structure

CDC Based Personal Profile CDC JVM

CLDC Based MID Profile CLDC KVM 12

Device Hardware

What is a Configuration?
A configuration is a specification that describes a virtual machine and some set of APIs, targeted at a specific class of devices. A configuration, for example, might be designed for devices that have less than 512 KB of memory and an intermittent network connection. The virtual machine is either a full Java Virtual Machine (as described in the specification) or some subset 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
13

CDC and CDLC

Connected Device Configuration (CDC) is for devices with much greater memory, processing power and network connectivity such as smart phones, set-top boxes, and embedded servers and devices. Connected Limited Device Configuration (CLDC) is for devices with less memory and processing power than CDC-based devices.
MIDP is based on CDLC, and together they provide the standard Java runtime environment and a rich set of APIs for most popular mobile devices 14

CLDC
CLDC is a specification and it is positioned on top of the KVM. It specifies APIs for devices with less than 512 KB of 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.
15

CLDC Characteristics
CLDC provides the lowest common denominator for small and resource-constrained devices characterized as follows: 160 kB to 512 kB of totally memory budget available for the Java platform. a 16-bit or 32-bit processor. low power consumption, often operating with battery power. connectivity to some kind of network, often with a wireless connection and with limited (often 9600 bps or less) bandwidth.
16

CLDC Versions
CLDC 1.0 : does not support floating point numbers, operation and datatype/class. All floating point operation are done through 3rd party class implementation, which cannot be accurate for large numbers CLDC 1.1 : supports floating point data type out from the box, making floating point operation much more faster and more accurate than using 3rd party floating point number class implementation
17

What is a Profile?
A high level abstraction of all resources for a class of devices which can be used by an application. A profile builds on a configuration but adds more specific 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 enable you to build complete applications.

Profiles usually include APIs for application life cycle, user interface, and persistent storage. MIDP is a profile for small footprint devices, like mobiles.
18

Optional Package
An optional package provides 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 be implemented alongside virtually any combination of configurations and profiles.
19

Configurations, Profiles, Packages

Configurations JSR 30 CLDC 1.0 Connected, Limited Device Configuration JSR 139 CLDC 1.1 Connected, Limited Device Configuration 1.1 JSR 36 CDC Connected Device Configuration JSR 218 CDC 1.1 Connected Device Configuration 1.1 Profiles JSR 37 MIDP 1.0 Mobile Information Device Profile JSR 118 MIDP 2.0 Mobile Information Device Profile 2.0 JSR 75 PDAP PDA Profile JSR 46 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 PDA Optional Packages for the J2ME Platform JSR 82 Java APIs for Bluetooth 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)

20

MIDP
The Mobile Information Device Profile (MIDP) adds APIs for application life cycle, user interface, networking, and persistent storage. Developers using MIDP can write applications once, then deploy them quickly to a wide variety of mobile information devices. MIDP has been widely adopted as the platform of choice for mobile applications. It is deployed globally on millions of phones and PDAs, and is supported by leading integrated development environments (IDEs).
21

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
22

CLDC Wireless Platform

Combines CLDC with the Mobile Information Device Profile (MIDP) to provide a complete Java application environment for mobile phones and other devices with similar capabilities. With the configuration and profiles, the actual application then resides and uses the different available APIs in the profile

23

Development Toolkits
The Sun Java Wireless Toolkit provides complete development support for developing MIDP applications, and works in combination with today's leading IDEs. Sun ONE Studio, Mobile Edition is a Javatechnology IDE for developing applications that can be deployed to Java technology-enabled mobile devices. Java ME SDK 3.0 combines both the above.. Netbeans Mobility ( 5.0 with Mobility pack, or 6.x which includes the mobility pack )
24

Sun Java Wireless Toolkit CDLC

The Sun Java Wireless Toolkit CLDC (formerly known as Java 2 Platform, Micro Edition (J2ME) Wireless Toolkit) is a toolbox for developing wireless 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, mainstream personal digital assistants, and other small mobile devices. Toolkit includes the emulation environments, performance optimization and tuning features, documentation, and examples
25

MIDP Features- Rich UI capabilities

MIDP applications provide the foundation for highly 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, extra buttons such as arrow keys, touch screens, and small QWERTY keyboards. MIDP applications are installed and run locally, can operate in both networked and unconnected modes, and can store and manage persistent local data securely.
26

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, including HTTP, 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.
27

MIDP Features- Multimedia & Game Functionality Support

MIDP is ideal for building portable games and multimedia applications. A low-level UI API complements the high-level UI API, giving developers greater control of graphics and input. A game API adds game-specific functionality, such as sprites and tiled layers, which take advantage of devices' native graphics capabilities. Built-in audio provides support for tones, tone sequences, and WAV files. In addition, developers can use the Mobile Media API (MMAPI) optional package to add video and other rich multimedia content to MIDP applications.
28

Mobile Devices : A list

Brand
BlackBerry BlackBerry BlackBerry LG LG LG LG LG LG Motorola Motorola Motorola Motorola Motorola Motorola Nokia Nokia Nokia Nokia Nokia Nokia 6710 8100 9100 B2000 B2100 C1300i CU515 G5500 KF310 C385 C550 E1 ROKR K3 MOTORAZRmaxxV3 MOTOROKR E6 3100 3110c 3200 5300 7210 E60-1

Model
MIDP-2.0 MIDP-2.0 MIDP-2.0 MIDP-2.0 MIDP-2.0 MIDP-2.0 MIDP-2.0 MIDP-1.0 MIDP-2.0 MIDP-2.0 MIDP-1.0 MIDP-2.0 MIDP-2.0 MIDP-2.0 MIDP-2.0 MIDP-1.0 MIDP-2.0 MIDP-1.0 MIDP-2.0 MIDP-1.0 MIDP-2.0

Profiles

Configuration
CLDC-1.1 CLDC-1.1 CLDC-1.1 CLDC-1.0 CLDC-1.0 CLDC-1.1 CLDC-1.1 CLDC-1.0 CLDC-1.1 CLDC-1.0 CLDC-1.0 CLDC-1.1 CLDC-1.1 CLDC-1.1 CLDC-1.1 CLDC-1.0 CLDC-1.1 CLDC-1.0 CLDC-1.1 CLDC-1.0 CLDC-1.1

29

Mobile Devices List contd:

Brand
Nokia Nokia Nokia Nokia Panasonic Panasonic Panasonic Sagem Sagem Samsung Samsung Samsung Siemens Siemens Siemens SonyEricsson SonyEricsson N-Gage N70 N91 N93-1 X200 X60 X500 my300X my501X GT-S7330 SGH-A801 SGH-D510 AF51 C75 M81 Z500i W710i

Model
MIDP-1.0 MIDP-2.0 MIDP-2.0 MIDP-2.0 MIDP-1.0 MIDP-1.0 MIDP-2.0 MIDP-2.0 MIDP-2.0 MIDP-2.0 MIDP-2.0 MIDP-2.0 MIDP-1.0 MIDP-2.0 MIDP-2.0 MIDP-2.0 MIDP-2.0

Profiles

Configuration
CLDC-1.0 CLDC-1.1 CLDC-1.1 CLDC-1.1 CLDC-1.0 CLDC-1.0 CLDC-1.0 CLDC-1.1 CLDC-1.1 CLDC-1.1 CLDC-1.1 CLDC-1.1 CLDC-1.0 CLDC-1.1 CLDC-1.1 CLDC-1.1 CLDC-1.1

30

MIDlets
An application written for MIDP is called a MIDlet. MIDlets are portable across compatible mobile devices that support the same optional APIs that the MIDlet itself uses. MIDlets are designed to support a particular MIDP version and are guaranteed to work properly with mobile devices that support that version

31

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 and resource files.
32

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 the MIDlet 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. 33

MIDlet Suites
One or more MIDlets are packaged in a single jar file and distributed as MIDlet suites. They have greater ability to share external resources than separate MIDlets. All of the MIDlets in a suite are installed onto a device as a single entity. At runtime, if the device supports concurrent running of more than one MIDlet, all active MIDlets from a MIDlet suite run in the same Java VM.
34

Toolkits
Sun Java Wireless Toolkit ( WTK ) Netbeans Nokia SDK Samsung SDK Motorola SDK

35

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 PC for MIDlet testing purposes Nokia PC Suite to enable the transfer to the physical phone
36

Hands on WTK for Mobile Apps

The Development Cycle

Standard Development Cycle

38

Step 1
Install Java SE ( JDK )
J2SE 5.0 ( or later ) to form the foundation of your development environment provides the Java platform upon which the Sun Java Wireless Toolkit runs. it includes a Java compiler and other tools that the toolkit uses to build your projects.

Install latest Java Runtime ( JRE )

39

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 tasks related 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 !!!

40

Step 3
Run the toolkit
Select the KToolbar shortcut

41

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

42

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 in HelloSuite and HelloMIDlet as shown below.

43

Step 4 contd
Create a new project ( contd )
click on Create Project and press OK to finish creating the new project .
Creating project "HelloSuite" Place Java source files in "C:\WTK23\apps\HelloSuite\src" Place Application resource files in "C:\WTK23\apps\HelloSuite\res" Place Application library files in "C:\WTK23\apps\HelloSuite\lib"

44

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 the same 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).

45

Step 5
Write code for a small MIDlet Save code as HelloMIDlet.java in the src directory of your project

46

Step 6
Build the project
Click on the Build button in KToolbar Additional directories (classes, tmpclasses, and tmplib ) are created as follows

47

Step 7
Run the MIDlet on the emulator
Click on the RUN button. You should see a mobile phone emulator pop up. The emulator is showing a list of MIDlets in the MIDlet suite ( presently only one )

48

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

49

Step 9
Exit
Click on EXIT to leave the MIDlet. Close the emulator window or hit the Escape key to end the emulator session.

50

Step 10
Other Emulators
The emulator you've just used is the Default Color Phone. The Sun Java Wireless Toolkit has other emulators 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 RUN again.
51

Nokia SDK
Third party SDKs also can be used

52

MIDlet Life cycle

Application Management Software

The Application Management Software (AMS) manages the MIDlets. The core of the MIDlet lifecycle is the AMS, which provides the context for all MIDlet activities The AMS is a part of the device's operating environment and manages MIDlets states during the execution process.
54

AMS
When a mobile device user selects a MIDlet for execution, the AMS instantiates it by calling the MIDlet's startApp method, which starts the lifecycle of the MIDlet. The AMS maintains control over the MIDlet lifecycle throughout its execution. There are no explicit restrictions to the number of MIDlets that can run simultaneously, the AMS can release resources by terminating inactive MIDlets or pausing active ones.
55

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 in the 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 to user initiated actions, actions initiated by other applications, or other events ( like a phone call )
56

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 brought to the foreground.

57

AMS
The system can close a MIDlet at any time, for example due to shortage of resources such as memory.
The AMS calls the MIDlet's destroyApp() method, forcing the application to a graceful exit. If this fails, the AMS terminates the MIDlet forcefully.

58

MIDLet Life cycle

59

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)

60

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. If a runtime exception occurs during startApp, the MIDlet will be destroyed immediately.

61

MIDlet Structure
Every MIDlet must have three methods:
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 set to 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

62

MIDlet Structure
Every MIDlet must have three methods:
destroyApp signals the MIDlet to terminate and places it in Destroyed state. 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

63

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) { } } 64

MIDP API Programming

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, and the user can traverse only through the items on that screen. 3 types of screens

66

MIDP UI
There are three types of screens:
Screens that encapsulate a complex user interface component that involves a List or TextBox component. The structure of these screens is predefined, and the application 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 related UI components to the form. Screens used within the context of the low-level API, such as a subclass of the Canvas class.

The Display class is the display manager that provides methods to retrieve information about the device's display capabilities. A screen is made visible by calling the Display.setCurrent() method.
67

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 information devices where portability is important. Low Level API provides little abstraction. It is designed for applications that need precise placement and control of graphic elements and access to low-level input events .
68

High Level API

To achieve portability, the API employs a highlevel abstraction and gives you little control over its look and feel. Interaction with components is encapsulated by the implementation 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.
69

High-Level MIDP GUI

Alert DateField Form Gauge List TextBox TextField
70

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

High-Level MIDP GUI

Command

CommandListener interface

71

Low Level API

This API gives the application full control over what is being drawn on the display. The Canvas and Graphics classes implement the low-level API. MIDlets that access the low-level API are not guaranteed to be portable because this API provides mechanisms to access details that are specific to a particular device.
72

Low-Level MIDP GUI

Canvas Raw input event Command CommandListener

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

73

Low-Level MIDP GUI

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

74

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
75

lcdui
Class diagram for lcdui class

76

Some Examples

77

RMS
Several applications need to store some data in a permanent way (even when the device is switched off) This kind of data is called persistent data and they are stored in a dedicated memory part called persistent storage MIDP defines a set of classes for storing and retrieving persistent data called Record Management System (RMS).
78

RMS
The basic storage mechanism used by the RMS is a Record Store implemented as a simple recordoriented database A Record Store can be shared among different MIDlets (only MIDP 2.0)
79

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 device then all the record stores associated with it will also be removed
80

RMS
To use the RMS, import the javax.microedition.rms package Record stores (binary files) are platform-dependent because they are created in platform-dependent locations. 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) records within 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. 81

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.

82

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 simple application
83

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 connection suport. How the device handles the sent MIDlet will be device specific. For example, the MIDlet may go into the Messaging Inbox, the AMS may be automatically or manually activated and handle the MIDlet, etc.
84

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 provide an option to install the sent MIDlet.
Trusted Source ????

85

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.
86

 A ChoiceGroup provides a group of related choices. A Form acts as a container for the other UI elements. A List provides 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.

87

 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 Ticker acts as a scrollable display of text.

88

Q&A

Time for a few Questions If none, . . . .

89

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

90