java on wireless devices
DESCRIPTION
Java on Wireless Devices. J2ME. Contents. Introduction to J2ME Constituents of J2ME – Configurations and Profiles More into MIDP Applications - MIDlets Designing User Interfaces using MIDP Networking using MIDP J2ME Database. J2ME. An Introduction. What is J2ME ?. - PowerPoint PPT PresentationTRANSCRIPT
Java on Wireless Devices
J2ME
Contents Introduction to J2ME Constituents of J2ME – Configurations
and Profiles More into MIDP Applications - MIDlets Designing User Interfaces using MIDP Networking using MIDP J2ME Database
J2ME
An Introduction
What is J2ME ? J2ME stands for Java 2, Micro Edition It just means Java for small devices which have many
usability constraints such as• Memory• Display area• Battery Life• Network Connectivity
J2ME is not:• A fixed, specific set of software• A fixed, specific set of API
J2ME is divided into Configurations and Profiles, which provide specific information and features for a group of related devices
Why J2ME ? Java’s perspective
Java API for low bandwidth devices Advanced Java API for Rapid Application
Development on low end clients Inherits Java’s USP: Platform Independence,
Object-oriented approach, In-built security, Easy to Use
Large Developer community
Why J2ME ? Applications perspective Dynamically
downloadable/upgradeable/removable Applications
Dynamic content Applications Off-line execution on Device – J2ME’s edge over
WAP API’s for Data Security applicable to banking and
m-commerce applications Richer GUI related to the devices’ constraints APIs for Network Connectivity Stand alone applications – (Usually) Do not need
any browser to run
Position of J2ME in Java arena
Card VM
Java Card API
KVM
CLDC
MIDPPDA
Profile
CVM
Foundation Profile
Personal Profile
CDC
JVM
J2SEJ2EE
Optional Pkgs Optional
Pkgs
J2ME
HOST Operating System
Relative Features of various VMsJVM Java
SpecTarget Devices Processo
rMemory
HotSpot VM
J2EE Enterprise Servers Up to 64 bit Upwards of 2 MB
HotSpot VM
J2SE Workstations, Desktop Clients, Laptops
32-64 bit Upwards of 2MB
CVM J2ME High end, consumer electronic and embedded devices like wireless communicators eg.
devices running Symbian's EPOC OS), high-end PDAs (e.g. devices
running embedded Linux or Windows CE), residential
gateways, automotive telematic systems, set-top boxes and
screen phones
32 bit 2MB – 10 MBMin 512Kb ROMMin 256 kB RAM
Relatively constrained GUI
KVM J2ME Cell Phones, Pagers, PDAs 16 bit 160-512 kBHighly
constrained GUI
Card VM Java Card API
Smart Cards 8 bit <32 kB
Constituents of J2ME
Configurations and Profiles
ConfigurationsSun’s definition: A configuration is defined as the
combination of a Virtual Machine (VM) and "core" APIs that represent an underlying development platform for a broad class of devices
Thus, A configuration is a specification for a certain class of devices
having similar capabilities Usually based on available memory, display and processing power
of the target set of devices Specifies a JVM, which can be ported to the target set of devices Specifies a subset of J2SE APIs that will be available to the target
set of devices
ProfilesSun’s definition: A profile is defined as a set of APIs
for a specific vertical market and relies upon the underlying configuration's capabilities to create new, market-specific APIs.
Thus, a Profile Is Built on Configurations Targets more specific set of devices than configurations Adds APIs for User Interface, Persistent storage,
available input and output facilities and other features that may be needed to run applications on that particular segment of devices.
J2ME Delivers: Two Configurations:
• CDC – Connected Device Configuration• CLDC – Connected, Limited Device Configuration
Two major Profiles:• MIDP – Mobile Information Device Profile• Foundation Profile• Others Upcoming – PDA Profile, Personal Profile, RMI
Profile, Java Game Profile, MIDP_NextGen Profile
Configurations-1: CDC CDC is based on CVM The CVM is a full-featured, Java 2 Virtual Machine;
designed for devices needing the functionality of the Java 2 VM feature set.
The CDC is a configuration that could become interesting for mobile terminals as their capabilities increase
CDC targets networked devices with relatively constrained Graphical user Interfaces.
Basic packages: java.lang, java.util, java.net, java.io, java.text, java.security
Configurations-2: CLDC CLDC is based on KVM Limitations w.r.t. J2SE:
• No support for JNI (Java Native Interface)• Limited bytecode verifier• Limited support for internationalization• No support for object finalization• No thread groups and daemon threads• Limited error handling• Simplified sandbox security model• No certificates supported• No refection: No Serialization, RMI or JINI
Features like Floating point support and J2ME Web Services support added in latest CLDC v1.1
CLDC Packages java.io - Provides for system input and output through byte and data
streams. java.lang - Language Classes included from J2SE java.util - Utility Classes included from J2SE.
Profiles 1 - MIDP Target devices have a small display area (min. 96x54 pixels) and a touch
pad Adds the following features to CLDC:
• Defining and controlling applications• Displaying text, graphics and responding to user events• Storing data in simple databases• Network connectivity via a subset of HTTP• Timer notifications
kxml and Nanoxml are two XML parsers on the device side Latest MIDP v2.0 adds support of HTTPS for ensuring end-to-end
security. Other features enhanced in GUI, network connectivity (using different
types of sockets), Audio support, Game Support, OTA Provisioning etc. More details to be taken later
Profiles 1: MIDP (Contd.)
New features added in MIDP 2.0• Enhanced UI – Richer and more flexible screen widgets• Media Support – You can add audio to your applications• Game Support – Game API for enhanced graphics,
performance and ease of development• Expanded Connectivity – Added support for different types
of sockets• Push Architecture – Servers can now invoke MIDlets for
alerts and broadcast• OTA Provisioning – Mandates a single, standard approach
for OTA MIDlet deployment on the devices.• End to End Security – Support of HTTPS and X.509 PKI
certificates.
Profiles 2 – Foundation Profile It provides a profile of the Java 2 Platform, suitable for
devices that need support for a rich, network enabled Java environment, but do not require a graphical user interface.
It is used by other profiles, targeted for devices of similar profile, but having their own GUI packages.
Other Upcoming Profiles PDA Profile – Is based on CLDC, meant for PDAs
• adds a display toolkit, which is a subset of AWT • Simple persistent data storage for applications, data, and
configuration information.
Personal Profile – Is based on CDC, meant for devices providing high Internet connectivity and web fidelity
RMI Profile – Provides RMI features for invoking remote services e.g. Printer, distributed objects from the device
Java Games Profile – Provides core audio-video features for development of Games, animations, videos etc.
MIDP Applications
An Insight
MIDP Applications in a DeviceLayout of applications on a typical device is as shown below:
MIDP Applications - MIDlets Applications in MIDP are called MIDlets These applications/MIDlets can be downloaded, updated for newer
versions or removed from the device These MIDlet applications can be used in offline mode as well, e.g.
Games, Text Editors etc. The user need to connect to the server only if he/she wants to upload some data.
Properties of MIDlets are described in a application descriptor file: a regular text file with an extension of .jad
MIDlet suites are packaged as jar files, which contain the class files for that application as well as other resource files required at runtime
A jar Manifest file contains other information like name, version, vendor, icon, MIDlet class name etc.
OTA Downloading of a MIDlet
Steps of OTA downloading1. Applications are found on the network by either the user browsing
the web or by a discovery application checking dedicated servers.
2. The descriptor URL is passed to the Application Management Software (AMS), usually developed by device manufacturer.
3. The AMS retrieves the application descriptor from the server.
4. In the application descriptor file, the AMS finds the URL to the MIDlets Jar file. The AMS downloads the Jar file.
5. The AMS stores the Jar file on the device.
6. The user selects the application to run and launches thus the KVM…
7. …and finally the application starts running.
MIDlets – Life Cycle The application must extend the class
javax.microedition.midlet to allow the application management software to control the MIDlet and to be able to retrieve properties from the application descriptor, notify and request state changes.
Destroyed
Active
Paused
Constructor
startApp() pauseApp()
destroyApp()
destroyApp()
MIDP PackagesPackages available for development of MIDP applications
MIDP Packages javax.microedition.lcdui - The UI API provides a set of features for
implementation of user interfaces for MIDP applications javax.microedition.rms - The MIDP provides a mechanism for
MIDlets to persistently store data and later retrieve it. E.g. RecordStore
javax.microedition.midlet - The MIDlet package defines MIDP applications and the interactions between the application and the environment in which the application runs
javax.microedition.io - This includes networking support classes based on the GenericConnection framework from the CLDC e.g. HTTPConnection, DatagramConnection etc.
MIDP Applications
Designing User Interfaces
MIDP User Interface
MIDP User Interface (Contd.) Display is the primary class for any GUI – There is only
one instance of Display per MIDlet. Display instantiated as : Display.getDisplay(MIDlet m) A Display displays the various Displayable objects, and
also controls the sequence of the various Displayable objects. (setCurrent() API)
Other classes – Command, Image, Font, Graphics, Ticker etc.
The Item class is the abstract parent of many items.
A Sample MIDletimport javax.microedition.midlet.*;import javax.microedition.lcdui.*;import javax.microedition.io.*; import java.io.*; import org.kxml.*; import org.kxml.parser.*;
/** Main MIDlet class */ public class MyMIDlet extends MIDlet
implements CommandListener { private Command exitCommand; // The exit commandprivate Command goCommand; private Display display; // The display for this MIDlet private final static String SERVLET_URL = 18.
"http://127.0.0.1:8080/ServletXML/ServletXML";private List list; private static String textBoxString = "";
public MyMIDlet() {display = Display.getDisplay( this ); exitCommand = new
Command( "Exit", Command.EXIT, 2 ); goCommand = new
Command( “GO", Command.SCREEN, 1 ); list = new List(“Commands List”,
Choice.IMPLICIT);}
/** Start up the MIDlet by associating list.with options, adding the commands and listener. */
public void startApp() { list.append(“First command”, null); list.append(“Second command”, null);list.addCommand( exitCommand ); list.addCommand( goCommand ); list.setCommandListener( this ); display.setCurrent( list );
} /** Pause is a no-op since there are no background
activities or 43. record stores that need to be closed. */
public void pauseApp() { } /** Destroy must cleanup everything not handled by the
garbage collector. */ public void destroyApp(boolean unconditional) { } /* Respond to commands*/ public void commandAction(Command c,
Displayable d) { if ( c == exitCommand ) {
destroyApp( false ); notifyDestroyed();
}else if ( c == goCommand ) {
if (((List)d).getSelectedIndex() == 0) processCommandOne();
else if (((List)d).getSelectedIndex() == 1)
processCommandTwo();}
}
Other GUI Components TextBox, TextField – For Text Inputs Ticker – To display a Scrolling message Alert – A dialog message for Alarms, info, confirmation, error and
warnings. Can be user or timer driven. List – Displays a list of options to choose from Gauge – Progress bar Image – Any image to be associated with widgets. It is a .png file DateField – For representing date fields Form – A customizable screen which may contain many different
components (like an HTML page).
Command Class A Command is equivalent to a Button It can be classified into “OK”, “Back”, “Cancel”, “Exit”, “Screen” etc. To show commands, add them to a Displayable Register with a Displayable to receive notifications, and pass a listener To listen for command events, implement the CommandListener
interface This has only one method, commandAction()
Form A customizable screen which may contain many different
components/items Use append() and insert() for adding items Use set() for modifying an item Use delete() to remove an item You can register an ItemStateListener with a Form Use the setItemStateListener() method The listener has a single callback:
public void itemStateChanged(Item item)
MIDP Applications
Networking with External Entities
Network Connections in MIDP CLDC specifies a generic
connection mechanism, which can be customized by implementations.
MIDP defines Connection and its subinterfaces for more specific types of connections
Connector is a factory class which takes in a URL string and opens a Connection, which can be typecast to any of the sub-defined connection interfaces.
HTTP Connections in MIDP GET:Connection con = (HttpConnection)Connector.open(url);
InputStream is = con.openInputStream();
// Get the length and process the data
int len = (int)con.getLength();
if (len > 0) {
byte[] data = new byte[len];
int actual = is.read(data);
}
else{
int ch;
while ((ch = is.read()) != -1) {
doSomething(ch);
}
}
is.close();
con.close();
POST:Connection con = (HttpConnection)Connector.open(url); // Set the request method and headerscon.setRequestMethod(HttpConnection.POST);con.setRequestProperty("If-Modified-Since", "29 Oct 1999 19:43:31
GMT");con.setRequestProperty("User-Agent", "Profile/MIDP-1.0
Configuration/CLDC-1.0");con.setRequestProperty("Content-Language", "en-US"); // Getting the output stream may flush the headersOutputStream os = con.openOutputStream();os.write("LIST games\n".getBytes());os.flush(); // Opening the InputStream will open the connection InputStream is = con.openInputStream(); // Get the length and process the data int len = (int)con.getLength(); if (len > 0) {
byte[] data = new byte[len]; int actual = is.read(data); process(data);
} else { int ch; while ((ch = is.read()) != -1) {
process((byte)ch); }
}
MIDP Applications
Storing Persistent Data
J2ME Databases Persistent storage in MIDP is based on record stores A record store is a collection of records. Each record is an array of bytes with a unique identification number Actual storage of records depends on MIDP implementation. It could
be hard disk on the device, a battery-backed RAM etc. The package javax.microedition.rms provides API for handling device
datastores. The class RecordStore consists of APIs such as openRecordStore(),
closeRecordStore(), deleteRecordStore(), listRecordStore() for RecordStore manipulation.
It also consists of APIs such as addRecord(), deleteRecord(), get and setRecord() for record manipulation.
J2ME Databases (Contd.)
A RecordStore allows eventlistener to be registered with itself.
This eventlistener is a class which implements a RecordListener interface to get notifications for addition, deletion and updating of records in that RecordStore.
J2ME also provides interfaces such as RecordComparator, RecordEnumerator and RecordFilter for comparing, enumerating and filtering of records from a RecordStore, respectively.
Mobile Databases File based storage
PDB(Palm Database) Databases
Sybase SQL Anywhere Studio 8.0 Oracle 9i Lite Relational database UltraLite from AppForge and
iAnyWhere Pocket Access 2002 SQL Server CE
J2ME Toolkit J2ME provides a toolkit for compiling and verifying the
source files. It then creates the jar file for the compiled classes and also makes the .jad file.
This toolkit provides 4 different device emulators to test the application.
It provides a Panel where the debug statements of the application get printed.
It provides a UI to specify the Application Properties, such as Servlet path etc. which are used by the application at runtime.
Visto’s J2ME Sync Client A client meant for synchronizing Calendar, Contacts and Email.
(Currently, having default implementation for Calendar/Contacts) Consists of its own GUI for Email (Calendar and Contacts in future) Creates and Opens up its own RecordStore for storing of Emails,
Calendar, and Contacts. Provisions the device for Email synchronization. Synchronizes the data present in its record stores with the ones at the
Corporate Server through the Sync Server, after comparisions. Maintains the state machine of the sync at the client. Sends the Sync data in WBXML format. Also contains code for performing encoding and Blowfish encryption
algorithms on the data.
Optional Profile Packages
Other competing technologies BREW (Binary Runtime Environment for Wireless) designed by
QualComm, based on C, C++ - It provides the device’s functionalities available to the application such as Memory Mgmt, Notifications, Networking, Display, UI etc.
MExE – (Mobile Execution Environment) – created by ETSI, maintained by 3GPP) - provides a standardized environment for appln execution on Mobile Devices.It provides interoperability between devices by defining “Classmarks” which cater to different groups of devices, e.g. WAP Environment, PersonalJava Environment, J2ME CLDC Environment and an upcoming Microsoft .NET Environment.
Personal Java and Embedded Java – These are subsets of J2ME, and target the devices which have smaller footprint than the J2ME devices
Lets Think Small !!
Thanks for Your Patience