QContactManager Class ReferenceThe QContactManager class provides an interface which allows clients with access to contact information stored in a particular backend. More... #include <QContactManager> Inherits QObject. Public Types
Public Functions
Signals
Static Public Members
Additional Inherited Members
Detailed DescriptionThe QContactManager class provides an interface which allows clients with access to contact information stored in a particular backend. This class provides an abstraction of a datastore or aggregation of datastores which contains contact information. It provides methods to retrieve and manipulate contact information, contact relationship information, and supported schema definitions. It also provides metadata and error information reporting. The functions provided by QContactManager are purely synchronous; to access the same functionality in an asynchronous manner, clients should use the use-case-specific classes derived from QContactAbstractRequest. Some functionality provided by QContactManager directly is not accessible using the asynchronous API; see the synchronous and asynchronous API information from the contacts module API documentation. Member Type Documentation
|
Constant | Value | Description |
---|---|---|
QContactManager::NoError | 0 | The most recent operation was successful |
QContactManager::DoesNotExistError | 1 | The most recent operation failed because the requested contact or detail definition does not exist |
QContactManager::AlreadyExistsError | 2 | The most recent operation failed because the specified contact or detail definition already exists |
QContactManager::InvalidDetailError | 3 | The most recent operation failed because the specified contact contains details which do not conform to their definition |
QContactManager::InvalidRelationshipError | 4 | The most recent operation failed because the specified relationship is circular or references an invalid local contact |
QContactManager::InvalidContactTypeError | 14 | The most recent operation failed because the contact type specified was not valid for the operation |
QContactManager::LockedError | 5 | The most recent operation failed because the datastore specified is currently locked |
QContactManager::DetailAccessError | 6 | The most recent operation failed because a detail was modified or removed and its access method does not allow that |
QContactManager::PermissionsError | 7 | The most recent operation failed because the caller does not have permission to perform the operation |
QContactManager::OutOfMemoryError | 8 | The most recent operation failed due to running out of memory |
QContactManager::VersionMismatchError | 12 | The most recent operation failed because the backend of the manager is not of the required version |
QContactManager::LimitReachedError | 13 | The most recent operation failed because the limit for that type of object has been reached |
QContactManager::NotSupportedError | 9 | The most recent operation failed because the requested operation is not supported in the specified store |
QContactManager::BadArgumentError | 10 | The most recent operation failed because one or more of the parameters to the operation were invalid |
QContactManager::UnspecifiedError | 11 | The most recent operation failed for an undocumented reason |
This enum describes the possible features that a particular manager may support
Constant | Value | Description |
---|---|---|
QContactManager::Groups | 0 | The manager supports saving contacts of the QContactType::TypeGroup type |
QContactManager::ActionPreferences | 1 | The manager supports saving preferred details per action per contact |
QContactManager::DetailOrdering | 5 | When a contact is retrieved, the manager will return the details in the same order in which they were saved |
QContactManager::Relationships | 3 | The manager supports at least some types of relationships between contacts |
QContactManager::ArbitraryRelationshipTypes | 4 | The manager supports relationships of arbitrary types between contacts |
QContactManager::MutableDefinitions | 2 | The manager supports saving, updating or removing detail definitions. Some built-in definitions may still be immutable |
QContactManager::SelfContact | 6 | The manager supports the concept of saving a contact which represents the current user |
QContactManager::ChangeLogs | 8 | The manager supports reporting of timestamps of changes, and filtering and sorting by those timestamps |
QContactManager::Anonymous | 7 | The manager is isolated from other managers |
Constructs a QContactManager whose implementation is identified by managerName with the given parameters.
The parent QObject will be used as the parent of this QContactManager.
If an empty managerName is specified, the default implementation for the platform will be used.
Constructs a QContactManager whose backend has the name managerName and version implementationVersion, where the manager is constructed with the provided parameters.
The parent QObject will be used as the parent of this QContactManager.
If an empty managerName is specified, the default implementation for the platform will be instantiated. If the specified implementation version is not available, the manager with the name managerName with the default implementation version is instantiated.
Constructs a QContactManager whose parent QObject is parent. The default implementation for the platform will be created.
Frees the memory used by the QContactManager
Returns a list of available manager ids that can be used when constructing a QContactManager. If an empty id is specified to the constructor, the first value in this list will be used instead.
Returns a URI that completely describes a manager implementation, datastore, and the parameters with which to instantiate the manager, from the given managerName, params and an optional implementationVersion. This function is generally useful only if you intend to construct a manager with the fromUri() function, or wish to set the manager URI field in a QContactId manually (for synchronization or other purposes). Most clients will not need to use this function.
Returns a pruned or modified version of the original contact which is valid and can be saved in the manager. The returned contact might have entire details removed or arbitrarily changed. The cache of relationships in the contact are ignored entirely when considering compatibility with the backend, as they are saved and validated separately.
Returns the contact in the database identified by contactId.
If the contact does not exist, an empty, default constructed QContact will be returned, and the error returned by error() will be QContactManager::DoesNotExistError.
The fetchHint parameter describes the optimization hints that a manager may take. If the fetchHint is the default constructed hint, all existing details, relationships and action preferences in the matching contact will be returned. If a client makes changes to an contact which has been retrieved with a fetch hint, they should save it back using a partial save, masked by the same set of detail names in order to avoid information loss.
See also QContactFetchHint.
Return the list of contact ids, sorted according to the given list of sortOrders
Returns a list of contact ids that match the given filter, sorted according to the given list of sortOrders. Depending on the backend, this filtering operation may involve retrieving all the contacts.
Returns the list of contacts stored in the manager sorted according to the given list of sortOrders.
The fetchHint parameter describes the optimization hints that a manager may take. If the fetchHint is the default constructed hint, all existing details, relationships and action preferences in the matching contact will be returned. If a client makes changes to an contact which has been retrieved with a fetch hint, they should save it back using a partial save, masked by the same set of detail names in order to avoid information loss.
See also QContactFetchHint.
Returns a list of contacts that match the given filter, sorted according to the given list of sortOrders.
Depending on the manager implementation, this filtering operation might be slow and involve retrieving all the contacts and testing them against the supplied filter - see the isFilterSupported() function.
The fetchHint parameter describes the optimization hints that a manager may take. If the fetchHint is the default constructed hint, all existing details, relationships and action preferences in the matching contact will be returned. If a client makes changes to an contact which has been retrieved with a fetch hint, they should save it back using a partial save, masked by the same set of detail names in order to avoid information loss.
See also QContactFetchHint.
Returns a list of contacts given a list of local ids (localIds).
Returns the list of contacts with the ids given by localIds. There is a one-to-one correspondence between the returned contacts and the supplied localIds.
If there is an invalid id in localIds, then an empty QContact will take its place in the returned list. The deprecated errorMap parameter can be supplied to store per-input errors in. In all cases, calling errorMap() will return the per-input errors for the latest batch function.
The fetchHint parameter describes the optimization hints that a manager may take. If the fetchHint is the default constructed hint, all existing details, relationships and action preferences in the matching contact will be returned. If a client makes changes to an contact which has been retrieved with a fetch hint, they should save it back using a partial save, masked by the same set of detail names in order to avoid information loss.
See also QContactFetchHint.
This signal is emitted at some point once the contacts identified by contactIds have been added to a datastore managed by this manager. This signal must not be emitted if the dataChanged() signal was previously emitted for these changes.
This signal is emitted at some point once the contacts identified by contactIds have been modified in a datastore managed by this manager. This signal must not be emitted if the dataChanged() signal was previously emitted for these changes.
This signal is emitted at some point once the contacts identified by contactIds have been removed from a datastore managed by this manager. This signal must not be emitted if the dataChanged() signal was previously emitted for these changes.
This signal is emitted by the manager if its internal state changes, and it is unable to determine the changes which occurred, or if the manager considers the changes to be radical enough to require clients to reload all data. If this signal is emitted, no other signals will be emitted for the associated changes.
Returns the definition identified by the given definitionName that is valid for the contacts whose type is the given contactType in this store, or a default-constructed QContactDetailDefinition if no such definition exists
Returns a map of identifier to detail definition for the registered detail definitions which are valid for contacts whose type is the given contactType which are valid for the contacts in this store
Return the error code of the most recent operation. For batch operations, if the error code is not equal to QContactManager::NoError, detailed per-input errors may be retrieved by calling errorMap().
See also errorMap().
Returns per-input error codes for the most recent operation. This function only returns meaningful information if the most recent operation was a batch operation. Each key in the map is the index of the element in the input list for which the error (whose error code is stored in the value for that key in the map) occurred during the batch operation.
See also error(), contacts(), saveContacts(), removeContacts(), saveRelationships(), and removeRelationships().
Constructs a QContactManager whose implementation version, manager name and specific parameters are specified in the given managerUri, and whose parent object is parent.
Returns true if the given feature feature is supported by the manager, for the specified type of contact contactType
Returns true if the given filter is supported natively by the manager, and false if the filter behaviour would be emulated.
Note: In some cases, the behaviour of an unsupported filter cannot be emulated. For example, a filter that requests contacts that have changed since a given time depends on having that information available. In these cases, the filter will fail.
Returns true if the manager supports the relationship type specified in relationshipType for contacts whose type is the given contactType.
Note that some managers may support the relationship type for a contact in a limited manner (for example, only as the first contact in the relationship, or only as the second contact in the relationship). In this case, it will still return true. It will only return false if the relationship is entirely unsupported for the given type of contact.
Returns the manager name for this QContactManager
Return the parameters relevant to the creation of this QContactManager
Return the uri describing this QContactManager, consisting of the manager name and any parameters.
Returns the engine backend implementation version number
Splits the given uri into the manager, store, and parameters that it describes, and places the information into the memory addressed by pManagerId and pParams respectively. Returns true if uri could be split successfully, otherwise returns false
Returns a list of relationships in which the contact identified by the given participantId participates in the given role. If participantId is the default-constructed id, role is ignored and all relationships are returned.
Returns a list of relationships of the given relationshipType in which the contact identified by the given participantId participates in the given role. If participantId is the default-constructed id, role is ignored and all relationships of the given relationshipType are returned. If relationshipType is empty, relationships of any type are returned.
This signal is emitted at some point after relationships have been added to the manager which involve the contacts identified by affectedContactIds. This signal must not be emitted if the dataChanged() signal was previously emitted for these changes.
This signal is emitted at some point after relationships have eben removed from the manager which involve the contacts identified by affectedContactIds. This signal must not be emitted if the dataChanged() signal was previously emitted for these changes.
Remove the contact identified by contactId from the database, and also removes any relationships in which the contact was involved. Returns true if the contact was removed successfully, otherwise returns false.
Remove every contact whose id is contained in the list of contacts ids contactIds. Returns true if all contacts were removed successfully, otherwise false.
Any contact that was removed successfully will have the relationships in which it was involved removed also.
The deprecated errorMap parameter can be supplied to store per-input errors in. In all cases, calling errorMap() will return the per-input errors for the latest batch function. The QContactManager::error() function will only return QContactManager::NoError if all contacts were removed successfully.
If the given list of contact ids contactIds is empty, the function will return false and calling error() will return QContactManager::BadArgumentError. If the list is non-empty and contains ids which do not identify a valid contact in the manager, the function will remove any contacts which are identified by ids in the contactIds list, insert QContactManager::DoesNotExist entries into the errorMap for the indices of invalid ids in the contactIds list, return false, and set the overall operation error to QContactManager::DoesNotExistError.
See also QContactManager::removeContact().
Removes the detail definition identified by definitionName from the database, which is valid for contacts whose type is the given contactType. Returns true if the definition was removed successfully, otherwise returns false
Removes the given relationship from the manager. If the relationship exists in the manager, the relationship will be removed, the error will be set to QContactManager::NoError and this function will return true. If no such relationship exists in the manager, the error will be set to QContactManager::DoesNotExistError and this function will return false.
Removes the given relationships from the database and returns true if the operation was successful. The deprecated errorMap parameter can be supplied to store per-input errors in. In all cases, calling errorMap() will return the per-input errors for the latest batch function.
Adds the given contact to the database if contact has a default-constructed id, or an id with the manager URI set to the URI of this manager and a local id of zero.
If the manager URI of the id of the contact is neither empty nor equal to the URI of this manager, or local id of the contact is non-zero but does not exist in the manager, the operation will fail and calling error() will return QContactManager::DoesNotExistError.
Alternatively, the function will update the existing contact in the database if contact has a non-zero id and currently exists in the database.
If the contact contains one or more details whose definitions have not yet been saved with the manager, the operation will fail and calling error() will return QContactManager::UnsupportedError.
If the contact has had its relationships reordered, the manager will check to make sure that every relationship that the contact is currently involved in is included in the reordered list, and that no relationships which either do not involve the contact, or have not been saved in the manager are included in the list. If these conditions are not met, the function will return false and calling error() will return QContactManager::InvalidRelationshipError.
Returns false on failure, or true on success. On successful save of a contact with an id of zero, its id will be set to a new, valid id with the manager URI set to the URI of this manager, and the local id set to a new, valid local id. The manager will automatically synthesize the display label of the contact when it is saved. The manager is not required to fetch updated details of the contact on save, and as such, clients should fetch a contact if they want the most up-to-date information by calling QContactManager::contact().
See also managerUri().
Adds the list of contacts given by contacts list to the database. Returns true if the contacts were saved successfully, otherwise false.
The deprecated errorMap parameter can be supplied to store per-input errors in. In all cases, calling errorMap() will return the per-input errors for the latest batch function. The QContactManager::error() function will only return QContactManager::NoError if all contacts were saved successfully.
For each newly saved contact that was successful, the id of the contact in the contacts list will be updated with the new value. If a failure occurs when saving a new contact, the id will be cleared.
See also QContactManager::saveContact().
Adds the list of contacts given by contacts list to the database. Returns true if the contacts were saved successfully, otherwise false.
This function accepts a definitionMask, which specifies which details of the contacts should be updated. Details with definition names not included in the definitionMask will not be updated or added.
The deprecated errorMap parameter can be supplied to store per-input errors in. In all cases, calling errorMap() will return the per-input errors for the latest batch function. The QContactManager::error() function will only return QContactManager::NoError if all contacts were saved successfully.
For each newly saved contact that was successful, the id of the contact in the contacts list will be updated with the new value. If a failure occurs when saving a new contact, the id will be cleared.
See also QContactManager::saveContact().
Persists the given definition def in the database, which is valid for contacts whose type is the given contactType. Returns true if the definition was saved successfully, otherwise returns false
Saves the given relationship in the database. If the relationship already exists in the database, this function will return false and the error will be set to QContactManager::AlreadyExistsError. If the relationship is saved successfully, this function will return true and error will be set to QContactManager::NoError. Note that relationships cannot be updated directly using this function; in order to update a relationship, you must remove the old relationship, make the required modifications, and then save it.
The given relationship is invalid if it is circular (the first contact is the second contact), or if it references a non-existent local contact (either the first or second contact). If the given relationship is invalid, the function will return false and the error will be set to QContactManager::InvalidRelationshipError. If the given relationship could not be saved in the database (due to backend limitations) the function will return false and error will be set to QContactManager::NotSupportedError.
Saves the given relationships in the database and returns true if the operation was successful. The deprecated errorMap parameter can be supplied to store per-input errors in. In all cases, calling errorMap() will return the per-input errors for the latest batch function.
Returns the id of the "self" contact which has previously been set. If no "self" contact has been set, or if the self contact was removed from the manager after being set, or if the backend does not support the concept of a "self" contact, an invalid id will be returned and the error will be set to QContactManager::DoesNotExistError.
See also setSelfContactId().
This signal is emitted at some point after the id of the self-contact is changed from oldId to newId in the manager. If the newId is the invalid, zero id, then the self contact was deleted or no self contact exists. This signal must not be emitted if the dataChanged() signal was previously emitted for this change.
Sets the id of the "self" contact to the given contactId. Returns true if the "self" contact id was set successfully. If the given contactId does not identify a contact stored in this manager, the error will be set to QContactManager::DoesNotExistError and the function will return false; if the backend does not support the concept of a "self" contact then the error will be set to QContactManager::NotSupportedError and the function will return false.
See also selfContactId().
Returns the list of contact types which are supported by this manager. This is a convenience function, equivalent to retrieving the allowable values for the QContactType::FieldType field of the QContactType definition which is valid in this manager.
Returns the list of data types supported by the manager
Updates the display label of the supplied contact, according to the formatting rules of this manager.
Different managers can format the display label of a contact in different ways - some managers may only consider first or last name, or might put them in different orders. Others might consider an organization, a nickname, or a freeform label.
This function will update the QContactDisplayLabel of this contact, and the string returned by QContact::displayLabel().
If contact is null, nothing will happen.
See the following example for more information:
/* Retrieve a contact */ QContact c = manager->contact(myId); qDebug() << "Current display label" << c.displayLabel(); /* Update some fields that might influence the display label */ QContactName name = c.detail<QContactName>(); name.setFirstName("Abigail"); name.setLastName("Arkansas"); c.saveDetail(&name); /* Update the display label */ manager->synthesizeContactDisplayLabel(&c); qDebug() << "Now the label is:" << c.displayLabel();
See also synthesizedContactDisplayLabel() and QContact::displayLabel().
Returns a display label for a contact which is synthesized from its details in a manager specific manner.
If you want to update the display label stored in the contact, use the synthesizeContactDisplayLabel() function instead.
See also synthesizeContactDisplayLabel().
The string constant for the parameter key which holds the names of detail definitions. If a manager supports suppressing change signals depending on the value given for this construction parameter, clients can request that signals be suppressed if the changes which might otherwise cause a signal to be emitted, involve details whose definition name is not contained in the given list.
That is, if a detail in a contact is changed, but that detail's definition name is not listed in the value for this parameter, the manager will not emit a change signal for that change.
If this parameter is not specified at construction time, changes to any detail of a contact will cause a change signal to be emitted.
The value of this parameter should be a comma (,) separated list of definition names. Any commas which might be part of a definition name must be escaped with a single backslash () character prior to concatenation. Any backslash character which might be part of a definition name must also be escaped with a backslash.
If the parameter (or value given for the parameter) is not supported by the manager, the manager may still be constructed, however the parameter will not be reported to the client if the client calls managerParameters() subsequent to manager construction.
The string constant for the parameter key which holds the value for signal sources. If a manager supports suppressing change signals depending on the value given for this construction parameter, clients can request that signals be suppressed if the changes which might cause a signal to be emitted do not match particular criteria.
If the parameter (or value given for the parameter) is not supported by the manager, the manager may still be constructed, however the parameter will not be reported to the client if the client calls managerParameters() subsequent to manager construction.
The default (assumed) value for this parameter, if this parameter is not given, is that the client wants to be notified of all changes to the data, regardless of the source of the change.
This value tells the manager to only emit signals for changes which are made in other manager instances. That is, the client wishes to receive change signals when another client (or background service) changes the data as it is stored in the backend, but does not wish to be notified of changes (or side effects) which it has caused itself.
This value tells the manager to only emit signals for changes which are made in other processes. That is, the client wishes to receive change signals when a client (or background service) in another process changes the data as it is stored in the backend, but does not wish to be notified of changes (or side effects) which were caused in the current client's process, even if those changes were made in a different manager instance to this one.