Symbian OS Communications (779884), страница 28
Текст из файла (страница 28)
Instead, the GAVDP API is used via the multimediaframework of Symbian OS. In other words, Bluetooth stereo headsets orspeakers are rendered in Symbian OS as though they are local audiodevices: this has the very compelling feature that any extant multimediaAV PROTOCOLS AND PROFILES121application can stream over Bluetooth without any change (or indeedknowledge that it is streaming via Bluetooth). Symbian OS licensees ownthe policy of selecting the appropriate audio input/output devices to sendor receive audio.4.4.1 Remote ControlThis remote-control framework, first delivered with the Bluetooth AVRCPprofile in Symbian OS and sometimes known as ‘Remcon’, abstractsaway the transport (e.g. Bluetooth, IrDA) and the protocol (e.g. AVRCP orproprietary).
Therefore applications can expect to receive events of theform ‘Play’, ‘Stop’ rather than requiring to interpret byte representations ofremote-control protocols. Each of the transport/protocols combinationsis called a ‘bearer’ and the standard Symbian OS includes the Bluetooth/AVRCP bearer. The device manufacturer may include other bearersto support, for example, a wired headset.The events and commands that are presented via the ‘core’ RemConAPI are based on the AV/C specification (upon which AVRCP is based).This specification need not be consulted to use RemCon; but it is notedhere as AV/C is a common, generic set of remote control commands.One interesting issue regarding implementation of AVRCP (and otherremote-control bearers) on an open platform, such as Symbian OS, is thatof where to send incoming remote-control signals.
For example, a ‘Play’signal arrives from a remote Bluetooth headset: to which applicationshould it be sent? What about volume controls? Should they be sentelsewhere in the system?The remote-control framework allows Symbian OS licensees to implement a ‘routing’ policy that allows for their particular combination ofUI metaphor (for example, whether non-visible applications are stillrunning or not), device-wide volume policy, inbuilt media applications,and potential downloadable applications to be sent remote-control commands.
The routing policy also applies to the sending of outgoing remotecontrol in a ‘connectionless’ manner (i.e., the application doesn’t care towhich device the command is sent). The use case for these connectionless commands is, for example, a volume-setting user interface informsRemcon of a need to send a volume up signal to the current renderingdevice. The policy can query the audio policy object to see which deviceis currently rendering, and forward the volume remote-control signal tothat device.
The licensees routing policy is encoded into a plug-in insideRemcon.This section does not provide an example application; however, snippets of code will be presented that demonstrate how a remote-controlcommand can be sent, and received. Following the description of therouting policy, the ability for an arbitrary application to receive events isdependent on the routing policy.122BLUETOOTHAn application that wishes to receive and/or send remote controlsignals first creates an ‘interface selector’ through instantiation of aCRemConInterfaceSelector class.
It then attaches classes representing different APIs to the interface selector: the two main APIs areCRemConCoreApiController (for controllers) and CRemConCoreApiTarget (for targets). Both of the core API classes may be attached tothe interface selector simultaneously.A concrete remote control API is attached to an interface selectorthrough a call to the API’s NewL().
The NewL() takes as parameters areference to the interface selector, and a reference to an callback interface mixin published with the remote control API. Therefore the client of(for example) the CRemConCoreApiController class must provide areference to an implementation of the MRemConCoreApiControllerObserverinterface.The MRemConCoreApiControllerObserver interface simply provides notification of the result of the sending by the controller of acommand (a non-error result indicates the successful sending of thecommand in the opinion of the appropriate bearer).The MRemConCoreApiTargetObserver is particularly importantto applications that expect to receive remote control commands: it is theinterface through which commands are delivered.
Some commands, suchas Play, have dedicated APIs through which to deliver command-specificoptions (in the case of ‘Play’ a parameter, derived from AV/C, is suppliedwhich gives the speed at which to play the media). Commands that donot have parameters are all delivered through the MrccatoCommandmethod. (Note that certain M-classes in Symbian OS take a randomlooking set of letters to prevent name clashing of methods from otherM-classes.)All of the methods in the MRemConCoreApiTargetObserver andCRemConCoreApiController which relate to the receiving or sendingof commands take a TRemConCoreApiButtonAction parameter. TheTRemConCoreApiButtonAction enumeration consists of the values:• ERemConCoreApiButtonPress• EremConCoreApiButtonReleaseERemConCoreApiButtonClickFor the controller case it allows the sending of either a ‘click’ of a virtualbutton, or a ‘press and hold’ of the virtual button.
The ‘press and hold’ feature allows the user to click a UI widget to begin (for example) increasingthe volume of a target device. In this case the application would send thePlay command with ERemConCoreApiButtonPress at the time the UIwidget is depressed. When the UI widget is released, the Play commandwould again be sent but with the TRemConCoreApiButtonActionvalue of ERemConCoreApiButtonRelease.AV PROTOCOLS AND PROFILES123CRemConCoreApiTargetCRemConInterfaceSelectorCRemConCoreApiControllerFigure 4.14 Block diagram of client-side remote control classesIn the target case, the bearer attempts to deduce a value for the buttonaction – this is then delivered to the application.
The AVRCP specificationcontains a number of timer values that allow an AVRCP entity to attemptto deduce the button action – even though the packets on the air (or wirein the case of Firewire!) only specify button press or release. The processis not particularly simple for the AVRCP entity – this is one more benefitof hiding AVRCP itself from the application developer.Target exampleThe following code shows the construction of the interface selector, andthe attachment of a remote control API that allows for the receipt ofremote control signals from a remote device.iRemConInterfaceSelector = CRemConInterfaceSelector::NewL();iRemConTarget = CRemConCoreApiTarget::NewL (*iRemConInterfaceSelector,*this);iRemConInterfaceSelector->OpenTargetL();//Controller exampleiSelector = CRemConInterfaceSelector::NewL();iCoreController = CRemConCoreApiController::NewL(*iSelector, *this);iSelector->OpenControllerL();//Ask user which device address we should connect to...TBTDevAddr btAddr;GetDeviceAddressL(btAddr);// Store as 8 bit machine readableRBuf8 bearerData;bearerData.CreateL(btAddr.Des());// Form the RemCon Addr from the AVRCP Uid and the// bluetooth addressTRemConAddress addr;addr.BearerUid() = TUid::Uid(KRemConBearerAvrcpImplementationUid);124BLUETOOTHaddr.Addr() = bearerData;iSelector->GoConnectionOrientedL(addr);iSelector->ConnectBearer(iStatus);SetActive();//send Playcase ERemConCoreApiPlay:iCoreController->Play(iStatus, iNumRemotes,ERemConCoreApiButtonClick);//send StopiCoreController->Stop(iStatus, iNumRemotes, ERemConCoreApiButtonClick);//send volume control when user presses UI widgetiCoreController->VolumeDown(iStatus, iNumRemotes,ERemConCoreApiButtonPress);// user releases UI widget on touchscreeniCoreController->VolumeDown(iStatus, iNumRemotes,ERemConCoreApiButtonPress);4.5 SummaryIn this chapter we have learnt about:• discovering and connecting to other Bluetooth devices• searching for services offered by remote devices• registering our service on the local device• security on Bluetooth links• low-power modes on Bluetooth links• L2CAP, RFCOMM, and the advantages and disadvantages of each• AV and remote control services provided by Bluetooth protocols andprofiles, and the remote control framework.ReferenceGamma, E., Helm, R., Johnson, R.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
