MIDlets are Java classes that form the interface between an application and the operating system in an MIDP device.
A group of collected MIDlets forms a MIDlet suite. The MIDlets in a MIDlet suite are packaged and installed on a mobile device as a single entity, known as the JAR file. The JAR file represents a MIDlet suite. This chapter explains the lifecycle of MIDlets. Further, it discusses executing and testing MIDlet applications. In addition, it discusses the process of managing and building a MIDlet suite.
Applications that are developed by using Java ME APIs are called MIDlets. MIDlets run on Java-enabled mobile devices. Although MIDlets are similar to Java applets, the following list states some differences between a MIDlet and an applet:
- An applet is a Java class file embedded into an HTML page. On the other hand, a MIDlet is a Java class file packaged into a Java Archive (JAR) file.
- An applet runs in a Web browser. On the other hand, a MIDlet runs in an Application Management Software (AMS) that is already installed on MIDP devices. AMS provides an environment for KVM and MIDlets.
- An applet is viewed in a browser or applet viewer tool on desktop computers. On the other hand, a MIDlet is viewed on handheld devices that support CLDC and MIDP.
Similar to an applet, a MIDlet undergoes various changes in its state. The life cycle of a MIDlet describes the sequence of the MIDlet’s states. The life cycle begins when a MIDlet is launched in a mobile device, paused when a call comes onto the mobile device, and ends when the MIDlet is destroyed. A MIDlet inherits the properties and methods of the MIDletclass, which is located in the javax.microedition.midletpackage of MIDP APIs. The MIDlet class contains all the methods that define the life cycle of a MIDlet. The MIDletclass provides three basic methods, startApp(), pauseApp(), and destroyApp()to control the execution of a MIDlet.
All the class files of a MIDlet application need to be packaged into a JAR file. Each JAR file may contain more than one MIDlet application. This group of MIDlet applications is known as a MIDlet suite. You can download a JAR file and install it in a mobile device by using either a serial cable connected to a computer or a wireless network. When the JAR file is installed, a menu entry appears for each MIDlet in the MIDlet suite. You can select and execute the required MIDlet application from the menu entries. The following figure shows various menu entries for each MIDlet in a MIDlet suite.
A MIDlet suite consists of one or more MIDlets packaged in a JAR file. A MIDlet suite contains all the resources to run a Java ME application on a mobile device. The packaging and deployment of a Java ME MIDlet application is different from that of a Java SE application. For example, to package a MIDlet application, you need a Java Application Descriptor (JAD) file. The JAD file is not required for packaging an application in Java SE.
Note : The JAR file format is used for combining many files into a single file. Creating a JAR file helps in easier handling and distribution of Java applications.
The building process of a MIDlet specifies various tasks that need to be performed to implement a MIDlet. To build a MIDlet, you need to perform the following tasks:
- Compile the MIDlet.
- Verify the MIDlet.
- JAR the MIDlet.
In addition to the preceding tasks, a MIDlet is obfuscated in order to reduce the size of the application.
Compiling the MIDlet
Compilation is the process of compiling the Java source files into executable byte code. The compiler of the virtual machine compiles the Java source code.
Verifying the MIDlet
Class file verification is the process of verifying all classes within a MIDlet suite to ensure that mobile applications do not perform incorrect operations. The class file verification for MIDlet suites is performed by the KVM in the following two phases:
- In-device verification The following figure shows how the KVM verifies the class files in a MIDlet.
Figure 1: Verification Process of a MIDlet
The preverification process is performed before a class file is loaded on a mobile device. The preverification process reduces the amount of work done by the mobile device. This is important because a mobile device has limited memory and cannot support complete verification of class files. In the preverification process, additional attributes are inserted in the class file by a software program called preverifier. These additional attributes help in describing the class as preverified. They also provide information that reduces the amount of time and memory necessary for the KVM to perform the verification. After the preverification process, the size of the class files becomes approximately 5% larger than its previous size.
The in-device verification is a verification process that is performed by the in-device verifier present in the KVM of the mobile device. When a mobile device loads a preverified class file, the in-device verifier verifies the syntax of the Java class files. When the in-device verifier finds an error in a class file, it reports the error and rejects the class file.
Jaring the MIDlet
In the jaring process, the MIDlets are packaged into a single JAR file. This JAR file includes all the class files, resource files, and manifest file of a MIDlet application. NetBeans performs the jaring process automatically when a project is built.
Obfuscating the MIDlet
The compiled class files of Java can be reverse engineered to produce the Java source files by using a tool called decompiler. This process is a threat to the Java source files. Obfuscation prevents this threat by preventing reverse engineering. In other words, obfuscation refers to the process of obscuring Java classes, making them difficult to decompile back into source code. Further, obfuscation also helps in reducing the size of the Java byte code of a MIDlet application. Obfuscation helps in reducing the time required to download the MIDlet application in a mobile device. It also helps in securing the Java source code of a MIDlet application. The obfuscation process removes information such as comments, line numbers, and local variable names present in the Java source files. After this information is removed, any attempt at reverse engineering is not successful. This is because the information that is derived after decompiling the Java source files becomes very difficult to understand.
Obfuscation also reduces the size of Java classes by removing additional information and replacing large identifiers. For example, obfuscation replaces the variable names and source file names with machine-generated names.
Running a Sample Program
Opening the Hello MIDlet
To open the Hello MIDlet, Steve needs to perform the following steps:
Select start->All Programs->NetBeans 6.0.1->NetBeans IDE to open the NetBeans IDE 6.0.1 window, as shown in the following figure.
Figure 2: Netbeans IDE 6.0.1 Window
Select File->New Project. The New Project dialogbox appears, as shown in the following figure.
Figure 3: New project dialog boxSelect the Mobility option from the Categories section. Ensure that the MIDP Application option is selected in the Projects section. Click the Next button. The Name and Location page is displayed, as shown in the following figure.
Figure 4: Name and Location Page
Type HelloWorld in the Project Name text box. Type <Drive Letter>:\JavaMEProjects in the Project Location text box.
Click the Next button. The Default Platform Selection page is displayed, as shown in the following figure.
Figure 5: The Default platform selection page
Click the Next button. The More Configurations Selection page is displayed, as shown in the following figure.
Figure 6: More configurations selection page
Click the Finish button. The HelloWorld -NetBeans IDE 6.0.1 window with the current status of the HelloWorld project appears, as shown in the following figure.
Figure 7: HelloWorld - Netbeans 6.0.1 Window
Running the Hello MIDlet
To run the Hello MIDlet, Steve needs to perform the following steps:
- Select Build->Build Main Project to build the HelloWorld project.
- Select Run->Run Main Project to run the HelloWorld project.
The DefaultColorPhone emulator window is displayed, as shown in the following figure.
Figure 8: DefaultColorPhone Emulator window
Click the soft key below Launch on the DefaultColorPhone emulator window to display the text Hello World! on the emulator screen, as shown in the following figure.
Figure 9: DefaultColorPhone Emulator Displaying the output
Select MIDlet->Exit to close the DefaultColorPhone emulator window. Select File->Exit to close the NetBeans IDE.
The availability of wireless Internet services on mobile devices such as mobile phones is making communication possible anywhere and at anytime. When connected to the Internet, the functionality provided by these mobile devices becomes seamlessly endless. Java is a very popular technology. It has been accepted as the de facto standard by the mobile industry for developing mobile applications. However, the standard edition of Java cannot be used for creating applications for mobile devices since it uses a lot of memory. Therefore, Sun Microsystems released Java ME for developing applications for resource-restricted devices. Java ME offers a flexible and robust platform for mobile application development with enterprise-class performance, reliability, and value.