|
|
              
Organizer Asynchronous APIIntroductionThe 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. Using the APIThe asynchronous API offered by the Organizer module is available through classes derived from the QOrganizerAbstractRequest class. It consists of three major categories:
Organizer Item ManipulationThe 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:
Item Collection ManipulationEvery 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: Schema ManipulationThe 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:
UsageAll 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. Error ReportingWhen 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(). X
|
