1
/****************************************************************************
3
** Copyright (C) 2012 Digia Plc and/or its subsidiary(-ies).
4
** Contact: http://www.qt-project.org/legal
6
** This file is part of the documentation of the Qt PIM Module.
8
** $QT_BEGIN_LICENSE:FDL$
9
** Commercial License Usage
10
** Licensees holding valid commercial Qt licenses may use this file in
11
** accordance with the commercial license agreement provided with the
12
** Software or, alternatively, in accordance with the terms contained in
13
** a written agreement between you and Digia. For licensing terms and
14
** conditions see http://qt.digia.com/licensing. For further information
15
** use the contact form at http://qt.digia.com/contact-us.
17
** GNU Free Documentation License Usage
18
** Alternatively, this file may be used under the terms of the GNU Free
19
** Documentation License version 1.3 as published by the Free Software
20
** Foundation and appearing in the file included in the packaging of
21
** this file. Please review the following information to ensure
22
** the GNU Free Documentation License version 1.3 requirements
23
** will be met: http://www.gnu.org/copyleft/fdl.html.
26
****************************************************************************/
30
\page contactsusage.html
32
\title Qt Contacts API Usage
36
With the Qt Contacts API, typical use cases are:
39
\li Access a list of personal contacts from the contact database
40
supported by the selected backend.
41
\li Sort or filter contacts and access them as a list.
42
\li Import contacts in vCard format into the selected
44
\li Export contacts to a vCard format to share elsewhere.
47
This section provides some examples of common usage of the Qt Contacts API.
49
\section1 Retrieving Contact Details
51
The most common use of the API is to retrieve a contact and then display
52
certain details of that contact. To do so, several steps must be taken:
54
\li A contact manager must be instantiated
55
\li The contact must be retrieved from the manager
56
\li The required details of the contact must be selected from the contact
59
\section2 Instantiating Contact Manager
61
The first step is usually as simple as:
63
QContactManager cm; // instantiate the default manager
66
\section2 Retrieving a Contact from the Manager
68
The second step requires either a filtering operation, or, if the id of the
69
contact is already known, a direct selection operation. If you are interested
70
in all contacts, a \e {default filter} retrieve operation is used. The retrieval
71
operations may either be \l{Qt Contacts Synchronous API}{synchronous} or
72
\l{Qt Contacts Asynchronous API}{asynchronous}; we recommend using asynchronous
73
operations for applications which require a responsive user interface.
74
For simplicity, however, the example below uses the synchronous API to
75
retrieve all contacts:
77
QList<QContact> allContacts = cm.contacts();
80
\section2 Selecting a Detail
82
The third step may be performed in several ways. The recommended way is to
83
utilize the templated detail accessor, if you know which type of detail you
86
QContact firstContact = allContacts.first();
87
qDebug() << "The first contact has a phone number:" << firstContact.detail<QContactPhoneNumber>().number();
90
Alternatively, you can use the base \l QContactDetail class methods to select
91
the detail in which you are interested in, and the field keys specified in the
92
derived class to select the value which you are interested in:
94
qDebug() << "The first contact has a phone number:" << firstContact.detail(QContactPhoneNumber::DefinitionName).value(QContactPhoneNumber::FieldNumber);
97
Note that in each case, if the contact did not have a phone number detail,
98
the return value of QContact::detail() is an empty detail. Also note that in
99
the first case, the return value will be of the QContactPhoneNumber detail
100
type, whereas in the second case, the return value will be of the
101
QContactDetail (base-class detail) type -- although the actual detail returned
102
in both cases is exactly the same.
104
\section2 Retrieving All Details
106
If you wish to retrieve all of the details of a contact, you may do something
109
QList<QContactDetail> allDetails = firstContact.details();
112
\section2 Retrieving Details of a Type
114
Alternatively, if you wish only to retrieve the details which are of some
115
particular type, you can use either the templated or non-templated accessor:
117
QList<QContactPhoneNumber> allPhoneNumbers = firstContact.details<QContactPhoneNumber>();
118
QList<QContactDetail> allPhoneNumbers2 = firstContact.details(QContactPhoneNumber::DefinitionName);
121
Note that in each case, if the contact did not have any phone number details,
122
the return value of QContact::details() is an empty list. Also note that in
123
the first case, the return value will be a list of the QContactPhoneNumber
124
detail type, whereas in the second case, the return value will be a list of
125
the QContactDetail (base-class detail) type -- although the actual details
126
returned in both cases will be exactly the same.
128
\section1 Saving Contacts
130
The next most common use of the API is to save a contact. Such an operation
131
consists of two steps:
133
\li Saving a detail in a contact
134
\li Saving the contact in a manager
137
Removing a contact is done similarly to saving a contact. An example of these
138
two operations is given below. Note that it uses the synchronous API to save
139
and remove the contact, although in a real application we recommend using the
140
asynchronous API to perform such manager-related operations.
142
QContactPhoneNumber newPhoneNumber; // create the detail to add
143
newPhoneNumber.setNumber("12345"); // set the value(s) to save
144
firstContact.saveDetail(&newPhoneNumber); // save the detail in the contact
145
cm.saveContact(&firstContact); // save the contact in the manager
146
cm.removeContact(firstContact.id()); // remove the contact from the manager
149
That's it! For more in-depth discussion of usage of the API, see the sections
152
\section1 Configuring Managers
154
Users of the contacts API can define which backend they wish to access if a
155
manager for that backend is available. The list of available managers can be
156
queried programmatically at run-time, and the capabilities of different
157
managers can be ascertained by inspecting a QContactManager instance.
158
Furthermore, some managers can be constructed with parameters which affect the
159
operation of the backend.
161
\section2 Loading the Default Manager for the Platform
163
Most users of the API will want to use the default manager for the platform,
164
which provides access to the system address book. Instantiating a manager by
165
using the default constructor will result in the default manager for that
166
platform being instantiated.
168
The default constructor can either be used to create a manager on the stack,
169
in which case it will be deleted automatically when it goes out of scope:
171
\snippet qtcontactsdocsample/qtcontactsdocsample.cpp Loading the default manager for the platform
173
or it can be used explicitly to create a manager on the heap, in which case
174
the client must ensure that it deletes the manager when it is finished
175
with it in order to avoid a memory leak:
177
\snippet qtcontactsdocsample/qtcontactsdocsample.cpp Loading the default manager for the platform on heap
179
\section2 Querying a Manager for Capabilities
181
Different managers will support different capabilities and details. Clients
182
can use the meta data reporting functions of QContactManager to determine what
183
the capabilities of the manager they have instantiated might be.
185
\snippet qtcontactsdocsample/qtcontactsdocsample.cpp Querying a manager for capabilities
187
\section2 Loading the Manager for a Specific Backend
189
In this example, the client loads a manager for a specific backend. While
190
this could be found and retrieved using a more advanced plugin framework
191
(such as the Qt Service Framework), this code assumes that the client has
192
prior knowledge of the backend in question.
194
Clients may wish to use this feature of the API if they wish to store or
195
retrieve contact information to a particular manager (for example, one that
196
interfaces with a particular online service).
198
\snippet qtcontactsdocsample/qtcontactsdocsample.cpp Loading a specific manager backend
200
\section2 Loading a Manager with Specific Parameters
202
The client loads a manager with specific parameters defined. The
203
parameters which are available are backend specific, and so the client had
204
to know that the \e Settings parameter was valid for the particular backend,
205
and what argument it took. In this example, the client tells the backend to
206
load detail definitions saved in a particular settings file.
208
\snippet qtcontactsdocsample/qtcontactsdocsample.cpp Loading a specific manager backend with parameters
210
\section1 Manipulating Contact Details
212
Once a contact has been created (or retrieved from a manager), the client can
213
retrieve, create, update or delete details from the contact. Since QContact
214
and QContactDetail are both container (value) classes, the API offered for
215
these operations is purely synchronous.
217
A contact consists of the details it contains, as well as an id. Some details
218
are read-only (such as the display label of a contact) or irremovable (like
219
the type of a contact), but most are freely modifiable by clients.
221
\section2 Adding Details
223
The client adds a name and a phone number to a contact.
225
\snippet qtcontactsdocsample/qtcontactsdocsample.cpp Adding a detail to a contact
227
\section2 Updating Details
229
The client updates the phone number of a contact.
231
\snippet qtcontactsdocsample/qtcontactsdocsample.cpp Updating a detail in a contact
233
\section2 Removing Details
235
The client removes the phone number of a contact.
237
\snippet qtcontactsdocsample/qtcontactsdocsample.cpp Removing a detail from a contact
239
\section2 Viewing Details
241
The client retrieves and displays the first phone number of a contact.
243
\snippet qtcontactsdocsample/qtcontactsdocsample.cpp Viewing a specific detail of a contact
245
\section2 Viewing All Details of a Contact
247
The client retrieves all of the details of a contact, and displays them.
249
\snippet qtcontactsdocsample/qtcontactsdocsample.cpp Viewing the details of a contact
251
\note Details are implicitly shared objects with
252
particular semantics surrounding saving, removal and modification. The
253
following example demonstrates these semantics.
255
\snippet qtcontactsdocsample/qtcontactsdocsample.cpp Demonstration of detail sharing semantics
257
\section1 Persistent Contact Information
259
After instantiating a manager, clients will wish to retrieve or modify contact
260
information (including relationships and possibly detail definitions) which
261
is persistently stored in the manager (for example, in a database or online
264
If the client wishes to use the asynchronous API, it is suggested that their
265
class uses member variables for the manager and requests, similarly to:
267
\snippet qtcontactsdocsample/requestexample.h Class setup
269
This allows them to define slots which deal with the data as required when the
270
state of the request changes:
272
\snippet qtcontactsdocsample/qtcontactsdocsampleasync.cpp Example of an asynchronous request slot
274
Note that if the client is interested in receiving the results of the request
275
as they become available, rather than only the final set of results once the
276
request changes state (to \c FinishedState, for example), the client should
277
instead connect the QContactAbstractRequest::resultsAvailable() signal to the
278
slot which deals with the results.
280
\section2 Creating Contacts
282
The client creates a new contact and saves it in a manager.
284
\snippet qtcontactsdocsample/qtcontactsdocsampleasync.cpp Creating a new contact in a manager
286
Alternatively, the client can explicitly block execution until the request is
287
complete, by doing something like:
289
\snippet qtcontactsdocsample/qtcontactsdocsampleasync.cpp Creating a new contact in a manager waiting until finished
291
The equivalent code using the synchronous API looks like:
293
\snippet qtcontactsdocsample/qtcontactsdocsample.cpp Synchronously creating a new contact in a manager
295
\section2 Retrieving Contacts
297
The client requests all contacts from the manager which match a particular
300
\snippet qtcontactsdocsample/qtcontactsdocsampleasync.cpp Filtering contacts from a manager
302
The equivalent code using the synchronous API looks like:
304
\snippet qtcontactsdocsample/qtcontactsdocsample.cpp Synchronously filtering contacts from a manager
306
The client can also retrieve a particular existing contact from a manager, by
307
directly requesting the contact with a particular (previously known) id.
308
With the asynchronous API, this takes the form of another filter:
310
\snippet qtcontactsdocsample/qtcontactsdocsampleasync.cpp Retrieving an existing contact from a manager
312
The synchronous API provides a function specifically for this purpose:
314
\snippet qtcontactsdocsample/qtcontactsdocsample.cpp Synchronously retrieving an existing contact from a manager
316
\section2 Updating Contacts
318
The client updates a previously saved contact by saving the updated version of
319
the contact. Any contact whose id is the same as that of the updated contact
320
will be overwritten as a result of the save request.
322
\snippet qtcontactsdocsample/qtcontactsdocsampleasync.cpp Updating an existing contact in a manager
324
The equivalent code using the synchronous API looks like:
326
\snippet qtcontactsdocsample/qtcontactsdocsample.cpp Synchronously updating an existing contact in a manager
328
\section2 Removing Contacts
330
The client removes a contact from the manager by specifying its id.
332
\snippet qtcontactsdocsample/qtcontactsdocsampleasync.cpp Removing a contact from a manager
334
The equivalent code using the synchronous API looks like:
336
\snippet qtcontactsdocsample/qtcontactsdocsample.cpp Synchronously removing a contact from a manager
338
\section2 Creating Relationships
340
The client specifies a relationship between two contacts stored in the manager
342
\snippet qtcontactsdocsample/qtcontactsdocsampleasync.cpp Creating a new relationship between two contacts
344
The equivalent code using the synchronous API looks like:
346
\snippet qtcontactsdocsample/qtcontactsdocsample.cpp Synchronously creating a new relationship between two contacts
348
\section2 Retrieving Relationships
350
The client requests the relationships that a particular contact is involved in
351
from the manager in which the contact is stored.
353
\snippet qtcontactsdocsample/qtcontactsdocsampleasync.cpp Retrieving relationships between contacts
355
The equivalent code using the synchronous API looks like:
357
\snippet qtcontactsdocsample/qtcontactsdocsample.cpp Synchronously retrieving relationships between contacts
359
When a contact is retrieved, it will contain a cache of the relationships in
360
which it is involved at the point in time at which it was retrieved.
361
This provides clients with a simple way to retrieve the relationships in which
362
a contact is involved, but carries the risk that the cache is stale.
364
\snippet qtcontactsdocsample/qtcontactsdocsample.cpp Retrieving relationships from cache
366
Clients can inform the manager that they do not require this cache of
367
relationships to be populated when retrieving a contact, which can allow a
368
manager to optimize contact retrieval. Other retrieval optimizations are also
369
possible to specify, for example that they do not require action preferences
370
to be returned, or that they are only interested in certain types of details.
371
The following code shows how the client can inform the manager that they are
372
only interested in relationships of the \c HasMember type (groups):
374
\snippet qtcontactsdocsample/qtcontactsdocsampleasync.cpp Providing a fetch hint
376
The equivalent code using the synchronous API looks like:
378
\snippet qtcontactsdocsample/qtcontactsdocsample.cpp Synchronously providing a fetch hint
380
\section2 Removing Relationships
382
The client can remove a relationship directly from a manager.
384
\snippet qtcontactsdocsample/qtcontactsdocsampleasync.cpp Removing a relationship
386
The equivalent code using the synchronous API looks like:
388
\snippet qtcontactsdocsample/qtcontactsdocsample.cpp Synchronously removing a relationship
390
Alternatively, when a contact which is involved in a relationship is removed,
391
any relationships in which it is involved will be removed also.
added
removed
src/contacts/doc/src/contactsusage.qdoc
