Symbian OS Communications (779884), страница 21
Текст из файла (страница 21)
Here’s a briefexample of its use:class CS60BtDeviceDiscoverer : public CActive{public:...void DiscoverDevicesL();virtual void RunL();...private:RNotifier iDevDiscovNotif;TBTDeviceSelectionParamsPckg iSelectParamsBuf;TBTDeviceResponseParamsPckg iResponseParamsBuf;TBTSockAddr iAddr;};void CS60BtDeviceDiscoverer::DiscoverDevicesL(){User::LeaveIfError(iDevDiscovNotif.Connect());iDevDiscovNotif.StartNotifierAndGetResponse(iStatus,KDeviceSelectionNotifierUid, iSelectParamsBuf, iResponseParamsBuf);SetActive();}void CS60BtDeviceDiscoverer::RunL(){if(iStatus.Int() == KErrNone){88BLUETOOTH// iResponseParamsBuf now contains details of the device the userselectediSockAddr.SetBTAddr(iResponseParamsBuf().BDAddr());// once other params (eg.
security, port) set on iAddr it can be usedtoconnect a socket}else// an error occurred{User::Leave(iStatus.Int());}}Example 4.3Discovering devices using the S60 device discovery UITo tailor the search to a more specific subset of devices (e.g. devicesoffering some form of rendering capability) see the methods on TBTDeviceSelectionParams.ConnectabilityAs with discoverability, Symbian OS applications cannot control theconnectability of the local device. Certain UIs will have a widget thatthe user can control that may directly control the connectability – thoughthe ‘connectable’ tag is much less meaningful to a user than ‘discoverable’.Often the UI widget that may affect connectability refers to turningBluetooth on or off; depending on the combination of UI and hardwarethis may range from toggling connectability to toggling the actual powerstatus of the Bluetooth hardware.Also, similarly to discoverability, the Bluetooth stack in Symbian OSwill not make itself connectable if there are no services to connect to.Furthermore, Symbian OS does not allow the device to be in a statewhere it is discoverable, but non-connectable.PairabilityThe Bluetooth stack in Symbian OS and the UI interact during theBluetooth pairing process to obtain the passkey from the user.
Once theuser has entered a passkey it is returned to, and stored by, the Bluetoothsubsystem. Today, all UI platforms leave the device in pairable mode atall times. There is no API to directly control whether the device is globallypairable or not.Class of deviceThe class of device value is managed by two mechanisms in SymbianOS: the device class is fixed by the device manufacturer since it is a staticvalue declaring the perceived appearance of the device to the end user.So for example a Symbian device may either be a ‘smartphone’, a regularBLUETOOTH IN SYMBIAN OS89‘mobile phone’, or perhaps a ‘laptop’.
The device manufacturer sets thisvalue at device creation time.Applications can register the service class value for their correspondinguse case (if applicable – not all services will need to update the serviceclass field).The applications make the updates to the service class by either of twomechanisms:• Publish and Subscribe (P&S)• Using a SetOpt() on their socket.Clearly the latter requires the service has access to the underlyingBluetooth socket. Despite this limitation, if the socket is available it isthe preferred method to set the service class, due to two problems usingthe P&S method – the relatively high capabilities required to perform theoperation and the possibility of race conditions.The P&S mechanism is useful for services that, for example, run overOBEX (see Chapter 10 for more details on running services over OBEX),as the client does not have access to the underlying socket to use theSetOpt() call to set the service class.
There are a number of Bluetoothapplications which may elect to run a service over OBEX; in thesecases, those applications will need to use the P&S mechanism to set therelevant service class bits – specifically the ‘object transfer’ bit. However,there is a problem with this approach – in order to write to this P&Skey, applications require both LocalServices and NetworkControlcapabilities. This essentially makes it impossible for most applications toperform this operation.Note that from Symbian OS v9.2 onwards, the OBEX stack will automatically set the object transfer bit in the service class when listeningon a Bluetooth transport. It does this using the socket SetOpt() call,which does not require the NetworkControl capability.In v9.1 there is no direct solution to this issue – although usefullythe object transfer bit will be set whenever the default OBEX service isrunning on a device.
Currently all UI platforms keep this service runningwhenever devices are connectable, so in practice this should not turn outto be a problem.The other issue with using the P&S mechanism is the possibility ofrace conditions. These can occur when two clients need to enable anew service class bit – the sequence for a client should be read, modify,write. There is a small possibility that two clients will interleave theirupdates, such that the first one reads the current value, then the secondone does, then the first one writes the new value, then the second one90BLUETOOTHwrites its new value. In that case the update from the first client will belost.
Reading back the service class after setting it to ensure the expectedupdate occurred may appear to be a workaround for this, however, thereis no guaranteed solution to the problem as scheduling issues can causethe read to return the expected value. The optimum solution to thisproblem is always to use the SetOpt() in preference to the P&S key.A quick note on filtering using the class of device. Neither the majoror minor device classes should be used for filtering – the intent of theseis to present, for example, an informative icon to the user of the deviceperforming the device discovery. Major service class can be used to filterdevices out of a search if they do not claim to provide the appropriatehigh-level service class, but any devices that do have the appropriate bitset still need to be queried using SDP to ensure they provide the particularservice that the application is searching for.
For example, we can safelyassume that devices without the object transfer bit set do not offer theFTP (OBEX file transfer profile – a standard way of transferring objectsbetween devices) service, but any that do have it set may not offer theFTP service either – they may well be offering another, unrelated, objecttransfer service. Thus once we have identified a candidate set of devicesoffering the service, we should then perform SDP queries for that serviceon the device before attempting to connect to it.9When using the P&S method, TBTDeviceClass is used when dealingwith device classes.
It has getters for each part of the device class: majordevice, minor device and major service classes. There are no settingmethods – setting is only allowed at construction time.Here’s an example in which we add in the networking major serviceclass using the P&S key:TInt currentCodAsTInt;User::LeaveIfError(RProperty::Get(KPropertyUidBluetoothCategory,KPropertyKeyBluetoothGetDeviceClass, currentCodAsTInt));TBTDeviceClass currentCod(currentCodAsTInt);TUint16 newServiceClass =static_cast<TUint16>(currentCod.MajorServiceClass() |EMajorServiceNetworking);TBTDeviceClass newCod(newServiceClass, currentCod.MajorDeviceClass(),currentCod.MinorDeviceClass());User::LeaveIfError(RProperty.Set(KPropertyUidBluetoothCategory,KPropertyKeyBluetoothSetDeviceClass, newCod.DeviceClass());Example 4.4Adding a new bit into the major service class using P & S9In this case we must perform the SDP search anyway to discover on which RFCOMMserver channel the default OBEX service is listening.
But even in cases where there is nodynamic port information registered in SDP (PAN profile, for example) we still need toperform the query to ensure the precise service we require is available.BLUETOOTH IN SYMBIAN OS91There is much less effort involved in using SetOpt(), we simply askfor the bit we want added to the major service class:// iListeningSocket is a constructed CBluetoothSocket (of any protocol//supported by CBluetoothSocket)TInt error = iListeningSocket.SetOpt(KBTRegisterCodService, KSolBtSAPBase,EMajorServiceNetworking);Example 4.5SetOpt()Adding a new bit into the major service class using aNotice that the level of the option is KSolBtSAPBase – this impliesthat it can be sent to any Bluetooth socket.4.2.3 Logical TransportsIn Symbian OS, although there are classes published pertaining to useof the synchronous links, there is very little need to use them.
This isbecause the use of synchronous links is currently only specified by theHands Free Profile, which is already implemented in shipping SymbianOS-based devices. Further, the Bluetooth stack in Symbian OS does notprovide any real-time guarantees regarding the transport of data via asynchronous link. And finally, Bluetooth controllers are often configuredto require data that is to be to be transported over a synchronous linkbe given to the Bluetooth hardware via a separate physical interface tonon-synchronous data – the management of this routing does not have apublished API.
As a result, we will not be covering the published classesrelating to synchronous links, as they offer nothing of general use.At present there are no APIs that refer to the ACL logical transport perse; however, to influence the choice of ACL packets that the physical linkmay carry, see section 4.2.4.4.2.4 Physical Link and Physical ChannelWhile there is no particular need to understand the physical channelconcept when implementing applications in Symbian OS, it is highlyrecommended for applications using Bluetooth to consider the physicallink over which they are running.Physical link controlOne of they key features of Bluetooth as a technology is that it is designedwith battery efficiency in mind; far more so that, say, the 802.11 familyof standards (aka wireless LAN).Each Bluetooth service has a responsibility to use the physical link ina manner that considers battery life.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
