J2ME Overview

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


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


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.


MIDP ScopeMIDP Scope


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


Potential applicationsPotential applications

Potential application areas include: sport scores

financial information

e-commerce

wireless games

inter-personal communication

etc, …


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


MIDP architectureMIDP architecture


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


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



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.



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.


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,....


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


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


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


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


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


Demo: Working with the Demo: Working with the emulatoremulator


MIDletMIDlet

J2ME applications are called MIDlets (Mobile Information Device applet).


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


MIDlet SkeletonMIDlet Skeleton


MIDlet States and LifecycleMIDlet States and Lifecycle


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


MIDlet SuitesMIDlet Suites


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


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


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


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, ...)


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.



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. .



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 .



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).


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);

}


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(); } }}



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



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.



Outputs:


Demo: Loading Packaged Demo: Loading Packaged ResourcesResources

Resource files can be packaged into MIDlet suite

Use application manager’s class loader this.getClass().getResourceAsStream()


Demo: Loading an imageDemo: Loading an image


OTA ProvisioningOTA Provisioning


SummarySummary

Mobile Information Device Profile (MIDP)

J2ME applications are called MIDlets (Mobile Information Device applet).

MIDlet package (MIDlet suite) Development and deployment process

Date post:	21-Jan-2016
Category:	Documents
Upload:	hamlet
View:	76 times
Download:	2 times

J2ME Overview

Documents