J2ME

J2ME APPLICATIONSON MOBILE DEVICES : J2ME APPLICATIONSON MOBILE DEVICES By: Chetan Manchanda

What is Mobile Computing? : 2 What is Mobile Computing? A new dimension of personal computing enabling communication and internet services at any place and at any time. Easy to use interfaces, applications and the convergence of ; VLS integration of computer, communication and consumer electronics circuits. Wireless communication technology. Internet infrastructure, embedded controllers. Speech technology

Application Examples : 3 Application Examples Retail Airline Car information system Healthcare Tracking Email access via WAP

Device Technology : 4 Device Technology Hardware Batteries Displays Memory Processors Human Machine Interface Navigation Haptic Interface Keyboard(On screen, Fitaly, T9, Octave) Speech Recognition, handwriting recognition etc. Biometrics

Operating systems : 5 Operating systems The main differences of OS for mobile devices from user’s point of view are human-machine interface, and the speed with which a task can be performed. Mobile devices have various chipsets and multiple operating systems because of wide range of usage.

Operating systems : 6 Operating systems Palm OS Applications User Interface Forms Controls Buttons Memory Management Runtime System Space System Management Events Time Alarm Communication TCP/IP Serial IrDA Microkernel

Operating systems : 7 Operating systems WinCE Applications Shells Internet Explorer Remote Connectivity Programming Interfaces, Communication interfaces Kernel GWE Object Store TCP/IP

Operating systems : 8 Operating systems QNX VxWorks BeOS Embedded Linux

Features of different OS : 9 Features of different OS

JAVA for Mobile Devices : 10 JAVA for Mobile Devices JAVA has its roots in the small device area. Current versions consists of; J2ME J2SE J2EE

Slide 11 : 11

Overview of J2ME Platform : 12 Overview of J2ME Platform JVMs , range from CardVM for smartcard, KVMs, Hotspot VMs. The Profiles are the java based APIS tailored for specific environments that provide capabilities for a specific vertical market or specific device type. A Configuration defines the minimum java libraries and VM capabilities that an application developer can expect to be available on all devices.

J2ME : 13 J2ME J2ME (Java 2 Platform, Micro Edition) Miniscule of normal Java 2 for mobile devices, such as PDA’s, mobile phones, TV boxes, etc.. For resource restricted devices Standardization effort by Sun, realizing the need to have a standard platform for all mobile device restricted devices From Java Cards, Personal Java, Embedded Java Consist of “Configuration” and “Profile” J2ME is NOT a Specification, VM or API

J2ME Universe : 14 J2ME Universe CDC More than 512kBROM, more than 256kB RAM It has restricted User Interface Library CLDC 128-256kB RAM KVM Embedded JAVA JAVA Card Real Time JAVA

J2ME : 15 J2ME

Slide 16 : 16

Slide 17 : 17 CDC Targeted for devices that have 2 MB or more total available memory Memory dedicated to J2ME environment More than 2MB ROM/Flash More than 512 KB RAM Network connectivity Full Java 2 Virtual Machine specification CDC uses Wireless communicators High-end PDAs TV set-top boxes Gateways Automotive entertainment and navigation systems Telecomm/Networking Equipment Industrial Controllers

Slide 18 : 18 The CLDC and the CDC each require their own virtual machine because of their different memory and display capabilities. The CLDC virtual machine is far smaller than that required by the CDC and supports less features. The virtual machine for the CLDC is called the Kilo Virtual Machine (KVM) The virtual machine for the CDC is called the CVM.

Slide 19 : 19 CLDC (J2ME Configuration) CLDC (Connected Limited Device Constrain) Fundamental of J2ME architecture Defines building block for device (standardization) to run Java CLDC 1.0(JSR 30) Launched Oct 1 1999 by 18 manufacturers to look for “lowest common denominator” CLDC 1.1(JSR 139) September 2001 – After MIDP 1.0 Enables Floating Point Core java.* libraries Additional I/O and networking libs Security features Internationalization

