Wiley.Games.on.Symbian.OS.A.Handbook.for.Mobile.Development.Apr.2008 (779888), страница 62
Текст из файла (страница 62)
Both Symbian and Nokia (who2www.forum.nokia.com/main/resources/tools and sdks/carbide/index.htmlWHAT ABOUT MIDP ON SYMBIAN OS?273implemented most of the optional JSRs on S60 handsets) were able torealize them as interfaces to native OS services which minimized thefootprint, while providing MIDP tight integration with the OS itself. Thisallows MIDP applications on Symbian OS to use the native widgets forthe UI and thus they can be hard to differentiate from C++ applications.This is great, as users often switch back and forth between multipleapplications, and they should maintain the same look and feel.Symbian OS is a full multi-tasking operating system, and the Java VMitself runs in a separate process in its own thread (the interpreter has itsown C++ thread where native interface code also executes).
In addition,there are several other native threads in the VM process and severalmore in the AMS. However, Java threads themselves do not use nativethreading – they are instead implemented by the virtual machine itself aslightweight threads in the CLDC HI.Another consequence is that, as a multi-tasking operating system,Symbian OS doesn’t need to automatically pause a ‘backgrounded’MIDlet (one that has been sent to the background). Depending on yourapplication this may or may not be a good thing.
As a game developer,you’ll certainly want to address this as best practice dictates, pausing yourgame loop and releasing as many resources as you can in this situation.Furthermore, this behavior is dictated by the Application ManagementSystem (AMS) which can be (and is) customized by licensees resulting invariance of behaviors between S60 and UIQ. We’ll discuss more on howto handle this and the MIDlet life cycle later.Other benefits Symbian OS offers in its MIDP implementation includea Canvas class that is double buffered by default, support for the nativecolor depth of the underlying platform, and a wide range of networkand push registry protocols.
Within the bounds of available resources,Symbian OS does not restrict the size of JAR files, the number of RMSrecords or their size, and you can create as many socket connectionsas you want. Further, you aren’t limited in how many Java threads youcan create and the VM supports a dynamic heap so it can grow to meetdemand. You need to keep that in mind when load testing your games asRuntime.freeMemory() will only return the instantaneous memorywith respect to the current size of the heap.All releases of Symbian OS starting with version 8.0 support thefull Mobile Media API (JSR 135) and natively support OpenGL ES 1.0.OpenGL ES forms an abstraction layer for the Mobile 3D GraphicsAPI (JSR 184), meaning that your MIDlets automatically benefit fromany hardware acceleration on the handset without your having to doanything.
This is way cool. And even though only a handful of Symbiansmartphones currently support hardware accelerated graphics, this is justthe start of a huge revolution in mobile applications and games.Symbian OS v9 has enhanced a number of existing APIs and addedmany more. The net result is a rich diversity of functionality optimized274MIDP GAMES ON SYMBIAN OSTable 9.1 Symbian OS API Support for the JavaME PlatformAPIJSRWeb Services172Security and Trust Services177SIP180Scalable 2D Vector Graphics226Location179File Connection & PIM75Mobile 3D Graphics184Mobile Media135Wireless Messaging120/205Bluetooth82Java Technology For TheWireless Industry (JTWI)185for performance and memory efficiency.
The latest Symbian smartphonessupport the APIs listed in Table 9.1.If you’re confused about the Wireless Messaging APIs (JSRs 120 and205), don’t be – you only need to know that JSR 205 is a superset of JSR120 and specifically adds programmatic support for MMS.One last point – one API that is notably absent from Table 9.1 isthe Java Binding for the OpenGL ES API (JSR 239). However it was onlyfinalized in September 2006, and, at the time of writing (September 2007),it is currently undergoing a maintenance review.
It is to be hoped that wewill see support for this in Symbian OS in the near future as well, since thisallows Java ME developers to code in the same immediate mode style usedin standard OpenGL ES. Consequently, porting native OpenGL/OpenGLES applications across to Java will be much easier as well.9.6 Pausing for BreathEven phones get tired. When power levels drop or memory becomesscarce, the operating system will sometimes direct the AMS to pause orPAUSING FOR BREATH275even stop and destroy a running MIDlet altogether.
Whether you like it ornot, any game you write is going to get backgrounded on a regular basis.This happens frequently in response to operating system events, otherapplications moving into the foreground, or incoming messages/phonecalls during game play. Sometimes it just happens accidentally becausethe player is unfamiliar with the phone’s abilities and interface. Howeverit happens, it’s going to happen.So, before you even consider how to start a game, think about how topause it and how to stop it.
This is really easy to get wrong, but with someplanning and design it’s actually quite easy to get it right, which directlyimpacts battery life and therefore game life. No-one wants to play a gamethat flat-lines their battery every time it’s accidentally left running in thebackground.By the nature of their ergonomics and the general use cases, mobilegames are often played in short bursts – sometimes less than a coupleof minutes – if that long.
As Chapter 1 described, research shows thata large proportion of users play mobile games for very brief spurts ofentertainment – usually while waiting for a bus, while waiting to buy acoffee, while standing in a queue, or even while waiting for their partnerto get ready to go out! Furthermore, it should be remembered that oftena game is paused by the player in response to a change in the player’ssurroundings – because they’ve just got on the bus, or entered a meeting, a lecture, or a job interview.
So pausing a game needs to do justthat – pause the game world entirely.This usage pattern is completely different to that of PC games, andtherefore we have to design the game architecture according to a differentperspective. A mobile game will be paused and resumed frequently andgiven the constrained nature of mobile devices, it’s important to makesure that the following steps are taken (in no particular order):• stop all non-essential threads – this generally refers to the game loopbut also includes timers and any other threads that the game uses.• release any non-essential resources – references to any large objects,cached game data, handles to the onboard camera(s) or the microphone, and so on• cease playing any video, sounds, and music• update the display to reflect that it is in a paused state• save the current game state.In fact so important is this approach, that Chapter 2 covers this in somedetail. The first two points above make sense for any mobile applicationnot just games, but the third point, to cease playing any audio or video,276MIDP GAMES ON SYMBIAN OSis an interesting one.
I have played more than one game that continuesto play tones or audio tracks even when in a paused state – which can bevery strange and results in a poor user experience.This is often because such games are designed for more mass marketdevices that do not support multi-tasking and it is assumed that a MIDletis either running or dead – so there is no concept of a ‘paused’ state.For example, on Nokia Series 40 devices, only one MIDlet can be activeat any one time, although a MIDlet can be backgrounded by a systemscreen (such as an incoming call dialog). However the AMS will not callany MIDlet life cycle methods when this occurs – although recent eventsindicate that Series 40 may soon allow the execution of multiple MIDletssimultaneously.As we have seen, this is not the case on Symbian OS.
A MIDlet that hasmoved to the background will continue to run, consuming clock cyclesof the processor, using resources, and draining the battery quite happilyunless told otherwise.It’s also important to think through the last two points in the listabove – what does a MIDlet display when paused, and how will a playerresume game play? How you choose to do this depends on the actualgame, but common techniques include displaying:• a separate pause menu with a pre-selected ‘Resume’ option• a ‘Paused’ caption over the top of a screen grab of the game worldtaken at the point where the game was paused• the main menu with a ‘Resume’ option added – which should be atthe top and pre-selected.If you do implement a separate pause menu, it’s also good practiceto include menu items for accessing the game settings and for exitingthe game altogether.
Players should be able to pause a game, disablevibrations, music, and sound effects via the settings screen, and thenresume play quickly and seamlessly in context with their surroundings.This is a real issue – a number of my friends have complained about beingcaught out in meetings because the game pause/resume cycle re-enabledsound effects and music without their realizing it (although they probablyshould have been working anyway). Many games do not handle pausingwell, which is why Forum Nokia has published a white paper devotedentirely to discussing how to do it.33The paper is called At The Core Of Mobile Game Usability: The Pause Menu and canbe found in the Usability section of the Forum Nokia website (www.forum.nokia.com/main/resources/documentation/usability/). The exact location of the paper has a URL whichis far too long to type in from a book, and is subject to change anyway, if the content isupdated in future.
We will keep a set of links to papers and resources that are useful togame developers on the Symbian Developer Network wiki (developer.symbian.com/wiki ).LIVING IT UP277MIDlet pause behavior is dictated by the application managementsystem (AMS) which is itself customizable. So it turns out that under S60,the AMS does not call pauseApp() on a MIDlet when it moves into thebackground, whereas on UIQ it does (or should).The best solution here is to ensure that all of your game loop pausecode is centralized in a method that can be called as required inresponse to a variety of events. This includes the AMS pausing theMIDlet via pauseApp() (if it does so), the MIDlet notifying the AMSthat it would like to be paused via notifyPaused() and finally byleveraging the Canvas.showNotify(), Canvas.hideNotify() andthe Displayable.isShown() methods.When resuming game playing, you can use the saved game state toquickly re-initialize all game data as required.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
