• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
J2ME Tutorial
 

J2ME Tutorial

on

  • 495 views

 

Statistics

Views

Total Views
495
Views on SlideShare
495
Embed Views
0

Actions

Likes
0
Downloads
14
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    J2ME Tutorial J2ME Tutorial Document Transcript

    • J2ME Tutorial J2ME Tutorial, Creating MIDletsJava 2 Micro Edition (J2ME) combines a resource-constrained JVM and a set of Java APIs fordeveloping applications for mobile devices. This article is the first in a series. This time, after aquick introduction to J2ME, I will provide a step-by-step guide to creating J2ME applications,also known asMIDlets, using a simple example. This will cover how to test and deploy theseMIDlets as well. Finally, I will round out this installment with a look at the lifecycle of a MIDlet.J2ME IntroductionWhat is J2ME? Cut away the hype and the excess fat and you are left with yet another (set of)Java APIs. Since these APIs cannot run on a traditional Java Virtual Machine (JVM), due to thelimited size of mobile devices in regards to memory and resource availability, J2ME defines alimited version of the JVM as well. In a nutshell:J2ME combines a resource constrained JVM and a set of Java APIs for developing applications formobile devices.Do you, as a developer, have to install this JVM and the APIs on mobile devices? No. Devicemanufacturers install and prepackage their devices with this JVM (and associated APIs). As adeveloper, you only need to develop applications targeting these devices and install them. Easiersaid than done!J2ME can be divided into three parts, as shown in Figure 1: a configuration, a profile, andoptional packages. A configuration contains the JVM (not the traditional JVM, but the cut-downversion) and some class libraries; a profile builds on top of these base class libraries by providinga useful set of APIs; and optional packages, are well, an optional set of APIs that you may or maynot use when creating your applications. Optional packages are traditionally not packaged bythe device manufacturers, and you have to package and distribute them with your application.The configuration and profile are supplied by the device manufacturers and they embedded themin the devices. Figure 1. The J2ME stackMr. Pritesh N. Patel ISTAR Page 1
    • J2ME TutorialThe most popular profile and configuration that Sun provides are the Mobile Information DeviceProfile (MIDP) and Connected Limited Device Configuration (CLDC), respectively. As the namesuggests, CLDC is for devices with limited configurations; for example, devices that have only128 to 512KB of memory available for Java applications. Consequently, the JVM that it providesis very limited and supports only a small number of traditional Java classes. (This limited JVM isactually called the KVM.) Its counterpart, the Connected Device Configuration (CDC) is fordevices with at least 2MB of memory available and supports a more feature-rich JVM (but stillnot a standard JVM).The MID profile complements the CLDC configuration very well because it minimizes both thememory and power required for limited devices. It provides the basic API that is used for creatingapplication for these devices. For example, it provides thejavax.microedition.lcdui package thatallows us to create the GUI elements that can be shown on a (limited) device running the MIDprofile on top of a CLDC configuration. Note that MIDP cannot be used with CDC devices. CDCdevices get their own set of profiles, like the Foundation and Personal profiles. However, I will notcover these profiles or the CDC here, and will concentrate on using MIDP and CLDC only.The latest versions of MIDP and CLDC are 2.0 and 1.1, respectively. Not many devices currentlysupport these versions, but the list is growing rapidly. Sun maintains a list of devices accordingto version.Acquiring and Installing the J2ME Development KitGetting started with developing applications (henceforth called "MIDlets") for the J2ME platformis easy. Although device manufacturers install and prepackage their devices with this JVM (andassociated APIs), you still need to install the J2ME Wireless Toolkit 2.2 on your developmentmachine. Before that, however, you must also have the Java Development Kit (JDK), version1.4.2 or greater, installed.Warning: I had problems getting the Wireless Toolkit to work properly with JDK 5.0. If you dontneed the latest features in version 5.0, it is best to stick to any 1.4.2 version. I have used 1.4.2_05for all examples in this series.You need this Toolkit because it contains tools that are important in generating MIDlets. ThisToolkit provides the development environment for the MIDP 2.0 and CLDC 1.1 (and for MIDP 1.0and CLDC 1.0, since these parameters are backwards compatible), and it provides the optionalpackages required for the optional libraries, like 3D and Mobile Media applications. Lastly, itprovides the ability to sign your MIDlets so that they can be authenticated before installation ona remote mobile device.Once you download the installation package for the Toolkit, install it in the directory of yourchoice. The default, on Windows, isC:WTK22, and this will be the installation directory for theexamples in this series as well. I will not explain the directories created under this folder justnow. Before I do that, let us try and understand the process of generating a MIDlet from scratch.Understanding the Process of MIDlet Creation--Without the ToolkitThere are seven steps in the creation of a MIDlet. These steps are: designing, coding, compiling,preverification, packaging, testing, and deployment. Some of these steps are not strictly MIDlet-centric (for example, every application needs to be designed, coded, and compiled), but we willcover them here because there are MIDlet-centric differences. The Toolkit abstracts a lot of thesesteps so that it is easier for you in the overall scheme of things. This is fine and dandy once youMr. Pritesh N. Patel ISTAR Page 2
    • J2ME Tutorialknow the process, but when you are only starting out, you really should be coding by hand,rather than using a sugar-coated abstraction.To ensure that we get a hands-on understanding of these steps, let us take the help of a simpleexample. We will create a MIDlet that, when executed, will print the current date and time on amobile device for a short time. Along with this in mind, keep Figure 2 handy to understand thesequence of these steps. Also, note that I will explain the lifecycle of MIDlets later. For themoment, lets get a simple MIDlet up and running, which will illustrate these steps. Figure 2. Steps to MIDlet creationStep 1: DesignMIDlets are different from other applications that you may have created, simply because MIDletsrun in an environment that is very different. There are several issues, not just those that aremost visible (for example, the interactivity of your MIDlet with the user), but others that impactits usability.For the example application, our Date-Time MIDlet does not need user interactivity. It needs todisplay the current date and time for a few seconds when the user executes the MIDlet. Forsimple cases like this, it is perhaps sufficient to mimic the design of the MIDlet by drawing it ona piece of paper. For more complex designs with multiple screens, it is best to design the screensprofessionally before starting the actual coding process.Step 2: CodeEach MIDlet must extend the abstract MIDlet class found inthe javax.microedition.midlet package, much like creating an applet by extendingthe java.applet.Applet class. At the minimum, your MIDlet must override three methods of thisabstract class, startApp(), pauseApp(), and destroyApp(boolean unconditional). Here isthe DateTimeApp class:package com.j2me.part1;import java.util.Date;import javax.microedition.lcdui.Alert;import javax.microedition.lcdui.Display;import javax.microedition.midlet.MIDlet;Mr. Pritesh N. Patel ISTAR Page 3
    • J2ME Tutorialpublic 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) { }}In this example, DateTimeApps constructor creates the element that is necessary to display thetime on a devices screen and thestartApp method does the actual task of displaying thiselement. Dont worry if you dont understand how the Alert element works, or when theconstructor or the other methods are called. I will cover the former in the next part, when welook at the GUI elements of MIDP 2.0, and the latter later in this article in the MIDlet Lifecyclesection.Copy this code into a file called DateTimeApp.java and save it in a folder that mimics its packagestructure (comj2mepart1). You can save it anywhere you want on your machine; as far as thisarticle is concerned, we will save it in the folderC:WTK22articlecomj2mepart1.Step 3: CompileWith this simple code in place, you now need to know how to compile it so that it is ready formobile devices. Compiling MIDlets is not very much different from compiling normal Javaapplications. You still use javac as the compiler, except you need to change theboot CLASSPATH while compiling MIDlets. This has the effect of changing the base Java classesthat the Java compiler uses to compile your MIDlet against, thereby ensuring that compilation istargeted towards the narrow set of Javas APIs for the J2ME platform. So instead of compilingagainst the java.lang.Date in "normal" Java, you actually want compilation done forJ2MEsjava.lang.Date. This is done by pointing to the CLDC and MIDP classes for javacs -bootclasspath option while compiling. This is shown below for the DateTimeApp MIDletcompilation. To do this compilation, make sure you that you enter the command by navigating tothe directory C:WTK22article via the command prompt.C:WTK22article>javac -bootclasspath ..libcldcapi11.jar;..libmidpapi20.jarcomj2mepart1DateTimeApp.javaNotice that I have done the compilation against the CLDC APIs 1.1 and MIDP APIs 2.0 versions,respectively, by including these libraries in the bootclasspath option. I could have done thecompilation against other versions if it was required, by simply pointing to their respectivelibraries.Mr. Pritesh N. Patel ISTAR Page 4
    • J2ME TutorialStep 4: PreverifyBefore you can deploy your MIDlet class, it needs to be preverified. Verification of byte code is astep performed by the JVM before it runs any class file to ensure that the class file isstructurally and conceptually correct as per the JVM specification. If the class file fails thischeck, it is rejected and the JVM shuts down, indicating either security or integrity violation ofthe class file. This verification is done by all JVMs, even the tiny JVM contained in a CLDCconfiguration 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 cannothandle (or should not handle). Therefore, the need for preverification.Preverification is one part of a special two-step verification process, especially designed forconstrained devices, such as the ones running CLDC-based JVMs. The idea is to let a developerpreverify his classes, which limits the amount of work needed to be performed when the classesare verified in the device. This preverification process adds special information to the classes thatidentifies them as preverified and makes the process on the device much more efficient.Keeping this in mind, preverify your Date-Time MIDlet. The Wireless Toolkit comes with apreverification tool in the bin folder of its installation (C:WTK22bin). The following command,when executed from C:WTK22article, will preverify the DateTimeApp.classcreated in theprevious step.C:WTK22article>..binpreverify.exe -classpath ..libcldcapi11.jar;..libmidpapi20.jarcom.j2me.part1.DateTimeAppBy default, the preverifier will create the preverified version of your DateTimeApp.class file in afolder called output in the current directory. It will preserve the package structure, so yourpreverified class will now be in the folderC:WTK22articleoutputcomj2mepart1. You can, ofcourse, point the output to another folder, using the -d option for the preverify tool, but for themoment, use the default output folder.Step 5: PackagePackaging your MIDlet so that it ready for testing and deployment is a fairly involved process,with several steps. Although each step is straightforward, they must be followed in propersequence.The first step is to create a Manifest file. This Manifest file describes the contents of the JavaArchive (JAR) file that we will be creating in the next step. There are several attributes that cango in this file, but for your Date-Time MIDlet, stick to only the ones that are required. This filescontents are shown here:MIDlet-Name: DateTimeAppMIDlet-Version: 1.0.0MIDlet-Vendor: Vikram GoyalSave this file as Manifest.mf in the C:WTK22articleoutput folder. (Note the newline after thelast attribute, MIDlet-Vendor. Itmust be present, otherwise this attribute will not be recognized.)Mr. Pritesh N. Patel ISTAR Page 5
    • J2ME TutorialNext, create the JAR file that packages up the preverified DateTimeApp.class file and theManifest file. To create this JAR file, navigate to the C:WTK22articleoutput directory and issuethe following command:C:WTK22articleoutput>jar cvfm DateTimeApp.jar Manifest.mf .comThis will create the DateTimeApp.jar file in the current (C:WTK22articleoutput) folder.The second-to-last step is to create a file that has an extension of .jad. A Java ApplicationDescriptor (JAD) file points to the location of the MIDlet it describes so that a J2ME device caninstall it. Again, this file can contain several attributes for a single MIDlet (or for several MIDlets),but for your Date-Time MIDlet, you will stick with the ones that are required.MIDlet-1: DateTimeApp, , com.j2me.part1.DateTimeAppMIDlet-Name: DateTimeAppMIDlet-Version: 1.0.0MIDlet-Vendor: Vikram GoyalMIDlet-Jar-URL: DateTimeApp.jarMIDlet-Jar-Size:MicroEdition-Profile: MIDP-2.0MicroEdition-Configuration: CLDC-1.1Save this file as DateTimeApp.jad in the same folder as the JAR file (C:WTK22articleoutput). Iwill explain the attributes in this file later, but for now, 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, inactual bytes. It is very important to get this exactly right, as the installation of this MIDlet willfail if this value is different from the actual size. On my machine, this value is 1469 bytes, andtherefore, this is what this attribute looks like on my machine:MIDlet-Jar-Size: 1469This completes the packaging part. Well, actually, there are other steps in the packaging that Icould talk about (for example, signing and obfuscation), but to keep things simple, I will leavethose steps for later discussion. For now, you will move on to testing of your MIDlet.Step 6: TestBefore deploying your MIDlets, they must be tested by using a base common emulator devicethat mimics the functionality of an actual device on your computer. This emulator is part of theWireless Toolkit and provides functionality that is sure to be present in the majority of devicesfor which the MIDlet is targeted. This emulator is present in the bin folder of the Toolkit.From the output directory created in the preverify step earlier, and where we now have apackaged MIDlet in the form of JAR and JAD files, issue the following command to run theemulator with this JAD file as an option.C:WTK22articleoutput>....binemulator.exe -Xdescriptor DateTimeApp.jadMr. Pritesh N. Patel ISTAR Page 6
    • J2ME TutorialYou should see the emulator pop up on your screen as shown in Figure 3, with the DateTimeAppMIDlet selected. If it doesnt, the most likely error at this point would be incorrect JAR sizeinformation. Make sure you have the exact size listed in the JAD file. Figure 3. Testing the DateTimeAppAt the lower right-hand corner of the emulated devices screen, you can see the "Launch" menuitem listed. The emulator has installed the MIDlet and is ready to launch it. Click on the phonebutton just underneath that menu item and the MIDlet should display the current date time fora few seconds and then disappear. Note that the MIDlet is still running even after the date andtime disappear, because in code, you did not destroy it.Step 7: DeployThis is it! Now you have reached the stage where you can deploy the MIDlet directly on yourmobile device. There are two ways to do this. The first is via a network connection between yourcomputer and your handset. This can either be via a USB cable or a Bluetooth wirelessconnection, depending on your device. Most Java-enabled devices will allow you to install J2MEapplications via this connection.Second, and the one that is more interesting, because it opens up your MIDlet to the outsideworld, is via the Internet. After all, what good is your MIDlet if the rest of the world cannot see it?Of course, this means that your device should be able to connect to the Internet using itsinternal browser.Before you proceed further, recall that when you created the JAD file, you entered two attributesin 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 shouldtheoretically 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 theJAD file restricts these versions to the newer ones, devices will fail to install this MIDlet if theyMr. Pritesh N. Patel ISTAR Page 7
    • J2ME Tutorialdo not support these new versions. If this is the case with your device, fear not! As I said before,because we are not using any MIDP-2.0- or CLDC-1.1-specific features, you can simply changethese version numbers in the JAD file, and this will be sufficient to install this device on allJava-enabled devices. If this is the case with your device, or the device that you are going to testthis MIDlet on, simply change these values in the JAD file and you are good to go.To be able to deploy your MIDlet via the Internet, you need to have access to a web server with areal-world IP address or domain name. You also need to have administrative privileges to be ableto modify the configuration files of your web server to add some Multipurpose Internet MailExchange (MIME) types for the JAD and JAR extensions. If you are using Jakarta/Tomcat asyour web server, you dont need to do this, as it already has these MIME types. For the Apacheweb server, modify the mime.types file and add the following extension types.text/vnd.sun.j2me.app-descriptor jadapplication/java-archive jarBy adding these MIME types, you are informing the browser, or any client accessing these filesfrom 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 pageprovides a point of reference, and therefore, lets create one for your Date-Time MIDlet. TheHTML doesnt need to be anything fancy. Dont forget that users will be accessing this page via amobile device, so it is prudent to keep the size of this page to the minimum. This is shown inListing 2.<HTML> Click <a href="DateTimeApp.jad">here</a> to download DateTimeApp MIDlet!</HTML>Listing 2. DateTimeApp.html page for accessing the DateTimeApp MIDletThe page provides a link to the JAD file, and the JAD file provides a link to the associated JARfile via the MIDlet-Jar-URL: DateTimeApp.jar attribute. However, since this is now going to beaccessed via a web server over the Internet, it is advisable to make this link absolute instead ofrelative. (The behavior of relative URLs is inconsistent as far as MIDlet access is concerned.)Since I am going to serve this MIDlet via a web site (Craftbits.com) I manage, I have modified thislink to an absolute URL using this web site.MIDlet-Jar-URL: http://www.craftbits.com/j2me/DateTimeApp.jarYou will, of course, need to change this URL to your own domain.Finally, upload the modified JAD file, the newly created HTML file, and the original JAR file toyour web server to a directory location where you will be able to navigate to the HTML page viayour mobile device browser. Now, anyone with a mobile device that can browse the Internetshould be able to point to your DateTimeApp.html file and download, install, and run theDateTimeApp MIDlet.Mr. Pritesh N. Patel ISTAR Page 8
    • J2ME TutorialFor those who dont have access to a web server, I have uploaded these files to my web server.Simply point tohttp://www.craftbits.com/j2me/DateTimeApp.html through your device and youwill be able to see this MIDlet in action.Thats it! You have completed all the steps required to manually create and deploy a MIDlet. Thisprocess has helped you to understand what goes on behind the scenes and given you confidencein all the steps of MIDlet creation. Because a lot of these steps are repetitive, it makes sense touse an automated tool. This is where the Wireless Toolkit comes in, and you will use it to createthe rest of the MIDlets in this article series. For the moment, lets recreate the same MIDlet usingthis Toolkit so that you can get familiar with its interface.Understanding the Process of MIDlet Creation--Using the ToolkitIn the section Acquiring and Installing J2ME Development Kit above, you downloaded the Toolkitand installed it in the folderC:WTK22 (as far as this article series is concerned; you may havedownloaded and installed it in a different folder). Lets explore the contents of this folder. Figure4 shows these contents as they should now look on your machine. Figure 4. Wireless Toolkit folder contentsNote that the default installation of the Toolkit would not have created the article folder, and thatyou created it in the previous section.As far as a MIDlet developer is concerned, the most important folders arethe apps and bin folders, but here is a short summary of each of these folders. Folder Folder Description Name Directory that acts as a simulation for mobile device appdb file system MIDlets created using the Toolkit reside in this apps directoryMr. Pritesh N. Patel ISTAR Page 9
    • J2ME Tutorial Contains executables for the various tools, including bin the Toolkit itself, and various other tools like the preverifier and the emulator The Wireless Toolkit documentation including API docs documentation for MIDP 2.0 and MIDP 1.1 Contains the JAR files for MIDP (both 2.0 and 1.1), lib CLDC (both 1.1 and 1.0) and several other optional libraries Directory where network and profiling sessions are sessions maintained Contains the libraries for the Toolkit itself, including wtklib the properties of various device emulatorsThe apps folder is the directory where all the MIDlets that are created using the Toolkit areinstalled. Browse this folder, and you will notice several example MIDlets provided in their ownfolders. These have their own directory structure that allows clean separation of source code,libraries, and rest of the files associated with a MIDlet project.The bin folder contains the executables for the Toolkit. The most important oneis ktoolbar.exe (on Windows), which starts the main interface window for the Toolkit. This foldercontains other executables as well, some of which we came across earlier (forexample, preverify.exe and emulator.exe). Let us, however, concentrate on using the Toolkit nowby running thektoolbar.exe from the bin folder. The Toolkit will start and you will get the windowshown in Figure 5. Figure 5. Main Toolkit windowMr. Pritesh N. Patel ISTAR Page 10
    • J2ME TutorialAs the message in the window says, from here, you can either create a new project or open anexisting one. When you click on the Open Project menu button, you will be presented with a listof projects. As you may have guessed, this list of projects is the directory listing ofthe apps folder. Selecting a project from this list will open up the project and allow you to changeits settings, build it (which includes compilation, preverification, and packaging) and run it. Thesteps of designing and coding are still to be done outside of this Toolkit.Lets use the Toolkit to create the Date-Time MIDlet from the previous section. Click on NewProject menu button, and enter the details in the window that comes up, as shown in Figure 6. Figure 6. Creating a new projectThe next window that comes up will allow you to change settings that control the target platformof your MIDlet. In this case, you want to target this MIDlet towards the MIDP 2.0 and CLDC 1.1platforms and therefore, keep the Target Platform as JTWI, which preselects the MIDP 2.0Profile. However, you will need to change the Configuration to CLDC 1.1 and uncheck theOptional Mobile Media API library, as shown in Figure 7. Figure 7. Changing project settingsMr. Pritesh N. Patel ISTAR Page 11
    • J2ME TutorialYou can review the rest of the settings by clicking on the tabs at the top, but for the moment,your project is ready to be created. Do so by clicking the OK button at the bottom. The projectwill be created with information about where to place the project files displayed on the screen, asshown in Figure 8. You can verify that the Toolkit has created a DateTimeApp folder underthe appsfolder by navigating to it. Figure 8. Project DateTimeApp createdYou have already created the only required src file for this MIDlet in the previous section. Copythis file, DateTimeApp.java, from the folder C:WTK22articlecomj2mepart1 to the fullyqualified src folder (C:WTK22appsDateTimeAppsrccomj2mepart1). Note that the Toolkitcreated the fully qualified path based on the package name, so you dont have to. Once the copyis done, come back to the Toolkit, and hit the Run menu button. The Toolkit will compile,preverify, and package, and, provided everything goes OK, will run the DateTimeApp in theemulator. Seems simple enough, doesnt it? All you had to do was to create a new project, set thesettings, write the code, drop it in the right directory, and hit the Run button. The Toolkit tookcare of the rest.Before you leave this section, examine the rest of the folders under the DateTimeApp project.The bin folder under theDateTimeApp folder contains the JAD and the Manifest files, whilethe classes folder contains compiled classes. But where is the JAR file for this MIDlet? Well, theJAR file is not created by just running (or building) your application in the Toolkit. To create theJAR file, you will need to select the Project menu item, and then select one of the options underthe Package submenu, as shown in Figure 9. Figure 9. Creating the MIDlets JAR fileMr. Pritesh N. Patel ISTAR Page 12
    • J2ME TutorialBy creating this package, the JAR file will be created, with correct Manifest information in theJAD file. You can even create the HTML file that we created in the deploy section previously, byclicking on the Run via OTA (Over The Air) menu. This will not only allow you to simulate youremulator running this MIDlet via the Internet, but also create the HTML file for you inthe bin folder. Before you can use this HTML file to deploy on your own server, along with theJAD and the JAR files, you will need to change the hostname, which defaults to "localhost."You now know how to create a simple MIDlet, both using the Toolkit, and without it. Its nowtime to look at the MIDlet lifecycle to understand what actually happens when your MIDlet isdeployed and run.The MIDlet LifecycleMobile 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 beresponsible for installing and removing a MIDlet, as well.) To facilitate this management, aMIDlet can be in one of three states which is controlled via the MIDlet class methods, that everyMIDlet extends and overrides. These states are active, paused and destroyed. Figure 10. The possible states of a MIDlet and the transition between themAs you can see from Figure 11, an installed MIDlet is put into a paused state by the AMScreating an instance of it, by calling its no-args constructor. This is of course, not the only waythat the MIDlet can be in a paused state. It can enter this state when the AMS callsthe pauseApp() method on an active MIDlet (and the method returns successfully). It can alsoenter this state when the MIDlet pauses itself by calling the notifyPaused() method, as opposedto the pauseApp() method, which is called by the AMS. However, what exactly is happening withthe MIDlet in the paused state?In a paused state, the MIDlet is waiting for a chance to get into the active state. Theoretically, inthis state, it should not be holding or using any of the device resources and should be passive innature. Once the MIDlet is created, this is the state to be in before becoming active. Also,entering the paused state is necessary when the device requires it to consume fewer resources,Mr. Pritesh N. Patel ISTAR Page 13
    • J2ME Tutorialbecause these resources may be required for handling other device functions, like handling anincoming call. This is when the device invokes the pauseApp() method through the AMS. If theMIDlet should inform the AMS that it has paused, it should invoke thenotifyPaused() method,which tells the AMS that the MIDlet has indeed paused.One final way in which a MIDlet can get into a paused state is when theMIDlets startApp() method, which is called when the AMS invokes it to start the MIDlet (eitherthe first time or from a paused state), throws a MIDletStateChangeException. Essentially, in caseof an error, the MIDlet takes the safe road of staying in the paused state.The active state is where every MIDlet wants to be! This is when the MIDlet can do its functions,hold the device resources and generally, do what it is supposed to do. As said previously, aMIDlet is in an active state when the AMS calls the startApp() method on a paused MIDlet(actually, the MIDlet enters the active state just before this method is called by the AMS). Apaused MIDlet can request to go into the active state by calling the method resumeRequest(),which informs the AMS that the MIDlet wishes to become active. The AMS may of course, chooseto ignore this request or, alternatively, queue it if there are other MIDlets requesting the same.The destroyed state is entered when a MIDlets destroyApp(boolean unconditional) method iscalled and returns successfully, either from an active or paused state. This method is called bythe AMS when it feels that there is no need for the MIDlet to keep running and is the place theMIDlet may perform cleanup and other last minute activities. The MIDlet can enter this stateitself, by calling the notifyDestroyed() method, which informs the AMS that the MIDlet hascleaned up its resources and is eligible for destruction. Of course, since in this case,the destroyApp(boolean unconditional) method is not called by the AMS, any last-minuteactivities must be done before this method is invoked.What happens if the AMS calls the destroyApp(boolean unconditional) method in the middle ofan important step that the MIDlet may be doing, and may be loath to be destroyed? This iswhere the Boolean unconditional flag comes into the picture. If this flag is set to true, the MIDletwill be destroyed, irrespective of what the MIDlet is doing. However, if this flag is false,effectively, the AMS is telling the MIDlet that it wants the MIDlet to be destroyed, but if theMIDlet is doing something important, it can raise aMIDletStateChangeException, and the AMSwill not destroy it just yet. However, note that even then, there are no guarantees that the MIDletwill not be destroyed, and it remains up to each device to decide how they should handle therequest. If the device does honor the MIDlets request, it may try and invokethe destroyApp(boolean unconditional) at a later stage.Note that a destroyed state means that the MIDlet instance has been destroyed, but notuninstalled from the device. The MIDlet remains installed in the device, and a new instance of itmay be created later.Let me end this section, and this article, with a flow chart of a typical sequence of events whileusing the DateTimeApp MIDlet that we created in the previous sections, and the correspondingAMS actions and MIDlet states. This flow chart is shown in Figure 11.Mr. Pritesh N. Patel ISTAR Page 14
    • J2ME Tutorial Figure 11. AMS actions and MIDlet states through a sequence of eventsMr. Pritesh N. Patel ISTAR Page 15