Symbian OS Communications (779884), страница 75
Текст из файла (страница 75)
Unnamed nodes do not have a fixed name, but are used toencapsulate common settings that can have multiple entries. The namegiven to the unnamed node must provide a unique URI to allow itschildren to be addressable within the management tree.Leaf nodes have a fixed name, and have data associated with them,this will typically be the value of the setting.DFFormat – The node format property is the data format of the nodevalue.
The node format values are specified by the OMA and include thefollowing:• b64 – base64 encoded• bin – binary encoded• bool – boolean• chr – text• int – integer• node – interior node• null – null• xml – XML data.In the case of interior nodes, the node format value must be ‘node’.DFType – the DFType property is different for interior and leaf nodes.Leaf nodes – this is the MIME type supported by the leaf node. A leafnode can support more than one MIME type, but they must be registeredMIME types.Interior nodes – for interior nodes the type may be empty, but if a typeis given it must only be one registered MIME type.AccessType – the access type of a node specifies which access commands the node supports.
The available access types are:• Add – add the node• Copy – copy the node to a new location in the management tree• Delete – delete the node and any underlying nodes• Exec – execute the node• Get – get the node value or children• Replace – replace the node value or name.370OMA DEVICE MANAGEMENTDefaultValue – this specifies the default value of the node when it iscreated.Description – a short description of the node where it is felt that moreinformation is useful.The DDF information can be described by an XML document. TheOMA include a framework description to be used for these XML documents in the DTD that is included with the OMA DM specifications.12.3.3 Management ObjectsA management object (MO) is the description of a complete subtreewithin the management tree.
This is typically implemented by a singleDM adapter and described by the DDF structure provided by the DMadapter to the DM framework. To describe the MO in a human readableform, the MO is represented by a diagram and a textual description ofthe DFProperties for the nodes. The diagram of the MO is similar to themanagement tree in its layout as it represents the hierarchy of the nodesonce they are added to the management tree. For the purposes of DMadapters, the MO must start with the root node and describe all otherrelationships within the DDF to this node. Each of the interior nodes canhave ancestors, a parent and children, whilst the leaf nodes can only haveancestors and a parent.
To further describe the layout of the nodes andthe possible structures that will be in the management tree, each nodemust adhere to the following rules:• Unnamed nodes are represented by a lower case x• Occurrences are represented as follows:+ one or many* zero or more? zero or one.If no occurrence character is given then the default occurrence of onemust be used.Figure 12.3 shows the diagram for an MO of the CommsBook2ndEdsubtree from Figure 12.2.In this example, there can be zero or more occurrences of the unnamednode x , but all occurrences must provide a unique URI within themanagement tree.
For example, if a new account was to be created,the DM server could add a new node under./CommsBook2ndEd calledAccount1: under this node the leaf nodes Setting1 and Setting2 willalways exist but the Setting3 node may or may not exist. Each time a DMserver accesses the settings under Account1 it will reference the nodeusing the full URI, so to access Setting1 the DM server would use theURI./CommsBook2ndEd/Account1/Setting1. If the DM server created asecond unnamed node Account2, the settings accessed using this nodeOMA DEVICE MANAGEMENT ESSENTIALSSymbianOSCommsProgramming2<x>*371Setting1Setting2Setting3?Figure 12.3 An example MOname in the URI would be stored separately to those of Account1 andtherefore are separate to those under the Account1 node.
To complete theMO, each node of the MO is described and their DFProperties are listedwith the supported values/actions. So the DFProperties for this examplemight be:./CommsBook2ndEd• Scope = permanent• Occurrence = one• DFFormat = node• AccessType = Get• Default Value =• Description =./CommsBook2ndEd/<x>*• Scope = dynamic• Occurrence = zero or more• DFFormat = node• AccessType = Add, Delete, Get, Replace• Default Value =• Description =./CommsBook2ndEd/<x>*/Setting1• Scope = dynamic• Occurrence = one372OMA DEVICE MANAGEMENT• DFFormat = chr• DFType: MIME = text/plain• AccessType = Get, Add, Replace• Default Value =• Description =./CommsBook2ndEd/<x>*/Setting2• Scope = dynamic• Occurrence = one• DFFormat = chr• DFType: MIME = text/plain• AccessType = Get, Add, Replace• Default Value =• Description =./CommsBook2ndEd/<x>*/Setting3?• Scope = dynamic• Occurrence = zero or one• DFFormat = chr• DFType: MIME = text/plain• AccessType = Get, Add, Replace, Delete• Default Value =• Description =12.4The Example DM AdapterThe example DM adapter that is included in the code accompanyingthis book allows a DM server to manipulate the settings of the XMPPapplication provided as an example for chapter 6.
The information provided within this section of the chapter details some of the APIs that areimplemented by the DM adapter and by the DM framework. For moreinformation on these APIs and the other APIs available, please see theSymbian OS Library.THE EXAMPLE DM ADAPTER373The first task when starting a new DM adapter is to determine whatsettings are going to be needed, and what the occurrences of thesesettings will be.
This is required for the creation of the MO. For the XMPPapplication it has been identified that there are seven settings that the DMserver can manipulate. These are:• DomainName• UserName• Password• ResourceName• Language• ConRef• UseTLS.For information on these settings see the example code for chapter 6.The occurrence for these settings will be one as they always exist whena new account for the XMPP is created.
There is one special case here,the ConRef leaf node, which represents a link to a network access point(NAP) within the management tree. In this case the data given is the URIto the NAP in the DM tree. As access points are not DM aware, this URImust be translated to the value that is used to reference the desired accesspoint. This also allows an existing NAP to be used rather than creatingnew settings for each new XMPP account (or any of the other MOs on thedevice).
The value passed to the node can either be the URI of an existingNAP account, or if the keyword INTERNET is used then the default NAPaccount must be used. Note that the default NAP account does not haveto be explicitly set, as this may be changed at any time by the user.Finally, as there can be more than one account for the XMPP application, there needs to be an unnamed node to allow the settings to beencapsulated for each account. The occurrence of this unnamed node iszero or more.The MO for this DM adapter is as shown in Figure 12.4.12.4.1 DFProperties./CommsBook2ndEd• Scope = permanent.
This node will always exist in the managementtree (whilst the DM adapter is on the device) and cannot be changed,therefore the scope is permanent.• Occurrence = one. There will only ever be one of these nodes and itmust exist.374OMA DEVICE MANAGEMENTSymbianOSCommsProgramming2<x>*DomainNameUserNamePasswordResourceNameLanguageConRefTLSFigure 12.4 The Symbian OS Comms Programming 2 MO• DFFormat = node. This is an interior node.• AccessType = Get.
It is not possible for permanent nodes to bechanged in any way and so Get is the only valid command for thisnode.• Default Value =• Description =./CommsBook2ndEd/<x>*• Scope = dynamic. This node will not always exist in the managementtree and is therefore dynamic and not permanent.• Occurrence = zero or more. It is possible for there to be no accountsfor the XMPP application or multiple accounts and so this node hasan occurrence of zero or more.• DFFormat = node• AccessType = Add, Delete, Get, Replace. This node can be added tocreate a new account, or deleted to delete an entire account. A Get onTHE EXAMPLE DM ADAPTER375this node will return a list of its child nodes.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