Slide 20 : 20 MIDP(J2ME Profile) MIDP (Mobile Information Device Profile) standardization based on CLDC Defines API features, focuses specifically on two way devices Application Model, user Interface, networking, security, storage API’s MIDP 1.0 (JSR 37) Started November 1999 API for security, networking and communication MIDP 2.0 (JSR 118) August 2001 after CLDC 1.1 (JSR 139) API addition Media with Sound, Camera Improvement on MIDP 1.0 Application model Persistent storage (RMS APIs) Networking (HTTP, etc.) User interface (High and low level APIs)

Slide 21 : 21 CLDC + MIDP The most popular profile and configuration that Sun provides are the Mobile Information Device Profile (MIDP) and Connected Limited Device Configuration (CLDC), respectively. CLDC is for devices with limited configurations Devices that have only 128 to 512KB of memory available for Java applications. Consequently, the JVM that it provides is very limited and supports only a small number of traditional Java classes. The MID profile provides the basic API that is used for creating application for these devices. For example, it provides the javax.microedition.lcdui package that allows us to create the GUI elements that can be shown on a (limited) device running the MID profile on top of a CLDC configuration. Note that MIDP cannot be used with CDC devices. The latest versions of MIDP and CLDC are 2.0 and 1.1, respectively. Not many devices currently support these versions, but the list is growing rapidly. Sun maintains a list of devices according to version.

Slide 22 : 22 What makes up a MIDP Application MIDP Applications are composed of two principle parts JAR File – Contains all of the classes and resources used by the application JAD File – Application descriptor, describes how to run the MIDP application

Slide 23 : 23 IMP - Information Module Profile Profile targeting embedded networked devices that wish to support a Java runtime environment, but that do not have graphical display capabilities The Information Module Profile is a strict subset of MIDP 1.0, where the APIs relating to GUI functionality (the LCDUI) are simply removed.

Slide 24 : 24 JAD Files Very simple NON-XML config file Application Name MIDI version Copyright and version information Location of the JAR file

Slide 25 : 25 Example JAD File MIDlet-1: Jargoneer, Jargoneer.png, Jargoneer MIDlet-Jar-Size: 2369 MIDlet-Jar-URL:http://www.jeffheaton.com/Jargoneer.jar MIDlet-Name: Jargoneer MIDlet-Vendor: Unknown MIDlet-Version: 1.0 MicroEdition-Configuration: CLDC-1.0 MicroEdition-Profile: MIDP-1.0

Slide 26 : 26 Steps in Designing a MIDlet There are seven steps in the creation of a MIDlet. Designing Coding Compiling Pre-verification Packaging Testing Deployment Some of these steps are not strictly MIDlet-centric (for example, every application needs to be designed, coded, and compiled), but we will cover them here because there are MIDlet-centric differences. Using a Toolkit abstracts a lot of these steps so that it is easier for you in the overall scheme of things. This is fine once you know the process, but when you are only starting out, you really should be coding by hand, rather than using an abstraction. We will create a MIDlet that, when executed, will print the current date and time on a mobile device for a short time. The lifecycle of MIDlets will be explained later.

1-Design : 27 1-Design MIDlets are different from other applications that you may have created, simply because MIDlets run in an environment that is very different. There are several issues, not just those that are most visible (for example, the interactivity of your MIDlet with the user), but others that impact its usability. For the example application, our Date-Time MIDlet does not need user interactivity. It needs to display the current date and time for a few seconds when the user executes the MIDlet. For simple cases like this, it is perhaps sufficient to mimic the design of the MIDlet by drawing it on a piece of paper. For more complex designs with multiple screens, it is best to design the screens professionally before starting the actual coding process.

