Java on Wireless Devices (J2ME)

hedgebornabaloneSoftware and s/w Development

Dec 2, 2013 (3 years and 8 months ago)

155 views

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


MIDP

PDA
Pr
ofil
e

CVM


Foundation Profile


Personal
Profile


CDC

JVM


J2SE


J2EE


Optional
Pkgs


Optional
Pkgs

J2ME

HOST Operating System

Relative Features of various VMs



JVM

Java
Spec

Target Devices

Processor

Memory

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 MB

Min 512Kb ROM

Min 256 kB RAM

Relatively
constrained GUI


KVM

J2ME

Cell Phones, Pagers, PDAs


16 bit

160
-
512 kB

Highly constrained
GUI

Card VM

Java Card
API

Smart Cards

8 bit

<32 kB


Constituents of J2ME

Configurations and Profiles

Configurations

Sun’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

Profiles

Sun’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 Device

Layout 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 downloading

1.
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 Packages

Packages 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 MIDlet

import 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
command


private 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 headers

con.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 headers

OutputStream 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 r
ecord 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