Symbian OS Communications (779884), страница 74
Текст из файла (страница 74)
The client can customizeand query the list of filters either using RHTTPFilterCollection,or the TFilterConfigurationIterator to add new, or removeexisting, filters.11.13.1 Writing a FilterFilters must be derived from MHttpFilter interface:class MHTTPFilter : public MHTTPFilterBase{public:IMPORT_C virtual void MHFUnload(RHTTPSession aSession, THTTPFilterHandleaHandle);IMPORT_C virtual void MHFLoad(RHTTPSession aSession, THTTPFilterHandleaHandle);public:enum TPositions{EProtocolHandler = 0,ECache = 100,EStatusCodeHandler = 200,EUAProf = 250,ECookies = 300,ETidyUp = 400,EClientFilters = 500,EClient = 1000};};To register, call AddFilter() on the RHTTPFilterCollectionretrieved from the RHTTPSession passed in MHFLoad().
This will addyour filter to the filter queue in a specific position. The position of thefilter is specified as a parameter. It must be a number between 0 and1000 which determines where the filter will be placed between the clientat one end and the protocol handler at the other. Care should be takenas position affects the behavior. For example, if two filters act upon thebody data which one comes first is important.Filters can register for the following properties:1. Occurrence of an event : filters can listen for a specific event orall transaction events (EAnyTransactionEvent, or use EAll toinclude session events). If a filter is interested in several events, itmust register separately for each one.364HTTP2.Presence of a header : a filter may also be interested in a specificheader being present, e.g.
SetCookie, for a cookie filter.3.StatusCode returned by the server, e.g. the redirection filter registers for the 3xx status codes (300–304 and 307 to be specific).When the event for which the filter is registered occurs, the filter’s MHFRunL() will be called. Each filter’s MHFRunL() is calledin the order that the filters are registered. At this point your filter’sprocessing can take place.
It works in a similar fashion to MTransactionCallback::MHFRunL(). In fact the MTransactionCallbackimplementation can be regarded as the last filter in the queue, which hasregistered for all incoming events.11.14SummaryIn this chapter we have learnt about:• HTTP sessions and transactions, and what features are and are notsupported by the HTTP framework• creating and submitting transactions to the HTTP framework• sending body data as part of a request, and receiving it as part ofa response• monitoring the state and progress of a transaction• use of the Stringpool to store and access common strings• how to get the HTTP framework to use a proxy• how to implement cache and cookie support in the HTTP framework• how to use filters that need explicit installation into the framework,such as the authentication filter• options the HTTP framework provides for improving performance,particularly over high-latency connections• how to create our own filters to modify and extend the behaviour ofthe HTTP stack.12OMA Device Management12.1 IntroductionThis chapter introduces the reader to the Symbian implementation of theOpen Mobile Alliance (OMA) Device Management (DM) specification.
Itis not intended as a comprehensive guide to the specification, but doescover aspects that are relevant to developers who wish to add plug-insto the Symbian OS DM framework. At the time of writing, the frameworkplug-in (DM adapter) information contained within this chapter and thecompanion code is based on a prototype interface. This interface is dueto be published in v9.3 of Symbian OS, and although all possible carehas been taken to ensure that the information will remain accurate, it ispossible that the interface may be subject to change prior to its release.Not all Symbian OS-based devices will include the Symbian DM solutioninitially; in particular, S60 currently have an independent solution – moredetails about their implementation, including details for creating DeviceManagement adapters, can be found on the Forum Nokia website.The DM protocol was originally created by the SyncML InitiativeLtd as a standardized means of managing remote devices.
The SyncMLInitiative was formed as a not-for-profit corporation to produce an openspecification for device management and data synchronization. Prior tothe formation of the SyncML Initiative both device management and datasynchronization were performed using a variety of proprietary protocolsthat operated on a limited number of devices and with limited supportby remote servers. Due to the nature of these proprietary protocols thesupport for device management on mobile devices was fragmented andnon-interoperable.In 2002 the SyncML Initiative was integrated into the OMA, and thestandardization effort for both device management and data synchronization has continued within the OMA. The OMA standardization effortbrings together representatives from a wide variety of companies such366OMA DEVICE MANAGEMENTas mobile device manufacturers, server vendors, operators and softwarecompanies collaborating on the standard to encompass as many industryaspects as possible.Device management provides an over-the-air (OTA) method of remotely managing the settings, applications and firmware of a mobiledevice and accessing diagnostic information.
Updating the firmwareOTA reduces the time to market by allowing firmware updates to beperformed once the end user has the device, rather than in the factory.Support costs for operators are reduced by enabling operators to accesssettings and diagnostics information on the device during a support callwith the end user, without the need to return the device to a supportcentre. Operators can also update applications on devices or installapplications to provide the end user with access to new services as theybecome available.
Finally, enterprises can use device management tomanage the large numbers of devices they are providing to their users.For these reasons, interest in device management has recently startedto grow as the advantages are being recognized.Currently, the OMA device management specification is at revision1.2, and this is the revision supported by Symbian OS v9.2 onwards. OMAdevice management v1.1.2 is supported in Symbian OS v8.0 to v9.1.
Moreinformation on OMA device management and the specification documents can be found on the OMA website, www.openmobilealliance.org.The following sections of this chapter look at the OMA device management specification, the Symbian frameworks that implement the OMAspecification and how to extend the framework by writing a DM adapterto allow DM servers to manage the settings of applications.12.2Device Management In Symbian OSThe OMA specification consists of shared components for both devicemanagement and data synchronization and therefore the Symbian OSarchitecture consists of separate frameworks for device management anddata synchronization, and a single framework that handles the commonaspects of the standard.
This can be seen in Figure 12.1.The SyncML framework handles the connections to remote serversvia various transport mechanisms and the encoding/decoding of the datatransmissions to the XML-based OMA protocols. The use of the SyncMLname is due to the original implementation being created before the OMAtook over the standardization effort.
The device management and datasynchronization frameworks provide APIs which the SyncML frameworkutilizes to pass commands received in the data transmissions. Once thecommands are passed from the SyncML framework to the DM framework,they are queued before being handled. Before the commands are passedOMA DEVICE MANAGEMENT ESSENTIALSTransportConnectiontransports367SyncMLframeworkDM ServerDatasynchronizationframeworkDevicemanagementframeworkDevicemanagementadaptersSettingsStoresFigure 12.1 A high-level overview of the Symbian OS DM frameworkto a specific handler (i.e., a DM adapter), they are first validated to ensurethat they can be actioned and that the server requesting the commandhas the correct access rights for the command.For maximum flexibility the DM framework utilizes ECOM plug-insto extend the support for different settings.
Plug-ins, referred to as DMadapters, are used to provide an translation layer between the OMAdevice management-based API, used by the DM framework, and theunderlying data store. This allows the DM framework to be extendedto support new settings, without changes to the DM framework codeitself. To reduce the complexity of the DM adapters, the DM frameworkalso deals with commands on the run-time properties (RTProperties) anddescription properties (DFProperties) from the DM server (these will beexplained in more detail later in the chapter). Commands on RTPropertiesand DFProperties are not dependant on the underlying data value, anddo not affect the data itself, but provide the DM server with informationabout the setting.12.3 OMA Device Management EssentialsA DM adapter does not have knowledge of the OMA DM specification,but some knowledge of the specification is essential to implementing anadapter correctly.
The following sections of the chapter introduce thereader to elements of the OMA DM specification.368OMA DEVICE MANAGEMENT12.3.1 Management TreeThe management tree is used to store settings, which are organizedinto management objects (more on these later) into a hierarchal treestructure. Settings can be addressed using uniform resource identifiers(URIs). The management tree consists of different types of nodes that formthe individual representations of each management object.
This allowseach setting to be uniquely addressed within the management tree. Allmanagement objects within the management tree are addressed fromthe root node (‘.’), and are delimited by ‘/’. So given the example treeshown in Figure 12.2, to address the node Setting1, the full URI wouldbe ‘./CommsBook2ndEd/Example/Setting1’.The management tree store contains information about the known URIsfor the DM adapters, and this is utilized when validating and handlingproperty commands from DM servers. The layout of the management treeis determined from the device description framework (DDF) that the DMadapters provide, and from the underlying data that is stored.12.3.2 Device Description FrameworkThe DDF holds meta-information about the management tree, the allowable layout of the management tree, and the scope, format, accessibility,etc.
of each of the nodes within the management tree. Although the DMframework handles DM commands for DFProperties, the DM adaptersmust provide the DFProperty information for their management object.The following is a short description of the DFProperties.Scope – there are two options for the scope of a node: permanent ordynamic. Permanent nodes are those that are guaranteed to exist in themanagement tree; dynamic nodes cannot be guaranteed to exist. It is notpermissible for a permanent node to be a child of a dynamic node./CommsBook2ndEdDMAccExampleSetting1Setting2SyncMLDevInfoDSAccSetting3Figure 12.2 An example management treeOMA DEVICE MANAGEMENT ESSENTIALS369DFTitle – this is the human readable name of the node, and is used inthe management tree. There are two types of nodes: interior node andleaf node.Interior nodes are either nodes that have a fixed name or they can beunnamed.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
