Programming Java 2 Micro Edition for Symbian OS 2004 (779882), страница 9
Текст из файла (страница 9)
Game play may be finished, for example, or theAMS may have decided that a process of a higher priority needsto claim the resources being used by the MIDlet.AMS invokes MIDletconstructorPAUSEDAMS invokes startAppACTIVEAMS invokes pauseAppAMS invokesdestroyAppAMS invokesdestroyAppDESTROYEDAMS reclaimsMIDletFigure 2.1State transition diagram of the MIDlet lifecycle.INTRODUCTION TO MIDP272.1.1.5 Example MIDletThe basic structure of a MIDlet is very simple.
As outlined earlier, thereis no static main method. The MIDlet is instantiated by the AMS, whichprovides the initial class for the MIDlet to initialize.The following skeleton code shows this basic MIDlet structure:import javax.microedition.midlet.*;public class MyMidlet extends MIDlet {public MyMidlet() {}public void startApp() throws MIDletStateChangeException {}public void pauseApp() {}public void destroyApp(boolean unconditional) {}}2.1.1.6 Creating MIDletsOnce the MIDlet has been created we are ready to compile, pre-verifyand package the MIDlet into a suite for deployment to a target device ora device emulator.CLDC provides a two-pass implementation of the bytecode verifier.Not only is the standard J2SE verifier bigger than the whole of a typicalCLDC implementation, it also requires over 100 KB of dynamic memoryfor a typical application.
CLDC therefore requires a pre-verifier, whichis typically run on the machine used to build the application, to carryout the space- and performance-intensive parts of verification. The preverifier annotates the bytecode so that all the client device has to do ischeck the results for correctness: the annotations cannot be spoofed andcode signing is not required. The on-device footprint is about 10 KB andrequires fewer than one hundred bytes of runtime memory. The downsideis a 5 % increase in class file size.Typically, compilation, pre-verification and packaging are automatedby tools, such as the KToolbar, available with Sun’s J2ME WirelessToolkit, as we will discuss later in this chapter.
The toolkits provide aninterface for the compiler, javac; pre-verification, preverify.exe;and the packaging tool, jar. These commands are also available on thecommand line (see Appendix 3).Once this process has been completed we are nearly ready to run theMIDlet suite. There is, however, one final task to complete: the creationof the application descriptor (JAD) file. This file is required to notify theAMS of the contents of the JAR file. The following attributes must beincluded in a JAD file:• MIDlet-Name – the name of the suite that identifies the MIDlets tothe user28GETTING STARTED• MIDlet-Version – the version number of the MIDlet suite; this isused by the AMS to identify whether this version of the MIDlet suiteis already installed or whether it is an upgrade, and communicate thisinformation to the user• MIDlet-Vendor – the organization that provides the MIDlet suite• MIDlet-Jar-URL – the URL from which the JAR file can be loaded;both absolute and relative URLs must be supported; the context forrelative URLs is from where the JAD file was loaded• MIDlet-Jar-Size – the number of bytes in the JAR file.It is also useful to include the following attributes in a JAD file:• MIDlet-n – the name, icon and class of the nth MIDlet in the JARfile (separated by commas); the lowest value of n must be 1 and allfollowing values must be consecutive; the name is used to identify theMIDlet to the user and must not be null; the icon refers to a PNG filein the resource directory and may be omitted; the class parameter isthe name of the class extending the MIDlet class• MIDlet-Description – a description of the MIDlet suite• MicroEdition-Configuration – the J2ME configuration required, in the same format as the microedition.configurationsystem property, e.g.
”CLDC-1.0”• MicroEdition-Profile – the J2ME profiles required, in the sameformat as the microedition.profiles system property, e.g.‘‘MIDP-1.0’’ or ”MIDP-2.0” depending on the version of MIDP againstwhich the MIDlet is built; if the value of the attribute is set to ‘‘MIDP2.0’’, the device onto which the MIDlet is to be installed mustimplement the MIDP 2.0 profile otherwise the installation will fail;MIDlets compiled against the MIDP 1.0 profile will install successfullyon a device implementing MIDP 2.0.The following represents a sample JAD file for a hypothetical applicationcalled ”MyMidlet”:MIDlet-1:MyMidlet, MyIcon.png, com.symbian.MyMidletMIDlet-Description: Example MIDP 2.0 MIDletMIDlet-Jar-Size: 3707MIDlet-Jar-URL: MyMidlet.jarMIDlet-Name: MyMidletMIDlet-Vendor: Symbian LtdMIDlet-Version: 2.0MicroEdition-Configuration: CLDC-1.0MicroEdition-Profile: MIDP-2.0Once the JAD file has been created the MIDlet is ready to be executed.The following command line is used to initiate the MIDlet within theemulator supplied with the Wireless Toolkit, via its JAD file.INTRODUCTION TO MIDP29C:\WTK20\bin>emulator Xescriptor:C:\WTK20\apps\Example\bin\MyMidlet.jadOf course, much of this is simplified if the developer uses the WirelessToolkit KToolbar application, which provides a convenient GUI to thesefunctions.
However, it may not always be possible to do this, especiallyin the case of Solaris and Linux machines.2.1.2 User InterfacesA user interface for mobile information devices would have provedsomething of a challenge for those sitting around the table during the earlystages of creating the MIDP 1.0 specification.
Confronted with a deviceof limited power, display and storage capabilities, those participants,including Symbian, who were a part of the Java Community Process forJSR 37 (MIDP 1.0) would have thought long and hard about how best totackle this problem.MIDP devices do, of course, pose quite a challenge for those taskedwith developing applications.
Much of the challenge in the applicationdesign is trying to create a sophisticated, productive application intuitiveenough for the enterprise user to grasp easily or engaging enough for thegamer. It must also be capable of running in a restricted environment.Java developers may at this point be asking themselves, ”I can see howmuch of the J2ME technology has been adapted or truncated from J2SE,so why not do the same with the user interface?” There are numerousreasons, many of which are concerned with the device paradigm itself.AWT was designed for desktop applications.
The desktop paradigmdraws upon inherited usage from other applications: the purpose and useof certain components, and the navigation between them, is understoodby the user and, therefore, doesn’t have to be re-learnt. It is also intuitive:more space allows the GUI to have fuller, more explanatory labels and apointer device provides a convenient way to initiate those commands.One of the main considerations for mobile applications has to beportability.
There are many different devices in the marketplace, all withdifferent screen sizes and keypads. Some have pointer devices, somehave joysticks and others have full keyboards. MIDP has had to cater forall these devices.Mobile devices do not have a great need for window management orre-sizing. Clearly an AWT-type interface would be overkill on a deviceso small. Features such as overlapping windows, toggling between formsand then resizing them would be wasted. Buttons are also placed inspecific places. The mobile UI needs to be more fluid and dynamic.Since much time has been spent by manufacturers testing out theirdevices on users, with focus groups, usability studies and other marketresearch, it would be a waste to then expect users to learn another30GETTING STARTEDmethod of entering and reading data from the device’s screen.
Rememberthe inherited knowledge a PC user gains from using the PC user interface?Well, the same applies to a mobile UI. The implementation of each of thehigh-level UI components is therefore left to the devices themselves andas a result the MIDP GUI (known as the LCDUI) was designed to takeinto account the following:• a portable user interface• a consideration of the form factor of small devices, the size of thescreen, the data input methods and the processor size: processingAWT objects and dealing with their garbage collection would not beappropriate for a constrained device• many people will use the devices while on the move or when notfully concentrating on the task in hand; many of the devices will beused with one hand, although some may use a pointing device• the UI of the applications should be comparable to the native applications on the device.2.1.2.1 Structure of the MIDP UI API and Class OverviewThe LCDUI is split into high-level and low-level APIs, both of which haveevent-handling capabilities.The high-level API is designed for applications that are required to beportable across many devices, regardless of screen size and input method.These applications can generally be aware of the device they are runningon and make adjustments accordingly.
A simple example of this wouldbe whether a pointing device was present or not. This set of classes hasa high level of abstraction and therefore the developer has little controlover the look and feel. More specifically, the programmer has no controlover the color, font and style of the components; scrolling and navigationof the on-screen image is left to the underlying implementation.Conversely, the low-level API provides very little abstraction and givesthe programmer precise control over where objects are placed on thescreen.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
