Viadeo Twitter Google Bookmarks ! Facebook Digg del.icio.us MySpace Yahoo MyWeb Blinklist Netvouz Reddit Simpy StumbleUpon Bookmarks Windows Live Favorites 
Logo Documentation Qt ·  Page d'accueil  ·  Toutes les classes  ·  Toutes les fonctions  ·  Vues d'ensemble  · 

Publish and Subscribe

The Publish and Subscribe API enables applications to read item values, navigate through and subscribe to change notifications.

Namespace

The QtMobility APIs are placed into the QtMobility namespace. This is done to facilitate the future migration of Mobility APIs into Qt. See the Quickstart guide for an example on how the namespace impacts on application development.

Overview

The Qt Value Space unifies various sources of hierarchical data into a single consistent model. Conceptually the Value Space is a hierarchical tree of which each node or leaf can optionally contain a QVariant value. A serialized version of a simple example Value Space might look like this.

 /Device/Buttons = 3
 /Device/Buttons/1/Name = Menu
 /Device/Buttons/1/Usable = true
 /Device/Buttons/2/Name = Select
 /Device/Buttons/2/Usable = false
 /Device/Buttons/3/Name = Back
 /Device/Buttons/3/Usable = true

Existing values within the Value Space are accessed through the QValueSpaceSubscriber class. This class provides a means to read values, receive change notifications for a given path and navigate through the Value Space.

New values are added to the Value Space via the QValueSpacePublisher class. This class allows applications to publish values and receive interest notifications when applications connect to a path. Interest notifications can be used to refrain from updating values in the Value Space when there are no interested parties.

Nodes in the Value Space can be thought of as representing schema objects. Obviously this is a conceptual differentiation and not a physical one, as internally the Value Space is treated as one large tree. By applying structured schema to the space "explore-ability" is increased. For example, the /Device/Buttons schema can be defined as containing a value representing the number of mappable buttons on a device, and a sub-item for each adhering to the MappableButton schema. The MappableButton schema itself may be defined as containing two attributes Name and Usable. Change notification is modeled in this fashion also. Were the /Device/Buttons/1/Name item to change, the /Device/Buttons/1 item would also be marked as changed, and so on up the tree. This allows, for example, subscribers to /Device/Buttons to be notified when anything "button" related changes.

Internally, the Value Space consists of an arbitrary number of data source trees, or layers, which are stacked on top of each other to form the final unified view. If a "higher" layer contains an item, it shadows the value of items in the layers below it. Consider the Value Space item /Device/Buttons. If two layers contained this item, the value in the layer with the higher layer order would shadow that with the lower layer order. However, if only the layer with the lower order contained this item, it would be visible through the QValueSpaceSubscriber class, even if the higher order layer contained sub-items such as /Device/Buttons/1. That is, layer shadowing occurs by value not by path.

Layer order is fixed and is defined in the layer implementation.

The following Value Space layers are available:

LayerDescription

Shared Memory Layer

The Shared Memory layer provides a non-permanent Value Space backing store using shared memory and local sockets. The Shared Memory layer is only available on Unix platforms.

The Shared Memory layer has an order of 0x10000000.

Volatile Registry Layer

The Volatile Registry layer provides a non-permanent Value Space backing store using volatile keys stored in the Windows' registry. The Volatile Registry layer is only available on Windows platforms.

The Volatile Registry layer has an order of 0x1000.

Non-volatile Registry Layer

The Non-volatile Registry layer provides a permanent Value Space backing store using keys stored in the Windows' registry. The Non-volatile Registry layer is only available on Windows platforms. The Non-volatile Registry layer has an order of 0.

ContextKit Layer

The ContextKit layer provides a non-permanent Value Space backing store using ContextKit. Publishing values to this layer via QValueSpacePublisher is currently not supported. The ContextKit layer has an order of 0.

Symbian Settings Layer

The Symbian Settings layer provides a permanent Value Space backing store using the Symbian OS' Properties (RProperty) as well as Central Repository files (CRepository). The Symbian Settings layer has an order of 0.

