Programming Java 2 Micro Edition for Symbian OS 2004 (779882), страница 8
Текст из файла (страница 8)
Symbian recognized the strength of theMIDP movement by including J2ME CLDC/MIDP 1.0 as its standardJava offering in Symbian OS Version 7.0, released in 2002, as well asback-porting the technology to earlier versions. Currently, all SymbianOS phones available in Western markets support at least MIDP 1.0.Although MIDP 1.0 generated considerable enthusiasm amongst thewireless Java community, it was also realized that MIDP 1.0 on itsown was limited in its capabilities to access the functionality offered bya typical smartphone from within a MIDlet. Consequently, soon afterthe release of MIDP 1.0, the wireless Java community started work onenhancing the capabilities of MIDP.
This has manifested in MIDP 2.0(JSR 118), released in its final form in November 2002, and a range ofextension API JSRs, all forming part of the Java Community Process.These developments provide a substantial increase in the functionalityavailable to MIDlets. As a consequence, the latest release of SymbianOS (Version 7.0s) and UIQ 2.1 move to a single Java technology streambased on J2ME CLDC and MIDP 2.0 (plus additional optional J2ME APIs).J2ME MIDP is now established as the ubiquitous Java platform in themobile phone arena and, as such, Symbian will continue to evolve andenhance its CLDC/MIDP offering. For more insight into future developments of J2ME on Symbian OS, including Symbian’s position with regardto CDC-based technologies, the reader is referred to Chapter 8.22INTRODUCTION TO J2ME1.5 SummaryThis chapter has introduced the J2ME architecture in order to indicatethe position of MIDP 2.0 within that structure.
We have examined thevarious configurations and profiles and shown why they are necessary inproviding a structure for the various needs and requirements of a J2MEdevice now and in the future. We have outlined the packages and classesof CLDC 1.0 and MIDP 2.0 to show their core functionality and have alsoshown how J2ME and Symbian sit together.In Chapter 2 we are going to examine MIDP 2.0 in more depth, startprogramming a simple MIDP 2.0 application and look at the some of thevarious tools on offer.2Getting Started2.1 Introduction to MIDPIn the previous chapter we examined the core MIDP functionality andoutlined the CLDC and MIDP classes that form the development environment.
Before we start writing our first piece of code, we need tolook at the basic concepts of MIDP, the most commonly used packagesand methods, and how it all fits together. We’ll also look at the variousdevelopment options, what they can do, and how they are installed.MIDP allows the execution of multiple MIDP applications, known asMIDlets. The model defines how the MIDlet is packaged, what runtimeenvironment is available, and how it should behave with respect to the,sometimes, constrained resources of the MIDP device. The model alsodefines how MIDlets can be packaged together in suites and share oneanother’s resources, such as graphics and data stored in the small databasefacility known as the RMS.
Each MIDlet suite also has a descriptor filecalled the JAD file, which allows the application management softwareon the device to identify what it is about to install prior to installation.The model also defines a lifecycle for a MIDlet, which allows for orderlystarting, stopping and cleanup of a MIDlet.2.1.1 The MIDP Model and LifecycleThe MIDlet forms the application framework that executes on CLDCdevices under the Mobile Information Device Profile (MIDP).
Everyapplication must extend the MIDlet class found in the javax.microedition.midlet package. The application management software(AMS) manages the MIDlet itself. The AMS is a part of the device’soperating environment and guides the MIDlet through its various statesduring the execution process. Unlike desktop or server applications,MIDlets should not have a public static void main() method. IfProgramming Java 2 Micro Edition on Symbian OS: A developer’s guide to MIDP 2.0. Martin de Jode 2004 Symbian Ltd ISBN: 0-470-09223-824GETTING STARTEDone is found then the AMS ignores it. MIDlets are initialized when theAMS provides the initial class needed by CLDC to start the MIDlet.
TheAMS then guides the MIDlet through its various changes of state. Weshall look at these states next.2.1.1.1 MIDlet StatesOnce a MIDlet has been instantiated, it resides in one of three possiblestates. A state is designed to ensure that the behavior of an applicationis consistent with the expectations of the end-users and device manufacturer. Initialization of the application should be short; it should bepossible to put an application in a non-active state; and it should alsobe possible to destroy an application at any time. Therefore, three validMIDlet states exist:PAUSEDThe MIDlet has been initialized, but is in a dormant state. This state isentered in one of four ways:• after the MIDlet has been instantiated by the AMS invoking its constructor; if an exception occurs, the DESTROYED state is entered• from the ACTIVE state, if the pauseApp() method is called by theAMS• from the ACTIVE state, if the startApp() method has been calledbut an exception has been thrown• from the ACTIVE state, if the notifyPaused() method has beeninvoked and successfully returned.When a well-written MIDlet is paused, it should generally release anyshared resources.ACTIVEThe MIDlet is functioning normally.
This state is entered after the AMShas called the startApp() method. The startApp() method can becalled on more than one occasion during the MIDlet lifecycle.DESTROYEDThe MIDlet has released all resources and terminated. This state, whichcan only be entered once, is entered for the following two reasons:• the destroyApp(boolean unconditional) method has beencalled by the AMS and returned successfully; if the unconditionalargument is false a MIDletStateChangedException may beINTRODUCTION TO MIDP25thrown and the MIDlet will not move to the DESTROYED state; theimplementation of the destroyApp() method should release allresources and terminate any running threads• when the notifyDestroyed() method successfully returns; theapplication should release all resources and terminate any runningthreads prior to calling notifyDestroyed().2.1.1.2 MIDlet Lifecycle MethodsThe javax.microedition.midlet.MIDlet abstract class definesthree lifecycle methods:• pauseApp() – this method is called by the AMS to indicate to theMIDlet that it should enter the PAUSED state, releasing all sharedresources and becoming passive• startApp() – this method is invoked by the AMS to signal to theMIDlet that it has moved from the PAUSED to the ACTIVE state.
Theapplication should acquire any resources it requires to run and thenset the current display• destroyApp() – this method is called by the AMS to indicate to theMIDlet that it should enter the DESTROYED state; all persistent andstate data should be saved and all resources that have been acquiredduring its lifecycle should be released at this point; generally, awell-written MIDlet will start up in the state it was in prior to beingshut down.2.1.1.3 Notifying and Requesting the AMSThe AMS manages the MIDlet suite installation and lifecycle.
There area number of methods that the MIDlet may use to notify the AMS of thestate it is in:• notifyDestroyed() – the MIDlet notifies the AMS that it hasreleased all resources held during execution, moved into theDESTROYED state and may be reclaimed by the system• notifyPaused() – the MIDlet notifies the AMS that it has movedinto the PAUSED state, releasing any shared resources it held• resumeRequest() – a paused MIDlet asks the AMS to be startedagain• getAppProperty() – provides a MIDlet with a mechanism toretrieve named properties from the AMS.26GETTING STARTED2.1.1.4 The Lifecycle ModelThe various states of the MIDlet (see Figure 2.1) show how the AMS andthe MIDlet interface combine to form the lifecycle of the MIDlet:1.The AMS creates a new instance of a MIDlet. The MIDlet’s constructoris called with no argument and the application is put into the PAUSEDstate.
If any exception is thrown during this phase then the applicationis put into the DESTROYED state.2.The AMS calls startApp() to move the MIDlet into the ACTIVEstate. The MIDlet itself will at this point acquire any resources itneeds and begin executing.3.Once the application is running, the MIDlet can move to two otherstates:• the MIDlet can be put into the PAUSED state by a call from theAMS to the pauseApp() methodThe MIDlet will cease to be in the ACTIVE state and choose torelease some of the resources it currently holds. If the programmerrequires the MIDlet to pause, then the MIDlet should first releaseshared resources (possibly stopping any running threads) and thencall the notifyPaused() method.• the MIDlet can move to the DESTROYED stateThe user or the AMS decides that the application no longer needsto be running.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
