470 likes | 764 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 ?.
E N D
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
Personal Profile J2ME Optional Pkgs Optional Pkgs MIDP PDA Profile Foundation Profile J2EE J2SE CDC CLDC Java Card API JVM CVM KVM Card VM HOST Operating System Position of J2ME in Java arena
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.
Steps of OTA downloading • Applications are found on the network by either the user browsing the web or by a discovery application checking dedicated servers. • The descriptor URL is passed to the Application Management Software (AMS), usually developed by device manufacturer. • The AMS retrieves the application descriptor from the server. • In the application descriptor file, the AMS finds the URL to the MIDlets Jar file. The AMS downloads the Jar file. • The AMS stores the Jar file on the device. • The user selects the application to run and launches thus the KVM… • …and finally the application starts running.
Constructor Paused destroyApp() pauseApp() startApp() Destroyed Active destroyApp() 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.
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 (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.
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(); } } A Sample MIDlet
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
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. Network 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); } } HTTP Connections in MIDP
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.
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