1 / 43

J2ME Overview

J2ME Overview. The Mobile Information Device Profile (MIDP). Chapter 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.

hamlet
Download Presentation

J2ME Overview

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. J2ME Overview The Mobile Information Device Profile (MIDP)

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

  3. MIDP • 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

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

  5. MIDP Scope

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

  7. Potential applications • Potential application areas include: • sport scores • financial information • e-commerce • wireless games • inter-personal communication • etc, …

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

  9. MIDP architecture

  10. CLDC java.lang java.io java.util javax.microedition.io MIDP javax.microedition.lcdui javax.microedition.midlet javax.microedition.rms MIDP Packages

  11. MIDP Packages (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

  12. MIDP Packages (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.

  13. MIDP Packages (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.

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

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

  16. Creating Source Code • Same as it always was • Use the development kit of your choice • Or use the text editor of your choice

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

  18. Preverifying • 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

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

  20. Demo: Working with the emulator

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

  22. MIDlet • 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 

  23. MIDlet Skeleton

  24. MIDlet States and Lifecycle

  25. MIDlet Packaging • MIDlets are grouped in MIDlet suites • MIDlet suites are packaged in JAR files • The JAR manifest contains extra information • An application descriptorfile contains extrainformation as well • A MIDlet suite, then,consists of two files: • A JAR with the MIDletclasses and resources • An application descriptorJAD file

  26. MIDlet Suites

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

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

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

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

  31. Develop your first MIDlet (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.

  32. Develop your first MIDlet (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..

  33. Develop your first MIDlet (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.

  34. Develop your first MIDlet (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).

  35. Your First MIDlet – HelloWorld_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); }

  36. Your First MIDlet – HelloWorld_MIDlet (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(); } } }

  37. Your First MIDlet – HelloWorld_MIDlet (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

  38. Your First MIDlet – HelloWorld_MIDlet (cont.) • Perform Preverification as follows: • Method 1: using Sun preverification tool - preverifye.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.

  39. Your First MIDlet – HelloWorld_MIDlet (cont.) • Outputs:

  40. Demo: Loading Packaged Resources • Resource files can be packaged into MIDlet suite • Use application manager’s class loader this.getClass().getResourceAsStream()

  41. Demo: Loading an image

  42. OTA Provisioning

  43. Summary • Mobile Information Device Profile (MIDP) • J2ME applications are called MIDlets (Mobile Information Device applet). • MIDlet package (MIDlet suite) • Development and deployment process

More Related