The Organizer Asynchronous API enables a client to asynchronously fetch, update, or remove calendar, scheduling and personal data from an organizer item manager. Use of the asynchronous API offers the programmer greater flexibility when requesting information from remote or slow local datastores.
The asynchronous API offered by the Organizer module is available through classes derived from the QOrganizerAbstractRequest class. It consists of three major categories:
The most common type of operation that clients will perform involves retrieval or modification of organizer items. For in-depth information about item manipulation, please refer to the main Organizer API page.
There are six different types of operation which are supported by the asynchronous API:
These operations are supported via the classes:
Every item is saved in a collection in a manager. Each collection has various properties which, if the manager supports such operations, may be modified by clients. For in-depth information about collections, please refer to the main Organizer API page.
There are three different types of operation which are supported by the asynchronous API:
These operations are supported via the classes:
The schema supported by a engine is the list of detail definitions which are supported by the engine. For in-depth information about the schema, please refer to the main Qt Organizer Schema page.
There are three different types of operation which are supported by the asynchronous API:
These operations are supported via the classes:
All asynchronous operations are performed in a similar pattern: a request of the desired type (which is derived from QOrganizerAbstractRequest) is created, certain criteria are set which determine the intent of the request, QOrganizerAbstractRequest::stateChanged() signal of the request is connected to a slot which deals with the results. The request can then be started.
Note that if the client is interested in receiving the results of the request as they become available, rather than only the final set of results once the request changes state (to FinishedState, for example), the client should instead connect the QOrganizerAbstractRequest::resultsAvailable() signal to the slot which deals with the results.
When a asynchronous operation fails, clients need to be able to retrieve error information associated with that asynchronous operation. It is possible to retrieve this error information by calling the QOrganizerAbstractRequest::error() function on the corresponding request.
For some asynchronous operations (for example, batch save or remove operations) it is possible that multiple errors may occur during the operation. In those cases, clients can call the errorMap() function on the request object to retrieve a map of input index to error. See, for instance, QOrganizerItemSaveRequest::errorMap().
© 2008-2011 Nokia Corporation and/or its subsidiaries. Nokia, Qt and their respective logos are trademarks of Nokia Corporation in Finland and/or other countries worldwide.
All other trademarks are property of their respective owners. Privacy Policy
Licensees holding valid Qt Commercial licenses may use this document in accordance with the Qt Commercial License Agreement provided with the Software or, alternatively, in accordance with the terms contained in a written agreement between you and Nokia.
Alternatively, this document may be used under the terms of the GNU Free Documentation License version 1.3 as published by the Free Software Foundation.