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  · 

Qt Contacts Schema

Introduction

The Qt Contacts API makes use of detail leaf classes which provide certain well-known functionality. In order to develop a backend engine which can service clients or provide synchronization to other backends, the schema must be known. The schema provided by the Qt Contacts API is updated with every release of Qt Mobility, so the function which returns the default schema definitions can take an integer which identifies the schema version which the engine writer developed against. Engine writers should call schemaDefinitions() in their code which generates the manager-specific schema (which is returned to clients when they call QContactManager::detailDefinitions()).

The schemaDefinitions() function should NOT be called by clients; rather, clients should call QContactManager::detailDefinitions() instead.

Schema Definition

Different backends have different capabilities. Some backends may not be able to implement certain definitions in the default schema (for example, some backends might not have support for storing location information), while other backends may not be able to implement some aspects of a particular definition in the default schema (for example, a logo field for organization details).

In order to be useful for clients, however, all backends should attempt to support the default schema. Furthermore, no backend should support a schema definition of a modified form where those modifications change the semantics of the data. A client should be able to request details of the QContactPhoneNumber type (that is, details whose definition name is "PhoneNumber") with reasonable certainty that the data returned is a phone number.

By implementing the default schema, the backend developer ensures that client code written against the default schema will work without source modification against their backend.

Default Schema

The leaf details that form the current version of the default schema are as follows:

QContactAddress

Contains an address of a contact

QContactAnniversary

Contains an anniversary of a contact

QContactAvatar

Contains avatar URLs of a contact

QContactBirthday

Contains a birthday of a contact

QContactDisplayLabel

The (possibly synthesized) display label of a contact

QContactEmailAddress

Contains an email address of a contact

QContactFamily

Contains names of family members of a contact

QContactFavorite

Indicates if a contact is a favorite contact as well as the position it should appear in an ordered list of favorites

QContactGender

Contains the gender of a contact

QContactGeoLocation

Contains a global location coordinate associated with a contact

QContactGlobalPresence

Aggregated presence information for a contact, synthesized or supplied by the backend

QContactGuid

Contains a globally unique Id of a contact, for use in synchronization with other datastores

QContactHobby

Contains a hobby of the contact

QContactName

Contains a name of a contact

QContactNickname

Contains a nickname of a contact

QContactNote

Contains a note associated with a contact

QContactOnlineAccount

Online account, which the contact uses to communicate with friends and family

QContactOrganization

Details about an organization that the contact is either a part of, or stands for

QContactPhoneNumber

Phone number of a contact

QContactPresence

Presence information for an online account of a contact

QContactRingtone

Ringtone associated with a contact

QContactSyncTarget

Sync target for a contact

QContactTag

Contains a tag associated with a contact

QContactThumbnail

Contains a thumbnail used in display lists to represent the contact

QContactTimestamp

Contains the creation and last-modified timestamp associated with the contact

QContactType

Describes the type of the contact

QContactUrl

Contains a url associated with a contact

Note that the following leaf details were added to the default schema in version 1.1 of the Qt Mobility project:

Detail Definition Uniqueness

A uniqueness constraint on a detail definition means that for any QContact, only one detail of that definition may be saved.

The leaf classes which have a uniqueness constraint in the default schema are as follows:

Detail Access Constraints

Some details in a contact retrieved from a manager may have access constraints set. An access constraint on a detail means that the detail may not be removed (if the access constraint is QContactDetail::Irremovable) or updated (if the access constraint is QContactDetail::ReadOnly) by the client. If the client attempts to save an updated version of a read-only detail in a contact, or remove a detail which is irremovable from a contact, the operation will succeed; however those updates to the contact will be ignored by the manager when the contact is saved there.

For example, the QContactDisplayLabel is defined in the default schema as a read-only, irremovable detail, meaning that it may not be modified or deleted by the client, but are provided by the backend (in the case of QContactDisplayLabel, automatically synthesized by the backend from various details of the contact, like the QContactName, QContactNickname, etc).

There are three possible detail access constraints: read-only, irremovable and no constraint. A read-only constraint ensures that clients cannot modify the values stored in such details in the persistent copy of the contact (that is, the contact as it is stored in the manager); the irremovable constaint ensures that a particular detail may not be removed by clients. In general, most details which are read only will also be irremovable, and vice versa. One exception to this is the QContactType detail, which is irremovable but may be updated by clients as desired. Details with no constraint may be added, updated and removed as desired by the client. Changes to such details in a contact will be persisted in the manager when the client calls QContactManager::saveContact().

Please see the documentation of QContactDetail for more information on access constraints.

The leaf classes which have access constraints in the default schema are as follows:

Furthermore, in the default schema, every contact is required to have at least two details by default: a QContactType which describes the type of entity that the contact represents (for example, a person or a group), and a QContactDisplayLabel which holds the default display label for the contact.

Backend-provided Details

As described in the section on detail access constraints, some details are provided by the backend, such as QContactDisplayLabel and QContactPresence. When the client attempts to save a QContact that contains these details, these details will be ignored by the backend (since any values in this field are synthesized by the backend). This means that while clients may (for example) add a QContactPresence detail to a QContact, it will not be persisted in the manager when the client attempts to save that contact.

Precisely which details are backend-provided is backend specific; some backends provide more details than others.

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 68
  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. BlackBerry 10 : premières images du prochain OS de RIM qui devrait intégrer des widgets et des tuiles inspirées de Windows Phone 0
  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. La rubrique PyQt/PySide a besoin de vous ! 0
Page suivante

Le blog Digia au hasard

Logo

Créer des applications avec un style Metro avec Qt, exemples en QML et C++, un article de Digia Qt traduit par Thibaut Cuvelier

Le blog Digia est l'endroit privilégié pour la communication sur l'édition commerciale de Qt, où des réponses publiques sont apportées aux questions les plus posées au support. 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