QServiceReplyBase Class

Detailed Description

The QServiceReplyBase class tracks non-blocking service framework calls.

The QServiceReplyBase class is a data-carrying class. Each instance is short-lived and only exists during the lifetime of a QServiceManager call. The QServiceReplyBase instance never owns any of the data it points to, it just serves to carry the payload from the background request back to the caller.

When an instance is first created, after being returned from QServiceManager::loadInterface(), that instance will return false from both the isRunning() and isFinished() functions. Then the request is started, and it will emit the started() signal. After that, and until the request is completed, the isRunning() function will return true. Finally the request is completed, and it will emit the finished() signal. After that the isRunning() function will return false, and the isFinished() function will return true. At this point client code can access the proxyObject() function to obtain the payload of the service request.

Typically there should be no reason to construct a QServiceReplyBase (or sub-class) instance: instead simply use the instances returned from the QServiceManager::loadInterface() function.

The service QObject returned from the proxyObject() function is owned by the caller of the original QServiceManager::loadInterface() function which resulted in the QServiceReplyBase instance. Likewise the QServiceObjectBase instance itself is owned by the caller and after the payload is retrieved, it should be queued for destruction with deleteLater() in the function which handles the finished() signal.

As a convenience the manager() function will return the QServiceManager associated with the request, and the request() function will return a QString indicating the details of the request itself.

For performance reasons the QServiceReplyBase object is not synchronized, and thread-safety is ensured by observing the following invariant condition:

• all calls to non-const methods are serialised

In general client code should never have to worry about this, since the private slots which can modify the reply are called via queued signal-slot connections behind the scenes ensuring that such accesses are serialised.

In the case of a request based on an interface name, request() will return the interface name; otherwise in the case of a request based on a descriptor it will return the interface name of the descriptor.