Wiley.Games.on.Symbian.OS.A.Handbook.for.Mobile.Development.Apr.2008 (779888), страница 61
Текст из файла (страница 61)
The firstwas the Java Technology for the Wireless Industry (JSR 185). The JTWIaims to minimize fragmentation across handsets by defining a minimumlevel of support for optional APIs. Release 1 of the JTWI, approved inJuly 2003, defines three categories of JSRs – mandatory, conditionallyrequired, and minimum configuration. A handset that declares itself to beJTWI-compliant supports at least the following mandatory JSRs:• MIDP 2.0 (JSR 118)• Wireless Messaging API (JSR 120).JAVA ME 101269The minimum configuration is unsurprisingly CLDC (either version).
Ifthe device allows MIDlets to access multimedia functionality via APIs,then the JTWI also specifies that the Mobile Media API (JSR 135) isrequired (i.e., it is conditionally required).It also defines a number of implementation parameters for the JSRs,including things like support for JPEG encoding, MIDI playback, thenumber of record stores allowed in the RMS, Unicode support, and somethreading requirements.In December 2006, this was taken a step further with the release ofthe final draft of the MSA – the Mobile Services Architecture (JSR 248),1which can be thought of as JTWI 2.
This mandates that an MSA compliantdevice is JTWI compliant as well as providing support for the followingAPIs:• Security and Trust Services API (177)• Location API (179)• SIP API for Java ME (180)• Content Handler API (211)• Payment API (229)• Mobile Internationalization API (238)• Multimedia Supplements (JSR 234)• Web Services (JSR 172)• Scalable 2D Vector Graphics API for Java ME (226)• Messaging (JSR 205)• Mobile 3D Graphics API (JSR 184 1.1)• Mobile Media API (JSR 135)• Bluetooth (JSR 82)• File and PIM (JSR 75)• MIDP 2.0 (JSR 118)• CLDC1.1 (JSR 139).The specification defines two categories of MSA known as MSA andMSA Subset.
A device that is MSA Subset compliant supports onlythe last seven (bolded) JSRs from the list above. This is a huge stepforward, but at the time of writing there are less than a dozen or so1You can find out more about JSR 248 at: jcp.org/aboutJava/communityprocess/final/jsr248/index.html.270MIDP GAMES ON SYMBIAN OShandsets in the market that are MSA compliant, and they’re not actuallySymbian smartphones (you can find the latest list of compliant devices atdevelopers.sun.com/mobility/device/device).
So it will take a while untilwe can rely on this level of standard support.Ok, that’s about all we need to discuss in the history of Java ME,particularly as there are many excellent textbooks that cover this indepth. See the references at the end of the chapter for more information.9.3 To Java ME or Not To Java ME?Some people will tell you that Java ME (and actually Java itself) is tooslow for any type of software development, let alone game development.Well, they’re wrong. First and foremost, if you want your game to run onas many mobile phones as possible, you need to use the most ubiquitousplatform in existence. Second, there is a huge support base for Java MEboth in industry and from developer networks.
Third, a well designedMIDP game can be ported across to DoJa fairly quickly which opens upthe possibility of entering the largest game market on the planet – Japan.I’ll discuss some of the issues involved in a port to DoJa in Chapter 10.The ability to perform rapid application development in the mobilespace is imperative given the short time to market demands of today’sgames industry. As much as I love C++, I’ll still turn to Java ME almostevery time for quick prototypes. Especially when you can demo it onSymbian smartphones, BlackBerry phones, Nokia Series 40 handsets, oreven one day maybe an iPhone (if they let us), and on independentproprietary OS phones from Fujitsu, LG, Telstra and so on.There’s a large number of other reasons to use the Java ME platform forgame development as well.
To start with, there are millions of skilled Javadevelopers worldwide and the learning curve from standard edition Javato Java ME is actually quite flat. This means obtaining quality professionalsis easy for game development studios. In addition, there are forums andhundreds of websites with code samples, tutorials and techniques. Theseweren’t written by academics or corporations, but by pioneers who hadto work out how to actually make this technology work in the early days.The Game API, introduced in MIDP 2.0 addresses many issues realizedin the MIDP 1.0 days by introducing techniques such as double buffering,a key state input mechanism that allows for multiple keystroke detectionand a high-level mapping, allowing the abstraction of main game actionsfrom specific keys. Compared to game development using Symbian C++,this is a lot easier to do, and there are more people available to doit.
The Game API also introduced sprites, tiles and layer managementsupport. Sprite transformations, (which allow for reduced JAR sizes),image transparency and collision detection at a Sprite and pixel level arealso included, which allows the developer to focus on the game logic fora better product.TOOLS AND SDKS271So these are some of the reasons why you should use Java ME for gamedevelopment. Now here are some reasons why you should be carefulbefore you do:• even though advanced hybrid techniques are used to produce thefinal executables, Java ME applications are just not going to be as fastor efficient as a well written native Symbian C++ application.
Thatsaid, Symbian engineers have put a large amount of time into gettingJava ME applications to run as fast as possible with a huge amount ofsuccess, as evinced by internal benchmark tests.• you are limited to the functionality exposed via the CLDC, MIDP andOptional APIs. While there are some ways (hacks) to access nativefunctionality, they’re architecturally poor, not a lot of fun and areusually best avoided – in short, if you need native, be native and workin C++• fragmentation across handsets, which has already been discussed• updates to the JavaME profiles and JSR support can be very slow, so ifyou’re dependent on a particular API, it may hold up your product• many handsets have quite restrictive limitations on core applicationparameters such as a maximum allowed JAR size, maximum heapmemory, as well as limitations on available memory for data persistence.
For larger database style applications, these can be prohibitive• MIDlets can be slow to load due to the need to load the entire VMbinary and AMS (if not already resident)• security built-in via bytecode verification and a sandbox securitymodel. This is independent of (but also built on) the new platformsecurity model introduced in Symbian OS v9.However, as we’ll see in the next section, many of these issues don’tapply on Symbian smartphones as their offering is best of breed.9.4 Tools and SDKsGetting started in Java ME development is really easy and there are anumber of great tools and IDEs freely available online to help get yougoing:• Eclipse with the EclipseME plugin (www.eclipseme.org )• Netbeans using the Netbeans Mobility Pack (www.netbeans.org/products/mobility )272MIDP GAMES ON SYMBIAN OS• Sun Wireless Toolkit (WTK) (java.sun.com/products/sjwtoolkit/download.html ).Until recently, Nokia also supplied Carbide.j,2 which I liked a lot, andit plugged itself into Netbeans as well.
However, support for this has nowbeen withdrawn, as apparently there’s not a lot of point having it aroundwhen so many people can get Eclipse or Netbeans for free. Nokia doeshave a large number of SDKs for MIDP development for S60 and Series40 devices though and both Eclipse and Netbeans will let you use these(and switch between them) quite easily in your projects.Although I’ve used Netbeans happily for years, these days I tend tofavour Eclipse in the interests of IDE consolidation – apart from using it tobuild Java ME software for Symbian OS, you can also use it for BlackBerrydevelopment (with some work) and, as we’ll see in the next chapter, youcan use it to target i-mode devices in the Japanese market with the DoJaplugin from NTT DoCoMo.
In addition, Carbide.c++ is based on Eclipse,so the look and feel is the same, whatever work you’re doing.If you’ve never done any Java ME work before, the WTK from Sunis the best place to start. It’s a simple development tool that allows youto focus on learning Java ME technologies without having to learn theintricacies of a new IDE up front. The latest version of the WTK is 2.5.1and it also includes the SNAP Mobile SDK which is used for providingstandardized community features in online game development. This issomething that we’ll cover in section 9.10.9.5 What About MIDP on Symbian OS?Let’s jump straight into why Symbian’s implementation of CLDC andMIDP provides one of the best game development platforms in the mobilespace.
Symbian first added CLDC 1.0 and MIDP 1.0 support in SymbianOS v7.0 in 2002. The CLDC was a port of Sun’s CLDC 1.0 HotspotImplementation VM (CLDC HI). This was about ten times faster than thestandard KVM available at the time by virtue of leveraging techniquessuch as lightweight threading and dynamic adaptive compilation.
Thenfrom Symbian OS v8.x onwards, they supplied a port of CLDC 1.1 HI, thusadding floating point support for Java ME applications to their offering.Then came the unforgettable Nokia 6600. Based on Symbian OS v7.0s,it was the first Symbian smartphone to support the MIDP 2.0 profile andmost of the JTWI release 1. The main point to note here is that in thiscase, MIDP 2.0 was actually implemented by Symbian engineers andthis allowed them to leverage the underlying operating system servicesand interfaces to maximize performance.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
