140 likes | 277 Views
J2ME Review. Le Ngoc Quoc Khanh. What we have learnt. J2ME Architecture Personal Profile and Foundation Profile CLDC MIDP High Level UI Low Level UI Event Handling RMS. J2ME Architecture. It just means Java for small devices J2ME is not A specific set of software
E N D
J2ME Review Le Ngoc Quoc Khanh
What we have learnt • J2ME Architecture • Personal Profile and Foundation Profile • CLDC • MIDP • High Level UI • Low Level UI • Event Handling • RMS
J2ME Architecture • It just means Java for small devices • J2ME is not • A specific set of software • A specific set of APIs • J2ME is divided in configurations and profiles • These provide specific information for a group of related devices
Foundation Profile • The Connected Device Configuration (CDC) is designed for the devices of the second category. These devices are not as constrained as the CLDC targeted devices • Foundation profile acts as an extension to CDC to achieve Java 2 Standard Edition functionality. • Foundation Profile is a set of Java APIs that support resource-constrained devices without a standards-based GUI system. Combined with the Connected Device Configuration (CDC), Foundation Profile provides a complete J2ME application environment for consumer products and embedded devices • Foundation Profile provides basic application support APIs without any additional support for GUIs
Personal Profile • Personal Basis Profile includes all of the APIs contained in Foundation Profile and adds support for lightweight AWT GUI components and the xlet application model. Personal Profile includes all of the APIs contained in Personal Basis Profile and adds support for full AWT compatibility and the applet application model.
CLDC is the Connected, Limited Device Configuration. The first goal is to define a specification for a JVM called the KVM (K for kilo) and the second is to define a set of Java classes (libraries). CLDC
Mobile Information Device Profile (MIDP) It’s the first finished specification It covers mobile phones, pagers, and other similar device (an exciting and exploding market) MIDP is based on CLDC and adds: Application APIs User interface APIs Persistent storage APIs MIDP
High-Level Event Handling • Before a MIDlet can recognize a message from the application manager about an event, it must set up a "listener." There are three "listener"interfaces available in the MID Profile 2.0: • CommandListener, ItemStateListener and ItemCommandListener. • When you want to process events, you will need a class that implements one or both of these interfaces. As part of the class that implements the interface(s), you will write the method(s) commandAction() and/or itemStateChanged(). This is where you place the code to decipher what event occurred and how you would like to handle the event.
Low-Level Event Handling • If you are using the low-level API, the only way to respond to keyboard input is by overriding the following methods of the Canvas class: • protected void keyPressed(int keyCode) • protected void keyReleased(int keyCode) • protected void keyRepeated(int keyCode) • The low-level API assumes only that the device has the minimal set of keys required by the MIDP specification: • The digits 0 through 9 • The star or asterisk character (*) • The pound or hash character (#)
Record Management System • Persistent storage in MIDP is based on record stores • Record Store is a small database (table) that contains pieces of data called "records". • A record store is a collection of records • The actual storage is left to the MIDP implementation • It could be a hard disk, battery-backed RAM, flash ROM, or something else • Each record is an array of bytes with a unique identification number • The content of the byte array is up to you • Everything you need is in javax.microedition.rms
Developing Process • Write your Java™ application • Compile it • Pre-verify it • Package it into a JAR file • Create the application descriptor • Publish the MIDlet suite • Install OTA on the device or emulator