Wiley.Games.on.Symbian.OS.A.Handbook.for.Mobile.Development.Apr.2008 (779888), страница 45
Текст из файла (страница 45)
Torpedo Bay is by the same developersLOCATION191and utilizes the same methodology as Swordfish, but it is essentially amultiplayer game, in a similar vein as the old battleships game but usingstreet maps.6.3.6 Implied LocationImplied location solutions are systems where the mobile phone usercan interact with objects or systems that have a known location relativeto the mobile network infrastructure. Thus a user’s particular locationcan be implied by his or her interaction with the objects or systems.At the system level, this could be the interaction with WLAN cellsor Bluetooth piconets. WLAN cells have a relatively small coveragearea, up to 100 meters, and as some mobile phones already includeWiFi functionality, it could be used to provide a general location area;alternatively, there have been proposals to use signal strength and theinteraction between different access points to obtain greater accuracy.However, the use of signal strength has a number of limitations whichmake its use outside a very defined environment, such as a researchlaboratory, somewhat impractical.1 Bluetooth technology offers a similarapproach for general location identification, although within a smallerarea than WiFi, at around 10 meters.
With its high penetration of theconsumer market, greater robustness against interference, and low powerrequirements, Bluetooth is arguably a much more practical solution formobile phones and has indeed started to be used for localized advertising.In terms of interacting with objects to determine a user’s location, thereare two main possibilities: two-dimensional bar codes, and RFID/NFCtags. Two-dimensional bar codes come in a variety of forms: QuickResponse (QR) codes (an example of which is shown in Figure 6.6),Figure 6.6 An example QR bar code192EXPLOITING THE PHONE HARDWARESemacodes, and ColorCodes, to name but a few of the variants.
All ofthese variants can contain an Internet address, which, when scanned,prompts the phone to load the relevant page. In Japan, QR codes havebecome commonplace on business cards to allow people to easilyupload contact details onto phones, or in some cases, allow bloggingof pictures associated with physical locations, for example, www.tokyopicturesque.com. All these codes require mobile phones with inbuiltcameras to take an image of the code, which is either decoded on thephone with specialist software, or transferred to an Internet service fordecoding. In terms of games, the only example of note is the ConQwestgame discussed in section 6.2.RFID/NFC tags are devices that can transmit a radio frequency signalthat contains information about the object to a suitable reader.
ABIResearch has predicted that RFID-enabled phones will occupy 50 %of the global market by 2009. That fact, coupled with its very lowpower operation, make it a suitable candidate for games, as previouslyhighlighted by PAC-LAN. The results of the research from PAC-LANand two other games, Mobspray and MobHunt,9 shown in Figure 6.7,indicate that RFID/NFC tags are superior to visual tags because theyhave faster read times, as the tags can be accessed at rates in excessof 100 kbits/s, whereas the two-dimensional bar codes require imagecapture and processing which typically takes few seconds. In addition,RFID tags can be written to, as well as read from, and have a simplerreading method, as the phone and the tag have merely to ‘touch’ or beplaced in close proximity (less than 3 cm), whereas the bar codes requireFigure 6.7Mobspray and MobHunt games9Coulton P., Rashid O., and Bamford W., Experiencing ‘‘Touch’’ in Mobile MixedReality Games, Proceedings of The Fourth Annual International Conference in ComputerGame Design and Technology, Liverpool, 15th – 16th November 2006, pp 68–75.LOCATION193the user to take a picture.
RFID tags are also more robust, as errors aremore likely to occur when scanning a bar code due to irregular cameraorientation.6.3.7 Using Location on Symbian OSTo allow developers to program location-aware applications more easily,Symbian introduced the location-based services (LBS) API, or locationacquisition (LA) API as it is sometimes called. LBS was initially a Nokiacomponent introduced into S60 2nd Edition, Feature Pack 2, but it laterfound its way to the core of the Symbian OS platform in Symbian OSv9.1. The API is comprehensive and broad enough to cover both networkbased positioning and GPS methods, to allow flexibility in applications.In particular it provides support for:• accurate coordinates identification with error estimates• bearing to, distance, altitude, latitude, and longitude determination• speed of the device and its direction of movement measurements(with accuracy estimates)• GPS network services and satellite information• Quality of Position (QoP) (dilution of precision) information estimations.Location-Based Services API OverviewLibrary to link againstlbs.libHeader to includelbs.hRequired platform securitycapabilitiesLocationClasses usedRPositionerServerRPositionerTPositionInfoBaseTPositionUpdateOptionsIn this section, we demonstrate how to use the LBS API with GPS andprovide a simple application that prints the latitude and longitude of thesmartphone onto the screen.
The example is the same for mobile phoneswith either internal or external GPS as the API automatically searches foran internal GPS receiver once started and if none is found it then searchesfor an external receiver by initiating a Bluetooth discovery session. Theuser is then presented with a list of all found Bluetooth devices, including194EXPLOITING THE PHONE HARDWAREFigure 6.8 Screenshot of FindMe on an S60 3rd Edition smartphoneBluetooth GPS receivers, to choose from, and once chosen, it will bestored by the API for future quick reference.The example is called FindMe, and a screenshot is shown in Figure 6.8.Note that the example requires the Location capability.The LBS API consists of almost 30 classes which include base classes,server and position classes, location information classes, and many others.For the sake of simplicity, in this example, we are going to use only thefour most basic classes needed to acquire the phone location, whichare:• RPositionerServer to make the primary connection to the location server• RPositioner to create a subsession to the server in order to obtaincurrent position information• TPositionInfoBase, to hold the position information• TPositionUpdateOptions to define the interval length for updates.Since most LBS classes are R classes they are not constructed withthe usual call to NewL().
They are simply defined as member variablesof a class and connected, manipulated, and finally disconnected in itsimplementation.As with any Symbian OS client-server API, a client application hasto set up a connection to the LBS server by calling RPositionServer::Connect() to enable it to retrieve positional information.Then the client must initiate a subsession to the connected server instanceby using one of the OpenL() method overloads of the RPositionerLOCATION195class. Once the connection is established, a requestor for the locationservice is identified in order to use it.A requestor guarantee is provided by the positioning framework tohelp prevent the misuse of positional information that is relevant to users’privacy and security. A requestor can be either a service or a contact. Aservice requestor represents any terminal or network application or service, and a contact requestor represents an individual person requestingthe location.
Since FindMe is an application (or service) on the phone,we utilize service requestors.Once the requestor is set up, the final stage in implementing LBSfor an application is to determine how often to capture the positional data updates, how long we should wait to receive the data inevent of delay, and how long we should keep the cached data. Oncethis is determined, we direct the server to start updating our application with position data with a call to the asynchronous functionRPositioner::NotifyPositionUpdate().
This takes as parameters a reference to an object of type TPositionInfoBase whichholds the location information retrieved from the server, and a reference to an active object’s iStatus member. Before terminatingthe application, we have to close both the subsession and the serverconnection with calls to RPositioner::Close() and RPositionServer::Close() respectively.Having described the basics for an LBS application, we can nowturn our attention to the specifics of our example. LBS requires theimplementation of an active object to manipulate the asynchronouscalls for location information acquisition. For this purpose, we haveimplemented the active object class CFindMeActive, which is derivedfrom CActive, implementing its two pure virtual functions RunL()and DoCancel().
The class encapsulates all necessary information andconstructions for operating the location service. The class is declared asfollows in FindMeActive.h:#include <lbs.h>//Location-based services APIclass CFindMeActive : public CActive{// Public methods for construction and destruction// are omitted for clarityprivate: // Inherited from CActive// Handle request completionvoid RunL();// Clean up a requestvoid DoCancel();private:// Member variablesRPositionServer iPosServer;// A pointer to our application's view classCFindMeAppView* iView;// Position information holder196EXPLOITING THE PHONE HARDWARERPositioner iPositioner;public:// Will be used from the view classTPositionInfo iPositionInfo;};The second-phase ConstructL() method performs the main actionsto connect to the server as previously discussed.
The important thing tonote is the use of function RPositioner::SetRequestor(), which isresponsible for assuring the security of the personal location informationof the user and takes three parameters:• the type of the requestor ERequestorService or ERequestorContact• the format of the identification of the requestor (EFormatApplication, EFormatTelephone, EFormatUrl or EFormatMail)• the value of the requestor identification which can be the applicationname, telephone number, URL, or email address, depending on whatwas passed as the second parameter.void CFindMeActive::ConstructL(CFindMeAppView* aView){// Set the pointer to our application viewiView = aView;// Connect to the position serverUser::LeaveIfError(iPosServer.Connect());// Open the subsession to the serverUser::LeaveIfError(iPositioner.Open(iPosServer));// Set the requestorUser::LeaveIfError(iPositioner.SetRequestor(CRequestor::ERequestorService ,// Service typeCRequestor::EFormatApplication ,// App formatKRequestor));// Our application name// Set update interval to receive position information// every 1 second.TPositionUpdateOptions udOpt;udOpt.SetUpdateInterval(TTimeIntervalMicroSeconds(KUpdateInterval));// The position server will terminate the request by the// requestor in case it could not retrieve position info// in 1 minute.udOpt.SetUpdateTimeOut(TTimeIntervalMicroSeconds(KUpdateTimeOut));// 5 seconds is the maximum age for a cached info.udOpt.SetMaxUpdateAge(TTimeIntervalMicroSeconds(KCacheAge));// Do not allow location server to send partial position data.// We are interested in complete data.udOpt.SetAcceptPartialUpdates(EFalse);// Set the update options.User::LeaveIfError(iPositioner.SetUpdateOptions(udOpt));// Set the active object to start getting asynchronous// position information.LOCATION197iPositioner.NotifyPositionUpdate(iPositionInfo,iStatus);SetActive();}When ConstructL() is executed, the active object submits an asynchronous request to receive positional information from the server.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