2-Code : 28 2-Code Each MIDlet must extend the abstract MIDlet class found in the javax.microedition.midlet package Much like creating an applet by extending the java.applet.Applet class. At the minimum, your MIDlet must override three methods of this abstract class startApp(), pauseApp(), and destroyApp(boolean unconditional) In this example, DateTimeApp's constructor creates the element that is necessary to display the time on a device's screen The startApp method does the actual task of displaying this element. Don't worry if you don't understand how the Alert element works, or when the constructor or the other methods are called. They will be covered in the next part, when we look at the GUI elements of MIDP 2.0, and the MIDlet Lifecycle. Copy this code into a file called DateTimeApp.java and save it in a folder that mimics its package structure. import java.util.Date; import javax.microedition.lcdui.Alert; import javax.microedition.lcdui.Display; import javax.microedition.midlet.MIDlet; public class DateTimeApp extends MIDlet { Alert timeAlert; public DateTimeApp() { timeAlert = new Alert("Alert!"); timeAlert.setString(new Date().toString()); } public void startApp() { Display.getDisplay(this).setCurrent(timeAlert); } public void pauseApp() { } public void destroyApp(boolean unconditional) { } }

3-Compile : 29 3-Compile With this simple code in place, you now need to know how to compile it so that it is ready for mobile devices. Compiling MIDlets is not very much different from compiling normal Java applications. You still use javac as the compiler, except you need to change the boot CLASSPATH while compiling MIDlets. This has the effect of changing the base Java classes that the Java compiler uses to compile your MIDlet against, Ensuring that compilation is targeted towards the narrow set of Java's APIs for the J2ME platform. So instead of compiling against the java.lang.Date in "normal" Java, you actually want compilation done for J2ME's java.lang.Date. This is done by pointing to the CLDC and MIDP classes for javac's -bootclasspath option while compiling. C:\someDirectory> javac -bootclasspath CLDC_DIR\lib\cldcapi11.jar;CLDC_DIR\lib\midpapi20.jar DateTimeApp.java Notice that the compilation is done against the CLDC API's 1.1 and MIDP API's 2.0 versions, respectively, by including these libraries in the bootclasspath option. Compilation against other versions can be done if required, by simply pointing to their respective libraries.

4-Preverify : 30 4-Preverify Before you can deploy your MIDlet class, it needs to be preverified. Verification of byte code is a step performed by the JVM before it runs any class file to ensure that the class file is structurally and conceptually correct as per the JVM specification. If the class file fails this check, it is rejected and the JVM shuts down, indicating either security or integrity violation of the class file. This verification is done by all JVMs, even the tiny JVM contained in a CLDC configuration for a J2ME device. Although this is not a problem for "normal" applications, verification in J2ME devices is a resource and memory constraint that they simply cannot handle (or should not handle). Therefore, the need for preverification. Preverification is one part of a special two-step verification process, especially designed for constrained devices, such as the ones running CLDC-based JVMs. The idea is to let a developer preverify his classes, which limits the amount of work needed to be performed when the classes are verified in the device. This preverification process adds special information to the classes that identifies them as preverified and makes the process on the device much more efficient. Sun’s Wireless Toolkit comes with a preverification tool in the bin folder of its installation (e.g. C:\WTK22\bin). The following command, when executed from will preverify the DateTimeApp.class created in the previous step. C:\dir_with_class_file>TOOLKIT_DIR\bin\preverify.exe -classpath CLDC_DIR\lib\cldcapi11.jar;CLDC_DIR\lib\midpapi20.jar DateTimeApp By default, the preverifier will create the preverified version of your DateTimeApp.class file in a folder called output in the current directory. You can point the output to another folder, using the -d option for the preverify tool.

5-Package : 31 5-Package Packaging is done in a sequence of steps and you have to follow the order of steps The first step is to create a Manifest file. This Manifest file describes the contents of the Java Archive (JAR) file that we will be creating in the next step. There are several attributes that can go in this file, but for our Date-Time MIDlet, lets stick to only the ones that are required. MIDlet-Name: DateTimeAppMIDlet-Version: 1.0.0MIDlet-Vendor: BIT4 Save this file as Manifest.mf in the output folder that contains your preverified class. (Note the newline after the last attribute, MIDlet-Vendor. It must be present, otherwise this attribute will not be recognized.) Next, create the JAR file that packages up the preverified DateTimeApp.class file and the Manifest file. To create this JAR file, navigate to the output directory and issue the following command: jar cvfm DateTimeApp.jar Manifest.mf DateTimeApp.class This will create the DateTimeApp.jar file in the current folder.

