Wiley.Games.on.Symbian.OS.A.Handbook.for.Mobile.Development.Apr.2008 (779888), страница 67
Текст из файла (страница 67)
It is based on their own W-CDMAtechnology that they created when other standards at the time were notin any usable state. To meet their specific requirements, NTT DoCoMochose not to use the S60 or UIQ platforms and, instead, developed theirown platform called the Mobile Oriented Applications Platform (MOAP).NTT DoCoMo have complete control over available content andtechnologies, and they have created methodologies to ensure that thingsstay that way. As you’ll see in this chapter, the business model drives thesoftware design and development process down to an extremely low level.FOMA handsets run Symbian OS v8.1b which gives them all thebenefits of the full EKA2 kernel without the platform security model ofSymbian OS v9.x.
These devices don’t need it because, as Chapter 1described, they are ‘closed,’ which means that you cannot install aftermarket applications written in native C++ on them. In addition, there isno support for the Java ME MIDP versions 1.0 or 2.0.The obvious consequence of this is that while these are Symbian OSsmartphones, you can’t just go ahead and write games for them usingnative C++ and a Symbian OS SDK, or using a MIDP (well you can – theyjust won’t install on any FOMA devices, which isn’t a whole lot of usewhen you’re targeting the Japanese market).One other thing we need to talk about here is the i-mode service,which is the mobile Internet platform originally created for NTT DoCoMoENTER DOJA!299subscribers that can be accessed from anywhere in Japan.
Over 5000official websites are accessible via the devices’ start menus (althoughunofficially there’s a lot more than that). It’s an ‘always on’ service, sothere’s no logging in or out. It offers extremely inexpensive access becausecharges are based on the volume of data sent and received rather thanairtime. There are also plans that charge on volume up to a thresholdafter which all usage is free.The i-mode service was so successful in Japan, that it expandedworldwide and the i-mode Alliance was formed, consisting of more than5 million subscribers spread over roughly 16 countries including the UK,Australia, Germany, France, Israel and Russia. However it has been metwith mixed success and, as Chapter 1 mentioned, in July 2007 the UKtelecommunications giant, O2 , announced that they would discontinuesupport for it by 2009, as they only had 250,000 subscribers.2So far, I’ve said a lot about what you can’t do, and at this point you’repossibly wondering how you actually can build games for the Japanesemarket.
Good. As you’ll see in the next section, you can create smallJava applications called ‘i-appli’ that leverage the proprietary DoJa profiletechnology developed by NTT DoCoMo. This is the only way to createand distribute installable games, unless you use Flash Lite, which Nigelwill talk about in the next chapter.So, that’s the market you’ll be targeting:• advanced devices with limited availability for hardware testing outsideJapan• FOMA/i-mode and MOAP restrictions from NTT DoCoMo• no platform security because the phones are closed• no Symbian C++ or MIDP development options available• sub-optimal Javadocs• a new profile called DoJa.Added to this, you probably can’t speak Japanese either! As they say,‘Boo Hoo For You.’10.3 Enter DoJa!DoJa, the Java development profile used in place of MIDP on i-modedevices, was conceived and created by – you guessed it – NTT DoCoMo.DoJa was created to provide a controlled application development2More information can be found at www.iht.com/articles/2007/07/17/business/imode.php.300GAMES IN JAPANenvironment for third party developers while ensuring that these applications (‘i-appli’) are secure and robust, and that the content providers’intellectual property (IP) is protected.
DoJa also simultaneously generatesrevenue streams for the operator through its technical design.Like MIDP, DoJa is dual layered and sits on top of a CLDC 1.0 (1.1 formore recent devices). It is built on the same basic premises that you wouldhave seen in the previous chapter; so the following concepts should befamiliar:• a lack of floating point support (although this has been added intoJapanese versions)• a generic connection framework• reduced java.util and java.io package functionalities• no finalization• byte code pre-verification.Instead of a JAD file, DoJa supports the concept of a more advancedapplication descriptor file (ADF) which is completely standardized andintegrated into the framework.
In this part of the world, i-appli applicationsare managed by the Java Application Manager (JAM) which provides manyof the same services as the AMS does in Symbian OS MIDP.There are a number of versions of the DoJa profile, most of which areonly available for use in Japan. For markets outside Japan, NTT DoCoMoproduced two tailored API versions which are known as 1.5oe and 2.5oe(the ‘oe’ stands for Overseas Edition).
These versions do not expose orsupport many of the advanced functionalities we’ve covered (such asbar codes, biometrics, etc.), because the required technical and socialsupporting infrastructure isn’t available outside of Japan. In any case,Western consumers generally aren’t as willing to pay for such expensivehandsets anyway (including me).Anyone familiar with the excellent Java Community Process (JCP), theJSRs, the reviews of JSRs, waiting for handsets that support them, anddealing with subsequent fragmentation issues will appreciate that oneof the key benefits to NTT DoCoMo in developing a proprietary profilesuch as DoJa is that it can bypass the JCP altogether.
Since DoJa is theirprofile, they can just get the in-house developers to build a new versionwhenever they decide they need it. Not surprisingly, there are at leastseven versions of the profile for use in Japan, in addition to the twooverseas APIs, whereas MIDP is only tentatively on its third version aftermore than twice as many years. And since NTT DoCoMo are providingthe handsets as well as the development platform, they can avoid the sortof fragmentation problems that are caused by optional API support ontarget hardware that have been the bane of Java ME developers worldwidefor years.ENTER DOJA!301Newcomers to DoJa development will find a large number of technicalrestrictions on what you can do and how you can do it.
This canbe frustrating after the relative freedom of MIDP 2.0 with the suite ofoptional extras provided by the latest Symbian OS phones. We’ll go intothis in more detail later, but here’s a taste of what I mean. In DoJa 2.5oe:• you can’t open sockets using anything other than OBEX or HTTP and,in the latter case, only to the server that the application was originallydownloaded from• data transfer rates on any given HTTP transaction are limited to 5 KBupload and 10 KB download• the size of the application JAR file is usually limited to a mere 30 KB• you only get up to 200 KB for local storage in a binary random accessfile called the Scratchpad (there is no Record Management System)• there is no access to PIM data (e.g.
calendar information)• there are no Bluetooth APIs• there is no multi-tasking – so only one application can be running ata time.As a direct consequence of these restrictions, application architecturesrevolve around server-centric (and hence bandwidth-centric) storage.After all, if you need to store a recorded voice tag for a video you justtook with the onboard camera, you’re hardly likely to be able to store theresulting video and audio byte streams in a 100 KB file – so, chances are,you will need to develop a server-based remote storage model for yourapplication.As another example, multiplayer games need some way for the handsets to communicate with each other. While this can be done usinginfra-red, it’s a bit frustrating when the communications fail becauseyou didn’t keep the devices aligned correctly throughout the game.
Usually, the solution here is to use Bluetooth, but DoJa support for this didnot arrive until version 5.0 (for Japan only), so as a result, developershave resorted to using server-based ‘messaging’ for real-time distributedgame play.This is a whole lot of data traffic, and it’s not hard to see why thisis such a successful business model for the operator. DoJa applications,by design, require a lot more use of bandwidth than either MIDP ornative Symbian OS applications, and this is exactly what the end usersget charged for.Since it has extremely well-defined boundaries, the DoJa profile is veryeasy to learn and you can build advanced applications quite quickly.There are some excellent online tutorials (see the Mobile Developer Lab302GAMES IN JAPANwebsite, www.mobiledevlab.com, for more information), and a broaddeveloper support base both in Japan and Europe, found at www.dojadeveloper.net/about.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
