Wiley.Games.on.Symbian.OS.A.Handbook.for.Mobile.Development.Apr.2008 (779888), страница 69
Текст из файла (страница 69)
In the AppParam field (see Figure 10.6), type ‘/i 0’ or ‘/i 1’ toset the irritation level to ‘Basic’ or ‘Really’ respectively.Figure 10.6Editing the ADF with the DoJa toolkitThe ADF is where the metadata for the i-appli is defined and it islocated in the project bin directory. For the example above, this file iscreated by the tool and is called Irritant.jam.
This is analogous tothe JAD file in Java ME applications. There are a large number of fieldsthat can be set, most of which are optional.Some of the more useful ADF parameters are defined in Table 10.3.Most of these exist for security reasons and the default behavior ofthe framework is to prevent application launch altogether if any fieldscontain invalid values. For a complete list of ADF parameters, refer to thedevelopment kit user guide.Okay, that about covers as much of the high level side of the APIas we need to. There’s obviously a lot more, but it’s more relevantto GUI application development for thick mobile clients than it is togame development.
Anyone with any experience of Java AWT or the310GAMES IN JAPANTable 10.3 ADF parametersParameterDescriptionPackageURLThe URL for the application binary. Communication bythe application is only possible to the host and portdefined here.AppSizeJAR size in bytes. Set during compilation.SPsizeSize of the Scratchpad in bytes. The maximum value hereis device dependent.AppParamStart up parameters.UseNetworkSpecifies if network communication is used.
The onlyvalid value here is the string ‘http’.UseSMSFlags use of SMS. Either left blank or the string ‘Yes’.LaunchBySMSIf MSISDN is set here application launch via SMS ispermitted.LaunchAtUsed when applications need to be launchedautomatically at regular intervals. Format is I h where his the interval in hours.javax.microedition.lcdui packages from Java ME should havelittle problem working the rest out.10.5Porting MIDP to DoJaIn general, a game port from MIDP 2.0 to DoJa is pretty straightforwardtechnically.
Just how difficult this conversion process will be depends onthe particular game and the functionalities it uses. A game that is largelydependent on CLDC classes as well as those in the low-level APIs onlywill be easier to port than one that leverages Bluetooth for multiplayernetworking.However it’s all Java, and there is a significant amount of overlapbetween the low level APIs most relevant to game development, soworking with the Graphics, Canvas, and Sprite classes is fairlyeasy. Double buffering is supported by default, but clipping, off-screenbuffers, and partial drawing via regions isn’t.
Media support is differenttoo: GIF and JPEG formats for images and, for audio, the Standard MIDIFile (SMF) format is supported on all handsets and MFi format support ison most. It should also be apparent by now that any socket, datagramPORTING MIDP TO DOJA311or serial communication mechanisms will need to either be removed orre-engineered.Like MIDP 2.0, DoJa supports a mechanism that allows the developerto avoid polling the keys for user input in the game loop. In DoJa, theCanvas.getKeypadState() method performs the same function asthe GameCanvas.getKeypadStates() method in MIDP 2.0 – in bothcases, an integer is returned where each set bit represents a particularkey stroke.
Alternatively, the processEvent() method of the Canvasclass can be overridden as shown in the code snippet below.public void processEvent(int type, int param){if(type == Display.KEY_PRESSED_EVENT){switch(param){case Display.KEY_DOWN:{...break;}case Display.KEY_SOFT1:{...break;}}}}There are two types of timers in the DoJa API, and they operate differently from the MIDP equivalent. The com.nttdocomo.util.Timerclass is used at an application level and notifies an observer class whenits expiry event occurs. This type of timer remains active as long asthe application does (or until it is explicitly cancelled).
In contrast,the com.nttdocomo.util.ShortTimer class is only used with thelow-level API, and events are sent to the Canvas.processEvent()method. In addition, this timer is automatically cancelled when the activescreen is changed.In summary, most MIDP application functionality can be ported toDoJa, sometimes requiring only a few source code changes. In fact, themost likely problem will be the requirement to keep the JAR executablebelow the 30 KB limit.
This can require significant re-architecting of yourMIDP application as the JAR size varies directly with the number ofclasses used and the number of methods in the classes, as well as thelength of the identifiers used for methods, fields, and classes. A commonway of reducing class size is to use an obfuscator which will replacereadable names with shorter ones.There are a number of other optimizations available to reduce executable size, including reducing the size of resources used, or movingaccess to them to a back-end server.
Judicious use of string constants,using the same name for a method and a variable (so that the namereference can be shared), as well as reducing the number of methodsand classes are all common techniques used to reduce class sizes and,therefore, the final JAR size.As a demonstration, I’ve ‘deflated’ the Irritant demo applicationdescribed above by applying some of these techniques (see the supplied source code Irritant2). The results are summarized in Table 10.4.312GAMES IN JAPANTable 10.4 Reducing JAR size (all sizes are shown in bytes)ActionJAR sizeMain classSecondary classInitial488621833355Reduce class names480621133285Reduce number of methods465021133009Shorten variable names456420802899Shorten string constants454620742899Change constant membersto static449619932899Note that even in this simple application, it was possible to reduce thefinal size of the JAR file by almost 8 % (and, consequently, the readabilityof the code by almost 100 %, but the limitations of the technology dictatethis approach).This may not seem like much, but in a more complex game it couldmean the difference between successful installation on a device andfailure.
Note also that these techniques could equally be applied to anyMIDP games not simply DoJa ones; however, as I mentioned, SymbianOS does not impose JAR file restrictions for MIDP applications, so there’sno excuse for doing so in a commercial environment.Unfortunately, DoJa is an example of what happens when businessstrategy defines the functionalities and limitations of a technology. Inorder to overcome these, developers are forced to use poor programmingtechniques and, consequently, produce application code that is difficultto maintain or re-use. This has also been flagged as one of the reasonscontributing to the poor acceptance of i-mode technologies outside ofJapan, as section 10.2 described.With this in mind, if we were to attempt a port of Third Degree(discussed in the previous chapter) across to DoJa, most of the changeswe would need to make would revolve around the size of the resources(the ‘Game Over’ image alone has a transparent background and is13 KB).
These assets would need to be reduced in size (and probablyquality) or moved to a server-based download approach.As the game itself is fairly simple, and the logic and interactions areabstracted by the engine and controller classes, the core porting effortinvolves working around the fact that DoJa does not have the concept oflayers or a LayerManager which are classes used extensively in mostMIDP games (the Third Degree engine itself sub-classes LayerManager). However DoJa does have a similar but less sophisticated conceptDOJA AND ECLIPSE313called the SpriteSet which has methods that can be used for spritecollision detection.There are differences in the sprite classes themselves as well.
In MIDP,we can set a transform and define a frame sequence. In DoJa, you haveto define and supply a linear transform yourself, and there is no built insupport for frames sequences – although it isn’t hard to do this yourself.We’d also need to change the use of the graphics contexts and userinput handling. In DoJa, the lock and unlock methods of the graphicsclass are used for double buffering (so there’s no explicit calls likeflushGraphics). While DoJa has a very similar mechanism to MIDPfor getting the key state during the game loop, you may need to use theprocessEvent for handling canvas key presses in certain cases.
Lastly,threads are generally shunned due to their overhead, in favor of a singleapplication loop that blocks until the game ends; so the main game loopmay need to be re-worked.For all this, many i-mode devices have such limited memory constraintsthat it may not be possible to get acceptable performance regardless ofthese issues.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
