Programming Java 2 Micro Edition for Symbian OS 2004 (779882), страница 13
Текст из файла (страница 13)
It specifies a framework with which programmers can create rich gaming applications. TheAPI has been designed to improve the performance of gaming applications on mobile devices that have, by definition, limited processorpower. Application size is greatly reduced because much of the coderequired to produce sprite animation has been wrapped within the API’sclasses.The API consists of five classes, which are as follows and will be givengreater attention in Chapter 3:• GameCanvas – a subclass of Canvas that provides the basic screenfunctionality for game developmentAs well as inheriting methods from Canvas, it also provides somegame-centric functionality, such as being able to query the currentstate of game keys, synchronous graphics flushing and an off-screengraphics buffer, which improve overall performance and simplifydevelopment.44GETTING STARTED• Layer – the visual element in a game such as a Sprite or aTiledLayer; it forms the basis for the Layer framework and affordsnecessary features such as location, size and visibility• LayerManager – an index of all the layers present in the gameIt provides the ability to create a ”view” or ‘‘viewport’’ to the game,which is useful when the developer is creating a large virtual world.
Asthe user navigates through the world, the LayerManager manageswhat should be seen at each particular moment. It then renders thatview to the display.• Sprite – a basic animated Layer that can display one of several framesThe really useful functionality of Sprite is that it creates a numberof equal-sized frames based upon the input of a Sprite film-strip,provided at creation. It therefore becomes self-aware and is able toprovide a custom or default sequential animation of all of its frames.Transformations may also be carried out and collision detectionmethods are available to simplify the development.• TiledLayer – a class that enables the developer to create a largearea of graphical content, without having to use the huge resourcesthat a large image would require.The TiledLayer consists of a grid of cells that can be populatedwith one of several small tile images.
In the Demo Racer application(see Chapter 5), we use a TiledLayer to create the background.These tiles are repeated across the screen to create a larger, screensized image. If, for example, we want some of these tiles to change wecould create dynamic cells to provide animation for a specific cell.For example, we may want to add a ”glaring sun” to the sky area ofthe screen.2.1.3 RMS StorageOne of the main problems for any application, especially in the enterprisesector, is the question of storing data after the application has been closed.MIDP applications may be used by sales people on the road, snapshotsof financial data may be downloaded via a secure server to the device orit may be that high scores for a game need to be stored.
Implementinga full-scale JDBC database on a small, constrained device would beadventurous, not to mention resource-draining on power and processor.However, at the other end of the scale the data cannot be written directlyto the device’s file system as this breaks the MIDP sandbox securitymodel. Therefore MIDP provides a simple record-based persistent storagemechanism known as the Record Management System (RMS). The RMSallows the MIDlet application to store persistent data within a controlledINTRODUCTION TO MIDP45environment, while maintaining system security.
It provides a simple,non-volatile data store for MIDlets while they are not running.The classes making up the RMS are contained in the javax.microedition.rms package. Essentially, the RMS is a very small, basicdatabase. It stores binary data in a Record within a RecordStore.MIDlets can add, remove and update the records in a RecordStore.The persistent data storage location is implementation-dependent and isnot exposed to the MIDlet.A RecordStore is accessible across all MIDlets within a suite, andMIDP 2.0 extends access to MIDlets with the correct access permissionsfrom other MIDlet suites.
However, when the parent MIDlet suite isremoved from the device, its recordstores are also removed regardless ofwhether a MIDlet in another suite is making use of them.The RMS recordstore is discussed in more detail in Chapter 3 and willalso feature in a couple of the case studies described in Chapter 5.2.1.3.1 Media API in MIDP 2.0MIDP 2.0 includes a small audio-only media capability, known as theMedia API. The Media API is a subset of the much richer optional J2MEMobile Media API (JSR 135).
The Mobile Media API does ship on someSymbian OS phones, such as the Nokia 3650 and Nokia 6600, but it isan additional API and not part of MIDP 2.0.The MIDP 2.0 Media API provides support for tone generation andaudio playback of WAV files if the latter is supported by the underlyinghardware. Since MIDP 2.0 is targeted at the widest possible range ofdevices, not just feature rich smartphones, the aim of the Media API isto provide a lowest common denominator functionality suitable for thecapabilities of all MIDP 2.0 devices.We will discuss programming the Media API and the Mobile MediaAPI in detail in Chapter 3.2.1.3.2 NetworkingIn Chapter 1 we looked at how the CLDC has defined a streamlinedapproach to networking, known as the Generic Connection Framework.The framework seeks to provide a consistent interface for every networkconnection between the MIDP classes and the underlying network protocols.
Every time a network connection is made, no matter what protocolis being used, the interface remains the same. To open a connection, thestatic open() method in the Connector class is used.In MIDP 1.0, the only protocol for which support was required wasHTTP. MIDP 2.0 has made many more protocols available, althoughHTTP and HTTPS are the only two mandatory protocols. The optionalprotocols include sockets, server sockets and datagrams.46GETTING STARTEDMIDP 2.0 adds an interesting new feature in the Push Registry. ThePush Registry maintains a list of incoming network connections registeredby MIDlets. When an incoming connection is received by the device alookup of the port and MIDlet name is performed.
If the MIDlet is notcurrently running then, if permitted by the security policy, the MIDlet willbe launched.Networking and the Push Registry will be discussed in more detail inChapter 3.2.2 Helloworld, Turbo EditionBy this stage in the book it is about time we started showing you somereal code. So let’s have a look at a sample application.Helloworld has been the stalwart for authors time and time againbecause it serves to show the developer the basics and is also simple toprogram. We thought, however, we might stretch the reader a little morehere. We want to give you something a little more useful, somethingthat serves to demonstrate some points already made and also illustratespoints we wish to make once we delve deeper into this book.This application is still called Helloworld, but the tag ”Turbo Edition”has been added to give it some glamour! Whereas previous Helloworldapplications have only really served to display some text on the screen,this version sets out to unlock some of the more useful additions includedin MIDP 2.0.
The Game API seemed the most likely candidate.2.2.1 OverviewAs has been outlined above, rather than recreate the wheel, we decidedthat it would be interesting to show what can be achieved by using theGame API and some sprite graphics. It was thought that the techniquesused here might serve as a splash screen, just to let the user know thateverything is well in the world and the application is loading. When itis running, the Symbian logo is displayed, before splitting into four (seeFigure 2.3).
The four pieces rotate and the display becomes ”Helloworld,Turbo Edition” (see Figure 2.4). The animation then runs in reverse.In addition to being a rather sophisticated animation, this demonstratesthe application lifecycle and what it really means for the developer. It alsoillustrates one of the basic principles of the Game API, sprite animation.So let’s have an initial look at what is actually inside it.This application is made up of four classes and one PNG formatgraphics file.
It has been tested using the Nokia 6600 and we did, ofcourse, use some of the tools outlined later in this chapter to achieve theend product.HELLOWORLD, TURBO EDITIONFigure 2.347Helloworld: Symbian.Figure 2.4 Helloworld: Turbo Edition.2.2.2 MIDlet Class: Helloworld.javaThis is the main class for the application. This class represents the MIDletlifecycle of the application.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
