quick_recipes (779892), страница 50
Текст из файла (страница 50)
When the initial network information data has been retrieved,RunL() will be called.In order to monitor any network information change, use the NotifyChange() function with the second parameter set to ECurrentNetworkInfoChange.Since we are using the same active object for two different requests,we keep track of what is currently being done using the iMonitoringvariable. The importance of this becomes clear when implementing theDoCancel() function to determine which request needs to be cancelled.The network information data is stored in a TNetworkInfoV1 variable, which contains a lot more information than just the Cell ID ofthe currently used Cell.
TNetworkInfoV1 contains the following variables:280SYMBIAN C++ RECIPES• iMode (network mode, i.e., GSM, cdma2000, etc.).• iStatus (phone network status).• iCountryCode (country code for the Cell’s network).• iNetworkId (network ID for the Cell).• iDisplayTag (tag displayed for the Cell, which actually is not thesame as the tag shown in the phone).• iShortName (short name for the network).• iBandInfo (network band information, i.e., 800 MHz on Band A,1900 MHz on Band C, etc.).• iCdmaSID (system identity (SID) of the CDMA or AMPS network).• iLongName (longer name for the network).• iAccess (the access technology that the network is based on).• iAreaKnown (indicates if the area is known).• iLocationAreaCode (location ID for the Cell).• iCellId (the actual Cell ID, which is unique inside the network fora specific operator in a specific country).4.8.3.2Retrieve Call Forwarding StatusAmount of time required: 25 minutesLocation of example code: \Telephony\Telephony_Monitor2Required library(s): etel3rdparty.libRequired header file(s): etel3rdparty.hRequired platform security capability(s): ReadDeviceData, NetworkServicesProblem: You want to know whether the phone automatically forwardsincoming calls.Solution: The CTelephonyAppUi class shows how to use the ForwardingStatus_Getter code.Discussion: You need to call CTelephony::GetCallForwardingStatus().
With this function you also need to specify which callforwarding status is being retrieved. The available options are:• ECallForwardingUnconditional (forwards for all calls).• ECallForwardingBusy (forwards when subscriber is busy).TELEPHONY281• ECallForwardingNoReply (forwards when subscriber does notreply within timeout).• ECallForwardingNotReachable (forwards when subscriber isunreachable).When the phone’s call forwarding status has been retrieved, RunL()will be called and the error code can be retrieved from the iStatusvariable.The status for the specified call forwarding condition is stored in aTCallForwardingSupplServicesV1 variable (if iStatus is KErrNone), which contains two fields:• iCallForwarding (the status of the forward, i.e., active, notactive, etc.).• iCallForwardingCondition (identifies the condition which wasrequested).Note: Setting the call forwarding on/off requires usage of a non-publicSymbian API but the same functionality can also be achieved byusing AT commands, if the target device supports AT commands forchanging call forwarding information.4.8.3.3Retrieve Call Barring StatusAmount of time required: 20 minutesLocation of example code: \Telephony\Telephony_Monitor2Required library(s): etel3rdparty.libRequired header file(s): etel3rdparty.hRequired platform security capability(s): ReadDeviceData, NetworkServicesProblem: You want to know if the phone is set to prevent some calls.Solution: The CTelephonyAppUi class shows how to use the BarringStatus_Getter code.Discussion: You need to call the CTelephony::GetCallBarringStatus() function.
With this function you also need to specify whichcall barring status is being retrieved and the options are:• EBarAllIncoming (barring for all incoming calls).• EBarIncomingRoaming (incoming when roaming).282SYMBIAN C++ RECIPES• EBarAllOutgoing (all outgoing calls barred).• EBarOutgoingInternational (international calls barred).• EBarOutgoingInternationalExHC (all international calls exceptones to the home network are barred; used when roaming).When the call barring status has been retrieved, RunL() will be calledand the error code can be retrieved from the iStatus variable.The call barring status for the specified condition is stored in a TCallBarringSupplServicesV1 variable (if iStatus is KErrNone),which contains two fields:• iCallBarring (the status of the call barring, i.e., active, notactive, etc.).• iCallBarringCondition (identifies the condition which wasrequested).Note: Setting the call barring requires usage of a non-public SymbianAPI.
If you require this functionality, you need to contact Symbianpartnering (see Chapter 5).4.9 ConnectivityThe connectivity features of modern smartphones have grown extensivelyover the past few years, and you may choose between technologies suchas Bluetooth, Infrared and USB for short-range communications. SymbianOS v9.x offers powerful support for each of the above connectivity bearersand provides rich APIs to fulfill any complicated task you may want toimplement.
Support can be split into two main categories:• Low-level technologies (e.g., Infrared or Bluetooth) and frameworks(e.g., ESOCK).• High-level technologies, such as OBEX.Some of the connectivity methods, for instance, those using USBconnections, are generally reserved for use by Symbian’s licensees andtherefore unavailable to third-party developers. As a result, these recipesillustrate how to use Infrared and Bluetooth connections to addressvarious issue you might need to resolve at both low and high-levelprotocol layers. As these recipes describe connectivity services, theydo not discuss networking and other areas that are based on the lowlevel components described here.
You can find more information aboutnetworking in the recipes found in Section 4.3.CONNECTIVITY283As a general rule, communications in Symbian OS are built arounda client–server architecture just like many other available services. C32is the Symbian OS comms server and supplies a client-side API andserver-side code, which is run as a thread in the C32 server process. TheC32 process contains its main thread, the C32 thread and a number ofother threads, namely ESOCK, ETel and Phonebook Synchronizer.
TheESOCK framework will be mentioned extensively in these recipes, as itplays an important role in connectivity services provision for applicationsand high-level technologies in Symbian OS.The actual implementation of various connectivity components isspread over multiple modules and therefore can be quite confusing insome cases. A good example are the OBEX classes, which are declared inclearly named header files – but you have to link your application againstirobex.lib even though you intend to use Bluetooth connections.The usage of different communication techniques may require thatappropriate platform security capabilities to be granted to your applications. All such cases are noted explicitly throughout the examples wherenecessary. High-level protocols, such as OBEX, often rely on the policydeclared by low-level ones; hence it is reasonable to assume in mostcases that your applications will be expected to have LocalServicescapability present.In order to keep them simple the code samples in these recipesare going to use as few active objects as possible.
Most asynchronousmethod calls are simply followed by User::WaitForRequest(). Thisis of course not how production-quality code should behave, and the codesamples provided for download to accompany this book will illustratehow to call asynchronous APIs correctly.4.9.1 Easy Recipes4.9.1.1Print over IrDAAmount of time required: 10 minutesLocation of example code: \Connectivity\IRPrintRequired library(s): c32.libRequired header file(s): c32comm.hRequired platform security capability(s): NoneProblem: You want to print a document to an IR printer.Solution: This task is quite simple and requires about a dozen lines ofcode. The solution is to use serial communications over an emulatedIrCOMM port:284SYMBIAN C++ RECIPES#include <e32base.h>#include <e32svr.h>#include <c32comm.h>_LIT(KIrCOMM,"IrCOMM");_LIT(KIrCOMM0,"IrCOMM::0");void PrintDataL(TDes8& aData){RCommServ server;server.Connect();TInt ret=server.LoadCommModule(KIrCOMM);User::LeaveIfError(ret);RComm commPort;ret=commPort.Open(server,KIrCOMM0,ECommExclusive);User::LeaveIfError(ret);TRequestStatus status;commPort.Write(status,KTimeOut,aData);User::WaitForRequest(status);User::LeaveIfError(status.Int());commPort.Close();server.Close();}It’s a simple as that!Discussion: The snippet above uses the standard Symbian OS client–server mechanism and follows a typical sequence as follows:4.9.1.21.Open client session to above server.2.Use this session to communicate data to and from the server.3.Close the session.4.Close the server if required.Discover Infrared DevicesAmount of time required: 20 minutesLocation of example code: \Connectivity\IRDeviceRequired library(s): esock.libRequired header file(s): es_sock.hRequired platform security capability(s): LocalServicesProblem: You want to discover the Infrared-enabled devices in range.CONNECTIVITY285Solution: To get the list of available IR-devices in range, you can usethe ESOCK classes RSocketServer and RHostResolver declared ines_sock.h.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
