j2me overview n.
Skip this Video
Loading SlideShow in 5 Seconds..
J2ME Overview PowerPoint Presentation
Download Presentation
J2ME Overview

J2ME Overview

184 Vues Download Presentation
Télécharger la présentation

J2ME Overview

- - - - - - - - - - - - - - - - - - - - - - - - - - - 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.util 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, and utility APIs from java.util • It also specifies a generalized wireless network API in

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