The QContactAbstractRequest class provides a mechanism for asynchronous requests to be made of a manager if it supports them. More...
#include <QContactAbstractRequest>
Inherits: QObject.
Inherited by: QContactDetailDefinitionFetchRequest, QContactDetailDefinitionRemoveRequest, QContactDetailDefinitionSaveRequest, QContactFetchByIdRequest, QContactFetchRequest, QContactLocalIdFetchRequest, QContactRelationshipFetchRequest, QContactRelationshipRemoveRequest, QContactRelationshipSaveRequest, QContactRemoveRequest, and QContactSaveRequest.
This class was introduced in Qt Mobility 1.0.
| enum | RequestType { InvalidRequest, ContactFetchRequest, ContactLocalIdFetchRequest, ContactRemoveRequest, ..., ContactFetchByIdRequest } |
| enum | State { InactiveState, ActiveState, CanceledState, FinishedState } |
| ~QContactAbstractRequest () | |
| QContactManager::Error | error () const |
| bool | isActive () const |
| bool | isCanceled () const |
| bool | isFinished () const |
| bool | isInactive () const |
| QContactManager * | manager () const |
| void | setManager ( QContactManager * manager ) |
| State | state () const |
| RequestType | type () const |
| bool | cancel () |
| bool | start () |
| bool | waitForFinished ( int msecs = 0 ) |
| void | resultsAvailable () |
| void | stateChanged ( QContactAbstractRequest::State newState ) |
The QContactAbstractRequest class provides a mechanism for asynchronous requests to be made of a manager if it supports them.
It allows a client to asynchronously request some functionality of a particular QContactManager. Instances of the class will emit signals when the state of the request changes, or when more results become available.
Clients should not attempt to create instances of this class directly, but should instead use the use-case-specific classes derived from this class.
All such request classes have a similar interface: clients set the parameters of the asynchronous call, including which manager the request will be made of, and then call the start() slot of the request. The manager will then enqueue or begin to process the request, at which point the request's state will transition from InactiveState to ActiveState. After any state transition, the request will emit the stateChanged() signal. The manager may periodically update the request with results, at which point the request will emit the resultsAvailable() signal. These results are not guaranteed to have a stable ordering. Error information is considered a result, so some requests will emit the resultsAvailable() signal even if no results are possible from the request (for example, a contact remove request) when the manager updates the request with information about any errors which may have occurred.
Please see the class documentation of each of the use-case-specific classes derived from this class for information about how to retrieve the results of a request (including error information). In all cases, those functions are synchronous, and will return the cached result set with which the manager has updated the request instance if the resultsAvailable() signal has been emitted.
Clients can choose which signals they wish to handle from a request. If the client is not interested in interim results, they can choose to handle only the stateChanged() signal, and in the slot to which that signal is connected, check whether the state has changed to either FinishedState or CanceledState (both of which signify that the manager has finished handling the request, and that the request will not be updated with any more results). If the client is not interested in any results (including error information), they may choose to delete the request after calling start(), or simply not connect the request's signals to any slots.
If the request is allocated via operator new, the client must delete the request when they are no longer using it in order to avoid leaking memory. That is, the client retains ownership of the request.
The client may delete a heap-allocated request in various ways: by deleting it directly (but not within a slot connected to a signal emitted by the request), or by using the deleteLater() slot to schedule the request for deletion when control returns to the event loop (from within a slot connected to a signal emitted by the request, for example stateChanged()).
An active request may be deleted by the client, but the client will not receive any notifications about whether the request succeeded or not, nor any results of the request.
Because clients retain ownership of any request object, and may delete a request object at any time, manager engine implementors must be careful to ensure that they do not assume that a request has not been deleted at some point during processing of a request, particularly if the engine has a multithreaded implementation. It is suggested that engine implementors read the Qt Contacts Manager Engines documentation for more information on this topic.
Enumerates the various possible types of asynchronous requests
| Constant | Value | Description |
|---|---|---|
| QContactAbstractRequest::InvalidRequest | 0 | An invalid request |
| QContactAbstractRequest::ContactFetchRequest | 1 | A request to fetch a list of contacts |
| QContactAbstractRequest::ContactLocalIdFetchRequest | 2 | A request to fetch a list of local contact ids |
| QContactAbstractRequest::ContactRemoveRequest | 3 | A request to remove a list of contacts |
| QContactAbstractRequest::ContactSaveRequest | 4 | A request to save a list of contacts |
| QContactAbstractRequest::DetailDefinitionFetchRequest | 5 | A request to fetch a collection of detail definitions |
| QContactAbstractRequest::DetailDefinitionRemoveRequest | 6 | A request to remove a list of detail definitions |
| QContactAbstractRequest::DetailDefinitionSaveRequest | 7 | A request to save a list of detail definitions |
| QContactAbstractRequest::RelationshipFetchRequest | 8 | A request to fetch relationships between contacts |
| QContactAbstractRequest::RelationshipRemoveRequest | 9 | A request to remove any relationships which match the request criteria |
| QContactAbstractRequest::RelationshipSaveRequest | 10 | A request to save a list of relationships |
| QContactAbstractRequest::ContactFetchByIdRequest | 11 | A request to fetch a list of contacts given a list of ids |
Enumerates the various states that a request may be in at any given time
| Constant | Value | Description |
|---|---|---|
| QContactAbstractRequest::InactiveState | 0 | Operation not yet started |
| QContactAbstractRequest::ActiveState | 1 | Operation started, not yet finished |
| QContactAbstractRequest::CanceledState | 2 | Operation is finished due to cancellation |
| QContactAbstractRequest::FinishedState | 3 | Operation successfully completed |
Cleans up the memory used by this request
Attempts to cancel the request. Returns false if the request is not in the QContactAbstractRequest::Active state, or if the request is unable to be cancelled by the manager engine; otherwise returns true.
This function was introduced in Qt Mobility 1.0.
Returns the overall error of the most recent asynchronous operation
This function was introduced in Qt Mobility 1.0.
Returns true if the request is in the QContactAbstractRequest::ActiveState state; otherwise, returns false
This function was introduced in Qt Mobility 1.0.
See also state().
Returns true if the request is in the QContactAbstractRequest::CanceledState; otherwise, returns false
This function was introduced in Qt Mobility 1.0.
See also state().
Returns true if the request is in the QContactAbstractRequest::FinishedState; otherwise, returns false
This function was introduced in Qt Mobility 1.0.
See also state().
Returns true if the request is in the QContactAbstractRequest::InactiveState state; otherwise, returns false
This function was introduced in Qt Mobility 1.0.
See also state().
Returns a pointer to the manager of which this request instance requests operations
This function was introduced in Qt Mobility 1.0.
See also setManager().
This signal is emitted when new results are available. Results can include the operation error which may be accessed via error(), or derived-class-specific results which are accessible through the derived class API.
This function was introduced in Qt Mobility 1.0.
See also error().
Sets the manager of which this request instance requests operations to manager
If the request is currently active, this function will return without updating the manager object.
This function was introduced in Qt Mobility 1.0.
See also manager().
Attempts to start the request. Returns false if the request is not in the QContactAbstractRequest::Inactive, QContactAbstractRequest::Finished or QContactAbstractRequest::Cancelled states, or if the request was unable to be performed by the manager engine; otherwise returns true.
This function was introduced in Qt Mobility 1.0.
Returns the current state of the request.
This function was introduced in Qt Mobility 1.0.
This signal is emitted when the state of the request is changed. The new state of the request will be contained in newState.
This function was introduced in Qt Mobility 1.0.
Returns the type of this asynchronous request
This function was introduced in Qt Mobility 1.0.
Blocks until the request has been completed by the manager engine, or until msecs milliseconds has elapsed. If msecs is zero or negative, this function will block until the request is complete, regardless of how long it takes. Returns true if the request was cancelled or completed successfully within the given period, otherwise false. Some backends are unable to support this operation safely, and will return false immediately.
Note that any signals generated while waiting for the request to complete may be queued and delivered some time after this function has returned, when the calling thread's event loop is dispatched. If your code depends on your slots being invoked, you may need to process events after calling this function.
This function was introduced in Qt Mobility 1.0.
© 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.