J2ME OverviewJ2ME Overview
The Mobile Information Device Profile (MIDP)
<Module>/<Chapter> 2 of <total>
Chapter ObjectivesChapter Objectives
MIDP Overview Relationship of MIDP to CLDC MIDP Architecture MIDP Scope MIDP 2.0 New Features Development Tools Development Steps MIDlets MIDlet Lifecycle Building, Packaging MIDlets OTA Provisioning
<Module>/<Chapter> 3 of <total>
MIDPMIDP
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
<Module>/<Chapter> 4 of <total>
MIDP RequirementsMIDP Requirements
MIDP is more specific than CLDC about device requirements: 128 kB for the MIDP implementation 32 kB for the runtime heap 8 kB for persistent data Minimum screen: 96 x 54, 1 bit color Some method of input Two-way network connection (intermittent)
What’s a MID? Mobile phones, two-way pagers, PDAs, etc.
<Module>/<Chapter> 5 of <total>
MIDP ScopeMIDP Scope
<Module>/<Chapter> 6 of <total>
Why MIDP?Why MIDP?
Portability Write Once, Run Anywhere all over again It could work right the first time with MIDP
It’s Java Developer productivity Developer availability
Safety Downloaded code isn’t particularly safe MIDP applications can’t escape the VM
<Module>/<Chapter> 7 of <total>
Potential applicationsPotential applications
Potential application areas include: sport scores
financial information
e-commerce
wireless games
inter-personal communication
etc, …
<Module>/<Chapter> 8 of <total>
MIDP 2.0 New FeaturesMIDP 2.0 New Features
Additional network protocols HTTPS, Comm, Datagram, SSL, Socket,
ServerSocket Note: Only HTTP and HTTPS are required by
the specification Push functionality
Ability to launch a MIDlet in response to an incoming message
Over The Air (OTA) provisioning
<Module>/<Chapter> 9 of <total>
MIDP architectureMIDP architecture
<Module>/<Chapter> 10 of <total>
MIDP PackagesMIDP Packages
CLDC java.lang java.io java.util javax.microedition.i
o
MIDP javax.microedition.l
cdui javax.microedition.
midlet javax.microedition.r
ms
<Module>/<Chapter> 11 of <total>
MIDP Packages MIDP Packages (cont.)(cont.)
CLDC:
The CLDC defines the "core" of MIDP APIs (mainly came
from the J2SE world)
These include fundamental language classes in
java.lang, stream classes from java.io, and utility APIs
from java.util
It also specifies a generalized wireless network API in
javax.microedition.io
<Module>/<Chapter> 12 of <total>
MIDP Packages MIDP Packages (cont.)(cont.)
MIDP: javax.microedition.lcdui
the UI API provides a set of features for implementation of user interfaces for MIDP applications
the central abstraction of the MIDP's UI is that of a screen. a screen is an object that encapsulates device-specific graphics rendering user input. Only
onescreen may be visible at the time, and the user can only traverse through the items on that screen.
the screen takes care of all events that occur as the user navigates in the screen, with only higher-level events being passed on to the application.
javax.microedition.midlet the MIDlet package defines Mobile Information Device Profile applications and the
interactions between the application and the environment in which the application runs. Core API of MIDP An application of the Mobile Information Device Profile is a MIDlet.
<Module>/<Chapter> 13 of <total>
MIDP Packages MIDP Packages (cont.)(cont.)
MIDP: javax.microedition.rms
the Mobile Information Device Profile provides a mechanism for MIDlets to persistently store data and later retrieve it.
this persistent storage mechanism is modeled after a simple record oriented
database and is called the Record Management System. implementation details will be covered after MIDlet
programming.
<Module>/<Chapter> 14 of <total>
Development ToolsDevelopment Tools
Sun J2ME Wireless Toolkit 2.2 + Third-party code editor
Borland JBuilder NetBeans IDE IntelliJ IDEA Eclipse with EclipseME plug-in Sun ONE Studio Mobile Edition Metrowerks Third party tools,....
<Module>/<Chapter> 15 of <total>
MIDP Development StepsMIDP Development Steps
Write your Java™ application Compile it Pre-verify it Package it into a JAR file
Sign the JAR file (new in MIDP 2.0 – Optional) Create the application descriptor Publish the MIDlet suite Install OTA on the device or emulator
<Module>/<Chapter> 16 of <total>
Creating Source CodeCreating Source Code
Same as it always was Use the development kit of your choice Or use the text editor of your choice
<Module>/<Chapter> 17 of <total>
Compiling Source CodeCompiling Source Code
It’s really cross-compiling Use J2SE tools to create classes for
MIDP Use the J2SE compiler’s –bootclasspath
option, like this: javac -bootclasspath /midp-fcs/classes
Jargoneer.java
Some development kits take care of the details
<Module>/<Chapter> 18 of <total>
PreverifyingPreverifying
MIDP’s bytecode verifier is much smaller than the J2SE verifier
Bytecode verification is split into two parts: The first part is performed off the device The second part is performed on the device
Use the preverifier supplied with the development kit
For example: preverify -classpath .;/midp-fcs/classes -d . Jargoneer preverify -classpath .;/midp-fcs/classes -d . Jargoneer$Poster
<Module>/<Chapter> 19 of <total>
Using an EmulatorUsing an Emulator
Although MIDP is in a final 2.0 release, it’s only a specification
There aren’t any publicly available devices that implement MIDP
There are plenty of MIDP emulators floating around
J2MEWTK includes four emulators
<Module>/<Chapter> 20 of <total>
Demo: Working with the Demo: Working with the emulatoremulator
<Module>/<Chapter> 21 of <total>
MIDletMIDlet
J2ME applications are called MIDlets (Mobile Information Device applet).
<Module>/<Chapter> 22 of <total>
MIDletMIDlet
MIDlets™ are Java-based mobile applications, with style and convention similar to applets and servlets.
Writing MIDlets is not difficult at all (similar to Java programmer learning servlets)
All you need to do (or to learn): Some basic concepts (e.g. the MIDlet lifecycle, packaging MIDlets - the MIDlet
suites) Basic compile and run cycle Standard and vendor specific development tools and emulators Major difference between J2SE and MIDP interfaces and classes MIDlet APIs and their usage Integration of MIDlets with server-side applications (e.g. servlets) to build
comprehensive mobile EC applications Of course, the most important is to use your innovation to build MIDlet applications
<Module>/<Chapter> 23 of <total>
MIDlet SkeletonMIDlet Skeleton
<Module>/<Chapter> 24 of <total>
MIDlet States and LifecycleMIDlet States and Lifecycle
<Module>/<Chapter> 25 of <total>
MIDlet PackagingMIDlet Packaging
MIDlets are grouped in MIDlet suites MIDlet suites are packaged in JAR files The JAR manifest
contains extra information An application descriptor
file contains extrainformation as well
A MIDlet suite, then,consists of two files: A JAR with the MIDlet
classes and resources An application descriptor
JAD file
<Module>/<Chapter> 26 of <total>
MIDlet SuitesMIDlet Suites
<Module>/<Chapter> 27 of <total>
Manifest InformationManifest Information
The manifest contains extra information The name, version, and vendor of the MIDlet
suite An optional icon file name for each MIDlet The class name of each MIDlet in the suite Configuration and profile versions
Other information is optional An icon for the MIDlet suite A description and URL for the MIDlet suite The amount of persistent data required by the
MIDlet suite
<Module>/<Chapter> 28 of <total>
The Application DescriptorThe Application Descriptor
The application descriptor is a regular text properties file with a .jad extension
It’s used by a device to decide if it wants to download a MIDlet suite
It contains some of the same information as the manifest MIDlet suite name, version, and vendor A URL where the MIDlet suite JAR can be found The size, in bytes, of the MIDlet suite JAR
<Module>/<Chapter> 29 of <total>
MIDlet PropertiesMIDlet Properties
Finally, you can put extra data in the application descriptor
It’s a lot like system properties in J2SE For example, you might define a server URL
in your application descriptor It’s easy to change without rebuilding and
repackaging your MIDlet suite See getAppProperty() in
javax.microedition.midlet.MIDlet
<Module>/<Chapter> 30 of <total>
Develop your first MIDletDevelop your first MIDlet
Steps to develop a MIDlet Creating your source code Compiling your MIDlet Preverifying MIDlet class Test for your MIDlet using MIDP Emulator Port your preverified MIDlet class onto the corresponding
J2ME device (e.g. Java phones, PDAs, ...)
<Module>/<Chapter> 31 of <total>
Develop your first MIDlet Develop your first MIDlet (cont.)(cont.)
STEP 1 : Program Coding
Coding your MIDlet just like developing any Java class, you can use either:
a "simple" text editor; or
an integrated Java development tool (e.g. JBuilder, Java VisualAge, etc)
STEP 2: Compiling your MIDlet
Compiling your MIDlet is as simple as compiling any other Java objects. The most
basic way is to compile in command-line mode (i.e. javac) using J2SE 1.3.0 or above. Of course, one can use the Sun "standard" J2ME toolkit J2MEWTK, J2MEWTK contains
simple integrated J2ME development
Or, development kit supported by device vendors / Java development software.
<Module>/<Chapter> 32 of <total>
Develop your first MIDlet Develop your first MIDlet (cont.)(cont.)
STEP 3: Bytecode Preverfication
What is Preverification and why do we need that for building MIDlets?
As explained previously, a mobile always in-short of memory, especially on
the tiny device such as a Java phone or pager.
In order to solve this question, CLDC (including MIDP) specific that bytecode
verification for all MIDlets are split into TWO steps.
The first one is done during MIDlet development (so called "Preverification")
and the rest is done on the mobile device.
In particular, the mobile device only require to do a "lightweight" second
verification. .
<Module>/<Chapter> 33 of <total>
Develop your first MIDlet Develop your first MIDlet (cont.)(cont.)
STEP 4: Test your MIDlet
Test for your MIDlet by using either MIDP emulator from Sun J2MEWTK or device
vendors-supplied emulator.
For J2MEWTK KToolBar development kit,. a wide range of emulators are supplied
For any standard J2ME devices, although the outlook and functions are different,
there are some major features in common for J2ME developer: The device has a small screen size and limited input capability
At least TWO soft buttons are available. Soft buttons are buttons that do not have a pre-
defined function. More importantly, in a typical MIDlet application, a single soft button may
perform different functions on different instances (states).
Navigation buttons to allow user to browse through lists of sets of choices .
<Module>/<Chapter> 34 of <total>
Develop your first MIDlet Develop your first MIDlet (cont.)(cont.)
STEP 5 - Port your MIDlet onto the destination device Once your MIDlet is successfully debugged and tested on the MIDP emulator, you
can port your MIDlet onto the destination device.
As discussed in the previous session, you have to package all the related files (not
only your MIDlet class) into a JAR file download it to your J2ME device.
If you are using J2MEWTK, you won't have to do it manually, the toolkit will
automatically do all the jobs for you. By default, for each MIDlet application, KToolbar
will create a apps folder under J2MEWTK directory, and all the resources, class files
and manifest file are located into separate directory under this apps folder.
The MIDlet suites can be download: over the network (provided by your phone service provider)
from your desktop computer via serial cable (with download program that come with your
mobile device).
<Module>/<Chapter> 35 of <total>
Your First MIDlet – Your First MIDlet – HelloWorld_MIDletHelloWorld_MIDlet
HelloWorld_MIDlet source code
import javax.microedition.midlet.*;
import javax.microedition.lcdui.*;
public class HelloWorld_MIDlet extends MIDlet implements CommandListener{
private Display display;
private TextBox mainScreen = null;
private Command exit = new Command("exit", Command.EXIT, 2);
public HelloWorld_MIDlet() {
display = Display.getDisplay(this);
mainScreen = new TextBox("Text Box", "Hello Students ...\nNice to meet you in the MIDlet!\nKhanh Le", 512,0);
mainScreen.addCommand(exit);
mainScreen.setCommandListener(this);
}
<Module>/<Chapter> 36 of <total>
Your First MIDlet – Your First MIDlet – HelloWorld_MIDlet HelloWorld_MIDlet (cont.)(cont.)
HelloWorld_MIDlet source code (cont.)public void startApp() { display.setCurrent(mainScreen); }public void pauseApp() { }
public void destroyApp(boolean unconditional) {}
public void commandAction(Command c, Displayable s) { if(c == exit) { destroyApp(false); notifyDestroyed(); } }}
<Module>/<Chapter> 37 of <total>
Your First MIDlet – Your First MIDlet – HelloWorld_MIDlet HelloWorld_MIDlet (cont.)(cont.)
A few main features can be found in this simple program: Every MIDlet MUST import two standard javax interfaces -
javax.microedition.midlet and javax.microedition.lcdui Similar to servlet that extend HttpServlet, every MIDlet class MUST
extends MIDlet In addition to this, every MIDlet would implements a CommandListener
which involve different states (as explained in the MIDlet lifecycle) including MIDlet constructor HelloWorld_MIDlet() - MIDlet constructor startApp() - handle startup procedures pauseApp() - handle Pause state procedures destroyApplication() - MIDlet object destruction procedures commandAction() - the most important method which involve the event
handling on different commands
<Module>/<Chapter> 38 of <total>
Your First MIDlet – Your First MIDlet – HelloWorld_MIDlet HelloWorld_MIDlet (cont.)(cont.)
Perform Preverification as follows: Method 1: using Sun preverification tool - preverify
e.g. preverify -classpath .;\raymond_midp\classes -d . HelloWorld_MIDlet Method 2: using Sun J2MEWTK
- by using KToolBar of J2MEWTK, the compile step will perform the preverification automatically- a snapshot of the KToolBar interface is shown below.
<Module>/<Chapter> 39 of <total>
Your First MIDlet – Your First MIDlet – HelloWorld_MIDlet HelloWorld_MIDlet (cont.)(cont.)
Outputs:
<Module>/<Chapter> 40 of <total>
Demo: Loading Packaged Demo: Loading Packaged ResourcesResources
Resource files can be packaged into MIDlet suite
Use application manager’s class loader this.getClass().getResourceAsStream()
<Module>/<Chapter> 41 of <total>
Demo: Loading an imageDemo: Loading an image
<Module>/<Chapter> 42 of <total>
OTA ProvisioningOTA Provisioning
<Module>/<Chapter> 43 of <total>
SummarySummary
Mobile Information Device Profile (MIDP)
J2ME applications are called MIDlets (Mobile Information Device applet).
MIDlet package (MIDlet suite) Development and deployment process
Recommended