GConf Layer

The GConf Layer provides a permanent Value Space backing store using the GConf configuration system designed for the GNOME desktop environment. The GConf Layer has an order of 0 and it's the only available layer in Maemo 5.

The Value Space has support for both client/server and peer-to-peer layer architectures. If a layer that uses a client/server architecture is used and a server process is not provided by the underlying system it will be necessary to start one. This can be done by calling QValueSpace::initValueSpaceServer() prior to any other use of the Value Space.

Detailed Layer Descriptions

Shared Memory Layer

The Shared Memory layer stores all values in a 10MB block of shared memory which is reserved when the Value Space server initializes. As the layer creates this region at startup, it is assumed that the operating system lazily commits memory. If this assumption is invalid, the Shared Memory layer will unnecessarily consume 10MB of memory.

Value Space clients read from the Shared Memory layer's shared memory region directly. A kernel lock is acquired for each read to prevent corruption. While the layer supports concurrent readers, it is possible that a faulty or malicious application could acquire and refuse to release this lock causing any layer updates to be delayed indefinitely.

Only the Value Space server ever writes to the shared memory region. When clients attempt to add items to the layer, their changes are transmitted via a QLocalSocket (e.g. /tmp/qt/valuespace_shmlayer domain socket on Unix systems) to the server where the update is performed. Updates are batched in-process and sent when the process re-enters the Qt event loop. Transmission and synchronization of changes can be forced manually by the QValueSpacePublisher::sync() function, although as this requires a round trip between the client and server, doing so frequently may significantly degrade performance.

Change notifications are transmitted to clients in the form of "something has changed" messages. Nodes within the shared memory region are versioned, which allows clients to quickly determine exactly what has changed without the need for a bulkier change notification protocol.

Symbian Settings Layer

Publish and Subscribe API can be used to access Symbian OS' Properties (RProperty) as well as Central Repository files (CRepository).

Declaring Value Space Paths

Since Publish and Subscribe API is based on Value Space that is accessed via textual path we need to somehow specify how particular paths are turned into RPropery or CRepository key definitions. Here the QCRML files come for help.

QCRML files are XML files that can be used to declare available Value Space paths that are visible to the clients. Each path defines whether the actual value is stored in CRepository or RPropery as well as needed Category/Repository/Key UIDs.

The following QCRML file defines Value Space paths for power state properties stored in Symbian OS Properties:

 <?xml version="1.0" encoding="UTF-8"?>
 <repository target="RProperty" uidValue="0x10205041">
     <key ref="/resources/battery/level" int="0x00000001"/>
     <key ref="/resources/battery/status" int="0x00000002"/>
     <key ref="/resources/charging/status" int="0x00000003"/>
 </repository>

The following QCRML file defines a Value Space path for the "current profile id" stored in Central Repository:

 <?xml version="1.0" encoding="UTF-8"?>
 <repository target="CRepository" uidValue="0x101f8798">
     <key ref="/profile/id" int="0x7e000001"/>
 </repository>

The qcrmlgen tool located in the tools directory can be used to create QCRML files.

Location of QCRML Files

All the QCRML files need to be located in \resource\qt\crml directory (in any available drive) in Symbian file system.

In .pro files this means that the files need to be deployed with the SIS package.

Example .pro file section:

 symbian {
     crml.sources = resources.qcrml profile.qcrml
     crml.path = c:/resource/qt/crml
     DEPLOYMENT += crml
 }

Limitations

The underlying Symbian APIs limit the data types that can be stored natively in available backing stores. In practice this is not a problem since the unsupported data types are automatically serialized in QByteArray and stored as 8-bit byte form by SymbianSettingslayer. The serialization/deserialization is transparent operation to the API user but may cause interoperatibility issues with native Symbian codes that access the same data directly. The maximum size of the bytearray is 65535 for RPropery backing store.

GConf Layer

Publish and Subscribe API can be used to access the GConf configuration system.

Limitations