Package… : 32 Package… The second-to-last step is to create a file that has an extension of .jad. A Java Application Descriptor (JAD) file points to the location of the MIDlet it describes so that a J2ME device can install it. Again, this file can contain several attributes for a single MIDlet (or for several MIDlets), but for your Date-Time MIDlet, we will stick with the ones that are required. MIDlet-1: DateTimeApp, , DateTimeAppMIDlet-Name: DateTimeAppMIDlet-Version: 1.0.0MIDlet-Vendor: BIT4MIDlet-Jar-URL: DateTimeApp.jarMIDlet-Jar-Size: MicroEdition-Profile: MIDP-2.0MicroEdition-Configuration: CLDC-1.1 Save this file as DateTimeApp.jad in the same folder as the JAR file. Note that the value of the MIDlet-Jar-Size attribute is missing. This missing value brings you to the last step of the packaging step, where you determine the size of the DateTimeApp.jar file, and put that value in this JAD file, in actual bytes. It is very important to get this exactly right, as the installation of this MIDlet will fail if this value is different from the actual size. MIDlet-Jar-Size: 1469 This completes the packaging part. (there are other steps in the packaging (for example, signing and obfuscation), but to keep things simple, I will leave those steps for later discussion.

6-Testing : 33 6-Testing Before deploying your MIDlets, they must be tested by using a base common emulator device that mimics the functionality of an actual device on your computer. This emulator is part of the Wireless Toolkit and provides functionality that is sure to be present in the majority of devices for which the MIDlet is targeted. This emulator is present in the bin folder of the Toolkit. From the output directory created in the pre-verify step earlier, and where we now have a packaged MIDlet in the form of JAR and JAD files, issue the following command to run the emulator with this JAD file as an option. OUTPUT_DIR>TOOLKIT_DIR\bin\emulator.exe -Xdescriptor DateTimeApp.jad You should see the emulator pop up on your screen with the DateTimeApp MIDlet selected. If it doesn't, the most likely error at this point would be incorrect JAR size information. Make sure you have the exact size listed in the JAD file. At the lower right-hand corner of the emulated device's screen, you can see the "Launch" menu item listed. The emulator has installed the MIDlet and is ready to launch it. Click on the phone button just underneath that menu item and the MIDlet should display the current date time for a few seconds and then disappear. Note that the MIDlet is still running even after the date and time disappear, because in code, you did not destroy it.

7-Deploy : 34 7-Deploy Now you have reached the stage where you can deploy the MIDlet directly on your mobile device. There are two ways to do this. The first is via a network connection between your computer and your handset. This can either be via a USB cable or a Bluetooth wireless connection, depending on your device. Most Java-enabled devices will allow you to install J2ME applications via this connection. Second, and the one that is more interesting, because it opens up your MIDlet to the outside world, is via the Internet. This requires that your device should be able to connect to the Internet using its internal browser. Before you proceed further, recall that when you created the JAD file, you entered two attributes in it that specified the version of CLDC (1.1) and MIDP (2.0) for which the MIDlet was created. Since the DateTimeApp MIDlet does not use any of the features of these versions, it should theoretically run on devices that support the lower versions of these attributes, as well. Therefore, the DateTimeApp MIDlet should run on CLDC 1.0 and MIDP 1.0, but because the JAD file restricts these versions to the newer ones, devices will fail to install this MIDlet if they do not support these new versions. If this is the case with your device, do not worry! Because we are not using any MIDP-2.0- or CLDC-1.1-specific features, you can simply change these version numbers in the JAD file, and this will be sufficient to install this device on all Java-enabled devices. If this is the case with your device, or the device that you are going to test this MIDlet on, simply change these values in the JAD file and you are good to go.

Deploy… : 35 Deploy… To be able to deploy your MIDlet via the Internet, you need to have access to a web server with a real-world IP address or domain name. You also need to have administrative privileges to be able to modify the configuration files of your web server to add some MIME types for the JAD and JAR extensions. If you are using Jakarta/Tomcat as your web server, you don't need to do this, as it already has these MIME types. For the Apache web server, modify the mime.types file and add the following extension types. text/vnd.sun.j2me.app-descriptor jad application/java-archive jar By adding these MIME types, you are informing the browser, or any client accessing these files from the server, how to handle these files when they are downloaded into the device. Next, create an HTML file that will become the point of reference. Strictly, this is not necessary, because a device that can access an HTML page can also access a JAD file. But an HTML page provides a point of reference, and therefore, let's create one for your Date-Time MIDlet. The HTML doesn't need to be anything fancy. Don't forget that users will be accessing this page via a mobile device, so it is prudent to keep the size of this page to the minimum. Click here to download DateTimeApp MIDlet!

Deploy : 36 Deploy The page provides a link to the JAD file The JAD file provides a link to the associated JAR file via the MIDlet-Jar-URL: DateTimeApp.jar attribute. However, since this is now going to be accessed via a web server over the Internet, it is advisable to make this link absolute instead of relative. The behavior of relative URLs is inconsistent as far as MIDlet access is concerned MIDlet-Jar-URL: http://serverName:port/directory/DateTimeApp.jar Finally, upload the modified JAD file, the newly created HTML file, and the original JAR file to your web server to a directory location where you will be able to navigate to the HTML page via your mobile device browser. Now, anyone with a mobile device that can browse the Internet should be able to point to your DateTimeApp.html file and download, install, and run the DateTimeApp MIDlet. That's it! You have completed all the steps required to manually create and deploy a MIDlet. This process has helped you to understand what goes on behind the scenes and given you confidence in all the steps of MIDlet creation. Because a lot of these steps are repetitive, it makes sense to use an automated tool. This is where the Wireless Toolkit comes in, Let's recreate the same MIDlet using this Toolkit so that you can get familiar with its interface.

Using the Toolkit : 37 Using the Toolkit Run the toolkit Create a new project The toolkit will create a folder with your project name under the apps directory Create a folder named src within that directory and copy all source files there Click Run.

MIDlet Lifecycle : 38 MIDlet Lifecycle Mobile devices, whether emulators or real, interact with a MIDlet using their own software, which is called Application Management Software (AMS). The AMS is responsible for initializing, starting, pausing, resuming, and destroying a MIDlet. Besides these services, AMS may be responsible for installing and removing a MIDlet, as well. To facilitate this management, a MIDlet can be in one of three states which is controlled via the MIDlet class methods, that every MIDlet extends and overrides. These states are Active Paused, and Destroyed MIDlet Paused MIDlet Active MIDlet Destroyed AMS new() startApp() pauseApp() destroyApp() destroyApp()

Mobile 3D Graphics API (M3G) : 39 Mobile 3D Graphics API (M3G) Java M3G API (JSR-184) provides a scalable, small-footprint, interactive 3D graphics Java API for J2ME. For a wide range of applications, including games, animated messages, screen savers, custom user interfaces, product visualization… Java M3G API is an optional package that can be adopted to existing J2ME profiles. The main target platform of the API is J2ME/CLDC, used with profiles such as MIDP 1.0 or MIDP 2.0. JSR-184 was selected by the Java Community Process (JCP) as “The most innovative JSR” in year 2003.

Mobile 3D Graphics API (M3G) : 40 Mobile 3D Graphics API (M3G) Key classes : Graphics3D, Loader and world Graphics3D : Rendering targets, Camera, Viewport, Light sources, Depth buffer, Rendering quality hints. Rendering Modes : Immediate Mode: Low level, allows to define every detail of rebdering process. Retain mode: Hides low level code, allowing user to lode animated 3d content from the file and play it using few lines of code. Difference between immediate and retained mode is vague as they can be freely mixed and matched.

Developer Tools : 41 Developer Tools Modeling tools for creating .m3g files. 3DS Max includes a built-in M3G exporter. 3DS Max is the most popular 3D modeling and animation package in the game industry.

More Information : 42 More Information http://java.sun.com http://www.forum.nokia.com