2. Contents
What’sJ2ME?
J2ME core concepts
Configurations (CLDC, CDC(
Profiles (MIDP(
MIDlet, MIDlet Suite
Basic classes API
Installation and using the Toolkit
Demos!!!
J2ME 2
3. Introduction
Personalized and intelligent information appliances
are necessities in our life today.
Such appliances can be:
cellphones
two-way pagers
smart cards
personal organizers
palmtops
These appliances tend to be special-purpose,
limited-resource, network-connected devices.
J2ME 3
4. 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
J2ME 4
5. ?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).
J2ME 5
7. Java Editions
Differentdevices 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.
J2ME 7
8. 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.
J2ME 8
9. Java Editions
Java 2 Platform
Java2 Java2 Java2
Standard Edition Enterprise Edition Micro Edition
(J2SE™) (J2EE™) (J2ME™)
Standard desktop & Heavy duty server Small & memory
workstation applications systems constrained devices
J2ME 9
10. 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 J2EE
fewer classes. J2SE
J2ME
J2ME 10
11. 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.
J2ME 11
12. 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 12
13. J2ME Core Concepts
Configuration
Profiles
J2ME
Minimum platform Profile
required for a
group of devices
J2ME
Profile Libraries
Configuration
Addresses specific Java Language
needs of a certain
device family Java Virtual Machine
Optional Packages
Host Operating System
J2ME 13
14. J2ME Core Concepts
J2ME is based on 3 core concepts:
Configurations
Profiles
Optional packages
J2ME 14
15. 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
Touse a configuration, a device must
meet certain minimum requirements.
J2ME 15
16. 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.
J2ME 16
18. CLDC vs. CDC
CLDC CDC
For very constrained 2 MB or more
devices memory for Java
160 - 512 KB of total platform
memory 32-bit processor
16-bit or 32-bit High bandwidth
processor network connection,
Low power most often using
consumption and TCP/IP
often operating with
battery power
Connectivity with
limited bandwidth
J2ME 18
19. CLDC vs. CDC - VM
Features
missing in The CDC supports a
the CLDC VM: complete, full-
featured Java 2
Floating point types virtual machine
Object finalization
JNI or reflection
Thread groups or
daemon threads
User Class loaders
Change in classfile
verification preverification
J2ME 19
20. 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.
J2ME 20
21. CLDC vs. CDC – J2SE Subset
TheCLDC includes The CDC includes
classes from: 17 packages
java.lang Includes more
java.io classes even in the
java.util shared packages
Onlyselected
classes from each
package are
included
J2ME 21
23. 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.
J2ME 23
24. 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.microedition.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.
J2ME 24
25. GCF - example
import java.io.*;
import javax.microedition.io.*;
StreamConnection conn = null;
InputStream is = null;
String url = "socket://somewhere.com:8909";
try {
conn = (StreamConnection) Connector.open( url );
is = conn.openInputStream();
.... // etc. etc.
}…
J2ME 25
26. 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 26
27. J2ME Core Concepts
J2ME is based on 3 core concepts:
Configurations
Profiles
Optional packages
J2ME 27
28. 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.
J2ME 28
29. Profiles
Profile
Profile
MIDP
MIDP PDAP
PDAP FP
FP PBP
PBP PP
PP
Mobile Personal Foundation Personal Personal
Information Digital Profile Basis Profile Profile
Device Assistant
Profile Profile
J2ME 29
30. 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
J2ME 30
31. 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.
J2ME 31
32. 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.
J2ME 32
33. MIDP - Specification
TheMIDP 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.
J2ME 33
34. 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 34
35. J2ME Core Concepts
J2ME is based on 3 core concepts:
Configurations
Profiles
Optional packages
J2ME 35
36. 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
J2ME 36
37. 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.
J2ME 37
39. …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.
J2ME 39
40. …MIDlets – The heart of J2ME
Every application must extend
javax.microedition.midlet.MIDlet 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
J2ME 40
41. …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()).
J2ME 41
42. MIDlet Suite
One or more MIDlets are packaged
together into a MIDlet suite, composed
of:
JAR (Java archive) file
JAD (Java Application Descriptor) file
Allthe user-defined classes and
resources required by the suite's MIDlets
must be in the JAR file.
J2ME 42
43. 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.
J2ME 43
52. 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.
J2ME 52
53. Form class API
Item management
public int append(Item item)
public Item get(int itemNum)
Layout
publicvoid
setItemStateListener(ItemState
Listener iListener)
J2ME 53
54. Sample classes API
MIDlet
Form
Command
CommandListener
ItemCommadListener
Item
J2ME 54
55. 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.
J2ME 55
56. Command class
Command label
public String getLabel()
Command type
public int getCommandType()
Command priority
public int getPriority()
J2ME 56
57. CommandListener class API
Thisobject is a listener for Commands
that are attached to a Displayable.
public void
commandAction(Command c,
Displayable d)
J2ME 57
58. ItemCommandListener class API
When a command (attached to an Item)
is invoked, the application is notified by
having the commandAction() method
called on the ItemCommandListener that
had been set on the Item.
public void
commandAction(Command c,
Item item)
J2ME 58
59. Sample classes API
MIDlet
Form
Command
CommandListener
ItemCommandListener
Item
J2ME 59
60. 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
J2ME 60
61. Item class API
public void
setDefaultCommand(Command cmd)
public void
setItemCommandListener(ItemCom
mandListener listener)
public void
notifyStateChanged()
public int getPreferredWidth()
J2ME 61
62. …Getting Started
1st
step: Download sun’s J2ME
Wireless Toolkit from:
http://java.sun.com/products/j2mewtoolkit/d
ownload-2_1.html
2nd step: Make sure you have J2SE
SDK installed
3rd step: Install the J2ME Toolkit.
J2ME 62
63. ….After the installation
Shortcuts are available from the start menu.
New directories
created
J2ME 63
65. Creating a new Application
Press “New Project”.
Enter the project’s name and the MIDlet’s
class name.
New directories will automatically be created.
J2ME 65
66. Where to place your files?
J2ME/apps/{proj} source, resource, and binary
files
J2ME/apps/{proj}/bin JAR, JAD, unpacked manifest
files.
J2ME/apps/{proj}/lib external class libraries, (JAR or
ZIP) for a specific project
J2ME/apps/{proj}/res resource files
J2ME/apps/{proj}/src source files
external class libraries, (JAR or
J2ME/apps/lib ZIP) for all KToolbar projects.
J2ME 66
67. And then what?
Choose the target platform
Write your code Java Technology for the Wireless
JTWI - conforms to
Industry (JSR-185).
Save
MIDP1.0 - includes MIDP 1.0 and CLDC 1.0
Custom - user defined settings, you can select project
Build
profile, configurations and various APIs.
(Compile + Preverify)
Run
J2ME 67
68. 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…
J2ME 68
69. Some other issues
OTA provisioning
Using Servlets
Working with EclipseME
Web services
J2ME 69
Stat with: Who doesn’t own a cellphone? Say that it is different than anything we knew until today.
The main difference is the size of libraries. 10-20 megabytes – too big for the majority of devices. Fewer classes – especially the smaller devices.
The Java runtime environment can only be used by the implementor and cannot be exposed to third parties
Class files are processed by an off-device class verifier, a process called preverification . At runtime, the VM uses information inserted into the class files by the preverifier to perform the final verification steps. Files that have not been processed by the preverifier are not loaded since they cannot be verified.
Many device manufacturers license the KVM or CVM from Sun Microsystems to serve as the core of their J2ME implementation, they are not required for J2ME compliance.
Only selected classes from each package are included: for example, the java.util.Vector and java.util.Hashtable classes are included, but none of the collection classes are. The largest package is the java.lang package, which defines the classes that are fundamental to any java application, classes like java.lang.Object or java.lang.Integer. The java.io subset only includes abstract and memory-based classes and interfaces like java.io.DataInput or java.io.ByteArrayInputStream. The java.util subset only includes a few utility classes.
It defines interfaces and a factory class for creating objects that implement those interfaces.
The code above assumes that the device knows how to map the "socket" protocol in the URL to an object that implements the GCF's StreamConnection interface, which defines methods for obtaining the input and output streams of a socket connection. It should be noted, however, that the CLDC does not actually define any I/O implementations. In other words, the CLDC defines the interfaces of the GCF, but the implementation classes -- the ones that do the actual I/O -- are left to the profiles and/or the device vendor to define. For example, the Mobile Information Device Profile (MIDP) -- a CLDC-based profile -- requires support for a subset of HTTP 1.1 and so it recognizes the "http" protocol in URLs and returns objects that implement the GCF's ContentConnection interface.
By itself, the CLDC is a limited programming platform. Because it does not define any user interface classes or implement any I/O models, about all you can do for output is write to the System.out stream, which may or may not be captured to a console or file. You really need the extra classes defined by a J2ME profile (like those of the MIDP) or device-specific classes (like those on the RIM BlackBerry devices or certain Japanese i-Mode phones) to do anything interactive.
Several profiles in various stages of development: Mobile Information Device Profile (MIDP) - CLDC-based, used for running applications on cellphones and interactive pagers with small screens, wireless HTTP connectivity, and limited memory. Personal Digital Assistant Profile (PDAP) – CLDC-based, extends MIDP with additional classes and features for more powerful handheld devices. Foundation Profile (FP) – CDC-based, extends the CDC with additional J2SE classes. Personal Basis Profile (PBP) - extends the FP with lightweight (AWT-derived) user interface classes and a new application model. Personal Profile extends the PBP with applet support and heavyweight UI classes.
Almost any wireless device built these days fits the definition of a MID, including low-end cellphones. Personal digital assistants (PDAs) can also be considered to be MIDs because wireless networking is now an option for most PDAs, but MIDP doesn't target these devices. Personal digital assistants (PDAs) can also be considered to be MIDs because wireless networking is now an option for most PDAs, but MIDP doesn't target these devices specifically: PDAs have more memory, larger screens, and interesting information management capabilities that are more effectively exploited using other profiles.
The MIDP 1.0 specification was defined by an expert group consisting of all the major players in the wireless and handheld device arena, including familiar names like Motorola, Nokia, Ericsson, Research in Motion, and Symbian. It has a lot of support in the telecommunications industry, and handset manufacturers like Motorola and Nokia in particular are devoting a lot of development effort to supporting MIDP in a wide range of their devices.
J2ME enabled phones raised to 100K on more recent models
Have minimum requirements. RMI – Remote Method Invocation JDBC – Java Data Base Connectivity
The first concept we have to understand is the MIDlet
Extends MIDlet like extending Applet class
A Java Application Descriptor (JAD) file. This file contains a predefined set of attributes that allows the device application management software to identify, retrieve, and install the MIDlets. A Java Archive (JAR) file. The JAR file contains Java classes for each MIDlet in the suite and Java classes that are shared between MIDlets. The JAR file also contains resource files used by the MIDlets and a manifest file.
Show manifest and jad files
Show the DEMO – HelloSuite.
The items contained within a Form may be edited using append, delete, insert, and set methods. Items within a Form are referred to by their indexes An item may be placed within at most one Form Items Layout - Layout policy in Form is organized around rows . Forms grow vertically and scroll vertically as necessary. The height of a Form varies depending upon the number of rows and the height of each row. An implementation may choose to lay out Items in a left-to-right or right-to-left direction depending upon the language conventions in use. You can use LAYOUT_LEFT, LAYOUT_RIGHT,LAYOUT_CENTER, considering row-breaks etc.
Displayable: (an object that has the capability of being placed on the display(Screen,Canvas)
Possible Command types: The defined types are BACK , CANCEL , EXIT , HELP , ITEM , OK , SCREEN , and STOP .
CommandListener – attaching the listener to the entire screen, the command can be of type SCREEN or anything else…
ItemCommandListener attaching the listener to a specific item, the command should be of type ITEM. A listener type for receiving notification of commands that have been invoked on Item objects.
Item has many layouts, including LAYOUT_DEFAULT , LAYOUT_LEFT , LAYOUT_RIGHT , LAYOUT_CENTER , LAYOUT_TOP , LAYOUT_BOTTOM , LAYOUT_VCENTER , LAYOUT_NEWLINE_BEFORE , LAYOUT_NEWLINE_AFTER , LAYOUT_SHRINK, LAYOUT_VSHRINK , LAYOUT_EXPAND , LAYOUT_VEXPAND , LAYOUT_2 Sizes: the implementor can set the sizes of an item. If the application attempts to lock a preferred size dimension to a value smaller than the minimum or larger than the maximum, the implementation may disregard the requested value and instead use either the minimum or maximum as appropriate. If this occurs, the actual values used must be visible to the application via the values returned from the getPreferredWidth and getPreferredHeight methods. Appearance: The StringItem and ImageItem classes have an appearance mode attribute that can be set in their constructors. This attribute can have one of the values PLAIN, HYPERLINK, or BUTTON
There’s sun’s download center Choose the relevant operating system. Available for windows, linux, solaris. (not for OS X, although MIDP is available). You need java sdk 1.3 or higher Install the toolkit in a directory with no space in its name…
KToolbar is the main working tool to handle J2ME applications You can create a new project, open an existing one, choose the emulator device, change the settings, build (compile and preverify) and run the simulation.
When creating a new project, you have to give it a name ( the name of the project will be the name of the directory under apps), and give the name of the MIDlet class.
Target setting - The project settings information and tabs change based on the selection you choose for the target platform. Some project settings are not applicable for a selected target platform. Building using the KToolbar – creating the classes and the .jad file Preverify – makes sure that the .jad is updated with the .jar files. That the used classes in the application are available in the chosen target platform. Doing so allows the device using the application without further checking which require more memory and cpu. Run – with the emulator, from the KToolbar
Finally, MIDlets are bundled into MIDlet suites for distribution to actual devices. This process entails JARing the MIDlet suite class files and the resource files, and putting some extra information in the JAR manifest. Again, these chores are best left to the J2ME Wireless Toolkit. To bundle up your MIDlet suite, select Project | Package from the menu. The .jad and .jar files for the MIDlet suite will be generated and placed in the bin directory of the project. The .jad file should contain the correct address of where the files are located on the net.
Once your application is in a stable state, you are ready to see how your application performs in a more realistic environment, that is the downloading and running of your application onto a mobile device from a browser or server. At this point, you will want to run your application using Over-The-Air (OTA) provisioning. The J2ME Wireless Toolkit simulates OTA provisioning, that allows you to test the functionality of your application and demonstrate the full provisioning process of your MIDlet suite from a web server to a device. With simulated OTA provisioning in the Wireless Toolkit, the MIDlet suite is packaged in the JAR and JAD format, deployed to the provisioning server, and downloaded to an emulated device.