Java 2 Platform, Micro Edition (J2ME)
Contents
=======
What’s J2ME?
J2ME core concepts
Configurations (CLDC, CDC)
Profiles (MIDP)
MIDlet, MIDlet Suite
Basic classes API
Installation and using the Toolkit
Demos!!!
Introduction
Personalized and intelligent information appliances are necessities in our life today.
Such appliances can be:
cell phones
two-way pagers
smart cards
personal organizers
palmtops
These appliances tend to be special-purpose, limited-resource, network-connected devices.
Environment requirements
We need an environment which is adapted for constrained devices - devices that have limitations on what they can do when compared to standard desktop or server computers.
The constraints are:
extremely limited memory
small screen sizes
alternative input methods
slow processors
So – what’s the solution?
Because of the vast need, Sun has decided to develop a special edition of Java - J2ME (Java 2 Micro Edition).
Java Editions
Different devices have different requirements and different expectations of Java.
One platform (solution) cannot address all the market segments (web server, video games etc.)
Users/developers want flexibility. They want to choose what they want to use and what they do not.
Java Editions
The Java 2 Platform is split into three editions.
Each edition provides a complete environment for running Java-based applications, including the Java virtual machine (VM) and runtime classes.
The three editions target different kinds of applications running on different kinds of devices.
Java Editions
Java Editions
Each edition defines different sets of class libraries.
There are thousands of core J2SE runtime classes, taking up to 10-20 megabytes
of space.
J2ME-based devices have
fewer classes.
PersonalJava and EmbeddedJava
J2ME is not the first attempt at adapting Java for constrained environments.
PersonalJava
Uses the basic Java 1.1 runtime classes with a few features from Java 2.
Implementation still requires a couple of megabytes of memory and a fast processor to run.
PersonalJava and EmbeddedJava
EmbeddedJava
Makes every behavior of the JVM and the runtime classes optional - the implementor can choose exactly which classes and methods are required.
The limitation: "write once, run anywhere".
J2ME Core Concepts
Configuration
Minimum platform required for a
group of devices
Profile
Addresses specific needs of a certain device family
Optional Packages
J2ME Core Concepts
J2ME is based on 3 core concepts:
Configurations
Profiles
Optional packages
Configurations
A configuration is a complete Java runtime environment, consisting of:
Java virtual machine (VM) to execute Java bytecode
Native code to interface to the underlying system
Set of core Java runtime classes
To use a configuration, a device must meet certain minimum requirements.
Configurations
The set of core classes is normally quite small and must be enhanced with additional classes supplied by J2ME profiles or by configuration implementor.
Configurations do not define any user interface classes.
Configurations
CLDC vs. CDC
CLDC
For very constrained devices
160 - 512 KB of total memory
16-bit or 32-bit processor
Low power consumption and often operating with battery power
Connectivity with limited bandwidth
CLDC vs. CDC - VM
Features missing in
the CLDC VM:
Floating point types
Object finalization
JNI or reflection
Thread groups or
daemon threads
User Class loaders
Change in classfile verification preverification
The KVM and CVM
KVM - Java virtual machines for the CLDC
CVM - Java virtual machines for the CDC
Written specifically to work in the constrained environment of a handheld or embedded device and to be easily ported to different platforms.
CLDC and CDC specifications do not require the use of the KVM or the CVM.
CLDC vs. CDC – J2SE Subset
The CLDC includes classes from:
java.lang
java.io
java.util
Only selected classes from each package are included
CLDC vs. CDC – J2SE Subset
Handling I/O
J2SE includes many classes for performing input and output.
There are a large number of I/O classes and they tend to encapsulate I/O models that are not necessarily found on all devices.
For example, some handheld devices do not have file systems. Socket support is not universal, either.
Handling I/O in CLDC
The CLDC has define a new set of APIs for I/O called the Generic Connection Framework.
The GCF, part of the new javax.microedit ion.io package, defines interfaces for the different kinds of I/O that are possible.
The CLDC does not actually define any I/O implementations these are left to the profiles and/or the device vendor to define.
GCF - example
import java.io.*;
import javax.microedit ion.io.*;
StreamConnectio n conn = null;
InputStream is = null;
String url = "socket://somewhere.com:8 909";
try {
conn = (StreamConnecti on) Connector.open( url );
is = conn.openInputS tream();
.... // etc. etc.
} …
Handling I/O in CDC
Since the CDC is a superset of the CLDC, it includes the GCF.
CDC also requires GCF support for two specific connection types: files and datagrams.
The reason: CDC includes the relevant classes from java.io and java.net packages.
J2ME Core Concepts
J2ME is based on 3 core concepts:
Configurations
Profiles
Optional packages
Profiles
Adds domain-specific classes to a configuration:
To fill in missing functionality
To support specific uses of a device
Most profiles define user interface classes for building interactive applications.
To use a profile, the device must meet the minimum requirements of the underlying configuration and of the profile.
Profiles
MIDP – MID Profile
MIDP is targeted at a class of devices known as mobile information devices (MIDs).
Minimal characteristics of MIDs:
Enough memory to run MIDP applications
Display of at least 96 X 56 pixels, either monochrome or color
A keypad, keyboard, or touch screen
Two-way wireless networking capability
MIDP - Specification
There are two versions of the MIDP:
MIDP 1.0 - released in September 2000. Many devices currently on the market support it.
MIDP 2.0 - currently in proposed final draft form. No devices yet support it.
MIDP - Specification
The MIDP adds APIs to the basic APIs defined by the CLDC. The new features include:
Support for application lifecycle management similar to the way applets are defined in J2SE.
Persistent storage of data.
HTTP-based network connectivity based on the CLDC's GCF.
Simple user interface support, with enough flexibility to build games or business applications.
MIDP - Specification
The MIDP specification is silent about a number of things:
No standard way to interface to the device's phonebook, in order to initiate voice calls.
How MIDP applications are loaded onto a device and how they are activated or deactivated.
MIDP Applications restrictions
Memory is a particularly scarce resource.
The early Motorola J2ME-enabled phones limited the size of an application to 50K. Some Nokia phones limit them to even less, about 30K.
MIDP 1.0 applications cannot share classes.
Placing part of the application in a web or application server (as a servlet, typically) that the MIDP application calls is almost a requirement for anything serious.
J2ME Core Concepts
J2ME is based on 3 core concepts:
Configurations
Profiles
Optional packages
Optional Packages
Set of APIs in support of additional, common behaviors.
Have specific dependencies on a particular configuration and/or one or more profiles.
Examples of optional packages :
RMI Optional Package
Bluetooth Optional Package
JDBC Optional Package
What it all means
"J2ME application" is an ambiguous term.
Configuration, profile and optional packages should be chosen.
CDC-based profiles make development simpler due to J2SE-like APIs, but don’t suit the low-end devices.
CLDC-based profiles makes the development task harder, especially when trying to shrink the size of the application to run on many of the small devices.
MIDlets – The heart of J2ME…
MIDP does not support the running of applications that use a static main method as their entry point, nor calling the System.exit method in order to terminate.
Instead, we use a MIDlet, which is a MID Profile application.
MIDlets – The heart of J2ME…
Every application must extend javax.microedit ion.midlet.MIDl et class to allow the application management software to:
control the MIDlet
be able to retrieve properties from the application descriptor
notify and request state changes
MIDlets – The heart of J2ME…
The extending class is the main class of the application.
The MIDlet class defines abstract methods that the main class implements (for example: startApp(), destroyApp(), notifyDestroyed ()).
MIDlet Suite
One or more MIDlets are packaged together into a MIDlet suite, composed of:
JAR (Java archive) file
JAD (Java Application Descriptor) file
All the user-defined classes and resources required by the suite's MIDlets must be in the JAR file.
MIDlet Suite
The JAR file must also include a manifest that describe the MIDlets in the suite.
The application descriptor (JAD) contains similar information, and is used by devices to obtain information about a MIDlet suite without having to download and install the MIDlet suite first.
Creating a MIDlet
Creating a MIDlet
Creating a MIDlet
Creating a MIDlet
Sample MIDP classes API
MIDlet
Form
Command
CommandListener
ItemCommandList ener
Item
Sample classes API
MIDlet – Base class
Form
Command
CommandListener
ItemCommandList ener
Item
MIDlet class API
protected abstract void startApp()
protected abstract void pauseApp()
protected abstract void destroyApp(bool ean*uncondition al)
public final String getAppProperty( String*key)
public final void notifyDestroyed ()
Sample classes API
MIDlet
Form
Command
CommandListener
ItemCommandList ener
Item
Form class
A Form is a Screen that contains an arbitrary mixture of items: images, read-only text fields, editable text fields, editable date fields, gauges, choice groups, and custom items.
In general, any subclass of the Item class may be contained within a form.
The implementation handles layout, traversal, and scrolling.
Form class API
Item management
public int append(Item*ite m)
public Item get(int*itemNum )
Layout
public void setItemStateLis tener(ItemState Listener*iListe ner)
Sample classes API
MIDlet
Form
Command
CommandListener
ItemCommadListe ner
Item
Command class
The Command class represents the semantic meaning of an action. Command objects are presented in the user interface.
The action itself is implemented in a CommandListener object.
The CommandListener is associated with a Displayable or an Item.
Once the Command is called – the CommandListener is invoked, and the action is performed.
Command class
Command label
public String getLabel()
Command type
public int getCommandType( )
Command priority
public int getPriority()
CommandListener class API
This object is a listener for Commands that are attached to a Displayable.
public void commandAction(C ommand*c, Displayable*d)
ItemCommandList ener class API
When a command (attached to an Item) is invoked, the application is notified by having the commandAction() method called on the ItemCommandList ener that had been set on the Item.
public void commandAction(C ommand*c, Item*item)
Sample classes API
MIDlet
Form
Command
CommandListener
ItemCommandList ener
Item
Item class
A superclass for components that can be added to a Form.
All Item objects have a label field
Choose the Item’s layout, size, and appearance
Attach Commands
Item class API
public void setDefaultComma nd(Command*cmd)
public void setItemCommandL istener(ItemCom mandListener*li stener)
public void notifyStateChan ged()
public int getPreferredWid th()
Getting Started…
1st step: Download sun’s J2ME Wireless Toolkit from: http://java.sun.com/products/j2mewtoolkit/download-2_1.html
2nd step: Make sure you have J2SE SDK installed
3rd step: Install the J2ME Toolkit.
After the installation….
Shortcuts are available from the start menu.
New directories
created
Using KToolbar
Creating a new Application
Press “New Project”.
Enter the project’s name and the MIDlet’s class name.
New directories will automatically be created.
Where to place your files?
And then what?
Choose the target platform
Write your code
Save
Build
(Compile + Preverify)
Run
Distribution to actual devices
Create a package
Place your code somewhere on the net.
Update .jad file
Download the application to your mobile
Start playing…
Some other issues
OTA provisioning
Using Servlets
Working with EclipseME
Web services
The END!
You can download all the demos JARs from: www.cs.huji.ac. il/~kerengaz/j2me/
Have Fun!!!
Contents
=======
What’s J2ME?
J2ME core concepts
Configurations (CLDC, CDC)
Profiles (MIDP)
MIDlet, MIDlet Suite
Basic classes API
Installation and using the Toolkit
Demos!!!
Introduction
Personalized and intelligent information appliances are necessities in our life today.
Such appliances can be:
cell phones
two-way pagers
smart cards
personal organizers
palmtops
These appliances tend to be special-purpose, limited-resource, network-connected devices.
Environment requirements
We need an environment which is adapted for constrained devices - devices that have limitations on what they can do when compared to standard desktop or server computers.
The constraints are:
extremely limited memory
small screen sizes
alternative input methods
slow processors
So – what’s the solution?
Because of the vast need, Sun has decided to develop a special edition of Java - J2ME (Java 2 Micro Edition).
Java Editions
Different devices have different requirements and different expectations of Java.
One platform (solution) cannot address all the market segments (web server, video games etc.)
Users/developers want flexibility. They want to choose what they want to use and what they do not.
Java Editions
The Java 2 Platform is split into three editions.
Each edition provides a complete environment for running Java-based applications, including the Java virtual machine (VM) and runtime classes.
The three editions target different kinds of applications running on different kinds of devices.
Java Editions
Java Editions
Each edition defines different sets of class libraries.
There are thousands of core J2SE runtime classes, taking up to 10-20 megabytes
of space.
J2ME-based devices have
fewer classes.
PersonalJava and EmbeddedJava
J2ME is not the first attempt at adapting Java for constrained environments.
PersonalJava
Uses the basic Java 1.1 runtime classes with a few features from Java 2.
Implementation still requires a couple of megabytes of memory and a fast processor to run.
PersonalJava and EmbeddedJava
EmbeddedJava
Makes every behavior of the JVM and the runtime classes optional - the implementor can choose exactly which classes and methods are required.
The limitation: "write once, run anywhere".
J2ME Core Concepts
Configuration
Minimum platform required for a
group of devices
Profile
Addresses specific needs of a certain device family
Optional Packages
J2ME Core Concepts
J2ME is based on 3 core concepts:
Configurations
Profiles
Optional packages
Configurations
A configuration is a complete Java runtime environment, consisting of:
Java virtual machine (VM) to execute Java bytecode
Native code to interface to the underlying system
Set of core Java runtime classes
To use a configuration, a device must meet certain minimum requirements.
Configurations
The set of core classes is normally quite small and must be enhanced with additional classes supplied by J2ME profiles or by configuration implementor.
Configurations do not define any user interface classes.
Configurations
CLDC vs. CDC
CLDC
For very constrained devices
160 - 512 KB of total memory
16-bit or 32-bit processor
Low power consumption and often operating with battery power
Connectivity with limited bandwidth
CLDC vs. CDC - VM
Features missing in
the CLDC VM:
Floating point types
Object finalization
JNI or reflection
Thread groups or
daemon threads
User Class loaders
Change in classfile verification preverification
The KVM and CVM
KVM - Java virtual machines for the CLDC
CVM - Java virtual machines for the CDC
Written specifically to work in the constrained environment of a handheld or embedded device and to be easily ported to different platforms.
CLDC and CDC specifications do not require the use of the KVM or the CVM.
CLDC vs. CDC – J2SE Subset
The CLDC includes classes from:
java.lang
java.io
java.util
Only selected classes from each package are included
CLDC vs. CDC – J2SE Subset
Handling I/O
J2SE includes many classes for performing input and output.
There are a large number of I/O classes and they tend to encapsulate I/O models that are not necessarily found on all devices.
For example, some handheld devices do not have file systems. Socket support is not universal, either.
Handling I/O in CLDC
The CLDC has define a new set of APIs for I/O called the Generic Connection Framework.
The GCF, part of the new javax.microedit ion.io package, defines interfaces for the different kinds of I/O that are possible.
The CLDC does not actually define any I/O implementations these are left to the profiles and/or the device vendor to define.
GCF - example
import java.io.*;
import javax.microedit ion.io.*;
StreamConnectio n conn = null;
InputStream is = null;
String url = "socket://somewhere.com:8 909";
try {
conn = (StreamConnecti on) Connector.open( url );
is = conn.openInputS tream();
.... // etc. etc.
} …
Handling I/O in CDC
Since the CDC is a superset of the CLDC, it includes the GCF.
CDC also requires GCF support for two specific connection types: files and datagrams.
The reason: CDC includes the relevant classes from java.io and java.net packages.
J2ME Core Concepts
J2ME is based on 3 core concepts:
Configurations
Profiles
Optional packages
Profiles
Adds domain-specific classes to a configuration:
To fill in missing functionality
To support specific uses of a device
Most profiles define user interface classes for building interactive applications.
To use a profile, the device must meet the minimum requirements of the underlying configuration and of the profile.
Profiles
MIDP – MID Profile
MIDP is targeted at a class of devices known as mobile information devices (MIDs).
Minimal characteristics of MIDs:
Enough memory to run MIDP applications
Display of at least 96 X 56 pixels, either monochrome or color
A keypad, keyboard, or touch screen
Two-way wireless networking capability
MIDP - Specification
There are two versions of the MIDP:
MIDP 1.0 - released in September 2000. Many devices currently on the market support it.
MIDP 2.0 - currently in proposed final draft form. No devices yet support it.
MIDP - Specification
The MIDP adds APIs to the basic APIs defined by the CLDC. The new features include:
Support for application lifecycle management similar to the way applets are defined in J2SE.
Persistent storage of data.
HTTP-based network connectivity based on the CLDC's GCF.
Simple user interface support, with enough flexibility to build games or business applications.
MIDP - Specification
The MIDP specification is silent about a number of things:
No standard way to interface to the device's phonebook, in order to initiate voice calls.
How MIDP applications are loaded onto a device and how they are activated or deactivated.
MIDP Applications restrictions
Memory is a particularly scarce resource.
The early Motorola J2ME-enabled phones limited the size of an application to 50K. Some Nokia phones limit them to even less, about 30K.
MIDP 1.0 applications cannot share classes.
Placing part of the application in a web or application server (as a servlet, typically) that the MIDP application calls is almost a requirement for anything serious.
J2ME Core Concepts
J2ME is based on 3 core concepts:
Configurations
Profiles
Optional packages
Optional Packages
Set of APIs in support of additional, common behaviors.
Have specific dependencies on a particular configuration and/or one or more profiles.
Examples of optional packages :
RMI Optional Package
Bluetooth Optional Package
JDBC Optional Package
What it all means
"J2ME application" is an ambiguous term.
Configuration, profile and optional packages should be chosen.
CDC-based profiles make development simpler due to J2SE-like APIs, but don’t suit the low-end devices.
CLDC-based profiles makes the development task harder, especially when trying to shrink the size of the application to run on many of the small devices.
MIDlets – The heart of J2ME…
MIDP does not support the running of applications that use a static main method as their entry point, nor calling the System.exit method in order to terminate.
Instead, we use a MIDlet, which is a MID Profile application.
MIDlets – The heart of J2ME…
Every application must extend javax.microedit ion.midlet.MIDl et class to allow the application management software to:
control the MIDlet
be able to retrieve properties from the application descriptor
notify and request state changes
MIDlets – The heart of J2ME…
The extending class is the main class of the application.
The MIDlet class defines abstract methods that the main class implements (for example: startApp(), destroyApp(), notifyDestroyed ()).
MIDlet Suite
One or more MIDlets are packaged together into a MIDlet suite, composed of:
JAR (Java archive) file
JAD (Java Application Descriptor) file
All the user-defined classes and resources required by the suite's MIDlets must be in the JAR file.
MIDlet Suite
The JAR file must also include a manifest that describe the MIDlets in the suite.
The application descriptor (JAD) contains similar information, and is used by devices to obtain information about a MIDlet suite without having to download and install the MIDlet suite first.
Creating a MIDlet
Creating a MIDlet
Creating a MIDlet
Creating a MIDlet
Sample MIDP classes API
MIDlet
Form
Command
CommandListener
ItemCommandList ener
Item
Sample classes API
MIDlet – Base class
Form
Command
CommandListener
ItemCommandList ener
Item
MIDlet class API
protected abstract void startApp()
protected abstract void pauseApp()
protected abstract void destroyApp(bool ean*uncondition al)
public final String getAppProperty( String*key)
public final void notifyDestroyed ()
Sample classes API
MIDlet
Form
Command
CommandListener
ItemCommandList ener
Item
Form class
A Form is a Screen that contains an arbitrary mixture of items: images, read-only text fields, editable text fields, editable date fields, gauges, choice groups, and custom items.
In general, any subclass of the Item class may be contained within a form.
The implementation handles layout, traversal, and scrolling.
Form class API
Item management
public int append(Item*ite m)
public Item get(int*itemNum )
Layout
public void setItemStateLis tener(ItemState Listener*iListe ner)
Sample classes API
MIDlet
Form
Command
CommandListener
ItemCommadListe ner
Item
Command class
The Command class represents the semantic meaning of an action. Command objects are presented in the user interface.
The action itself is implemented in a CommandListener object.
The CommandListener is associated with a Displayable or an Item.
Once the Command is called – the CommandListener is invoked, and the action is performed.
Command class
Command label
public String getLabel()
Command type
public int getCommandType( )
Command priority
public int getPriority()
CommandListener class API
This object is a listener for Commands that are attached to a Displayable.
public void commandAction(C ommand*c, Displayable*d)
ItemCommandList ener class API
When a command (attached to an Item) is invoked, the application is notified by having the commandAction() method called on the ItemCommandList ener that had been set on the Item.
public void commandAction(C ommand*c, Item*item)
Sample classes API
MIDlet
Form
Command
CommandListener
ItemCommandList ener
Item
Item class
A superclass for components that can be added to a Form.
All Item objects have a label field
Choose the Item’s layout, size, and appearance
Attach Commands
Item class API
public void setDefaultComma nd(Command*cmd)
public void setItemCommandL istener(ItemCom mandListener*li stener)
public void notifyStateChan ged()
public int getPreferredWid th()
Getting Started…
1st step: Download sun’s J2ME Wireless Toolkit from: http://java.sun.com/products/j2mewtoolkit/download-2_1.html
2nd step: Make sure you have J2SE SDK installed
3rd step: Install the J2ME Toolkit.
After the installation….
Shortcuts are available from the start menu.
New directories
created
Using KToolbar
Creating a new Application
Press “New Project”.
Enter the project’s name and the MIDlet’s class name.
New directories will automatically be created.
Where to place your files?
And then what?
Choose the target platform
Write your code
Save
Build
(Compile + Preverify)
Run
Distribution to actual devices
Create a package
Place your code somewhere on the net.
Update .jad file
Download the application to your mobile
Start playing…
Some other issues
OTA provisioning
Using Servlets
Working with EclipseME
Web services
The END!
You can download all the demos JARs from: www.cs.huji.ac. il/~kerengaz/j2me/
Have Fun!!!
Comment