GConf can natively store only a limited set of QVariant data types. These types are Bool, Int, Double, String, StringList and List. When publishing other data types the values are automatically serialized and stored to GConf as BASE64 encoded strings. When reading these values they are automatically converted back to the original data types. The serialization/deserialization is transparent operation to the API user but may cause interoperatibility issues with native applications that access the same data directly.

Examples

Publish and Subscribe

In the example Publish and Subscribe the Value Space is used as a method of communicating changes in one dialog (the publisher) to another dialog (the subscriber).

Battery Charging - Accessing Publish and Subscribe from QML

In the example Accessing Publish and Subscribe from QML the Publish and Subscribe concept is now extended to make the publisher an input of the level of charge in a battery. A slider on the publisher dialog represents the modifiable level of charge. The Value Space acts as a communications medium between the publisher dialog and the subscriber graphical battery animation. The battery is implemented in QML and C++ with Value Space supplying the charge level for the animation to represent.

Namespaces and Classes

QValueSpace

Contains miscellaneous identifiers used throughtout the Publish and Subscribe API

QValueSpacePublisher

Allows applications to publish values in the Value Space

QValueSpaceSubscriber

Allows applications to read and subscribe to Value Space paths

X

Thank you for giving your feedback.

Make sure it is related to this specific page. For more general bugs and requests, please use the Qt Bug Tracker.

[0]; s.parentNode.insertBefore(ga, s); })();
Publicité

Best Of

Actualités les plus lues

Semaine
Mois
Année
  1. « Quelque chose ne va vraiment pas avec les développeurs "modernes" », un développeur à "l'ancienne" critique la multiplication des bibliothèques 94
  2. Apercevoir la troisième dimension ou l'utilisation multithreadée d'OpenGL dans Qt, un article des Qt Quarterly traduit par Guillaume Belz 0
  3. Les développeurs ignorent-ils trop les failles découvertes dans leur code ? Prenez-vous en compte les remarques des autres ? 17
  4. Pourquoi les programmeurs sont-ils moins payés que les gestionnaires de programmes ? Manquent-ils de pouvoir de négociation ? 42
  5. Quelles nouveautés de C++11 Visual C++ doit-il rapidement intégrer ? Donnez-nous votre avis 10
  6. Adieu qmake, bienvenue qbs : Qt Building Suite, un outil déclaratif et extensible pour la compilation de projets Qt 17
  7. 2017 : un quinquennat pour une nouvelle version du C++ ? Possible, selon Herb Sutter 6
Page suivante

Le Qt Labs au hasard

Logo

Le moteur de rendu OpenGL

Les Qt Labs sont les laboratoires des développeurs de Qt, où ils peuvent partager des impressions sur le framework, son utilisation, ce que pourrait être son futur. Lire l'article.

Communauté

Ressources

Liens utiles

Contact

  • Vous souhaitez rejoindre la rédaction ou proposer un tutoriel, une traduction, une question... ? Postez dans le forum Contribuez ou contactez-nous par MP ou par email (voir en bas de page).

Qt dans le magazine

Cette page est une traduction d'une page de la documentation de Qt, écrite par Nokia Corporation and/or its subsidiary(-ies). Les éventuels problèmes résultant d'une mauvaise traduction ne sont pas imputables à Nokia. Qt qtmobility-1.1
Copyright © 2012 Developpez LLC. Tous droits réservés Developpez LLC. Aucune reproduction, même partielle, ne peut être faite de ce site et de l'ensemble de son contenu : textes, documents et images sans l'autorisation expresse de Developpez LLC. Sinon, vous encourez selon la loi jusqu'à 3 ans de prison et jusqu'à 300 000 E de dommages et intérêts. Cette page est déposée à la SACD.
Vous avez déniché une erreur ? Un bug ? Une redirection cassée ? Ou tout autre problème, quel qu'il soit ? Ou bien vous désirez participer à ce projet de traduction ? N'hésitez pas à nous contacter ou par MP !
 
 
 
 
Partenaires

Hébergement Web