C++11/Qt & Dropbox v2 API in dropboxQt

[anda_skoa]

Very nice!

Is the "completed" signal emitted in all cases of task end? I.e. it is also emitted when the task failed?

E.g. if you look at QNetworkReply it has a finished() signal that will always be emitted, no matter if the operation succeeded or failed.
The application programmer can therefore be sure that connecting to this signal will always be enough to catch the end of the operation.

Another example for that pattern in Qt is QProcess. It will also always emit the finished() signal, indepent of whether the process exited cleanly, with an error or crashed.

Cheers,
_

[osoft]

no, 'completed' is emited only in case of success, failed in case of 'error'. we can have 'finished' maybe 3rd signal emited in both cases

or maybe just have one signal 'finished' and let user check status of object, like in QNetworkReply

[anda_skoa]

no, 'completed' is emited only in case of success, failed in case of 'error'.

With two signals you need to remember to connect both or you could end up with obejcts hanging around and not being deleted.
For two signals you would need to return a shared pointer to be sure that the object is always deleted even if only one signal is being handled.

Cheers,
_

[osoft]

Converted two signal into one 'finished', seems to work but need a bit more testing.
Also replaced macros with new function
std::unique_ptr<RESULT> waitForResultAndRelease();

This function can be used to wait for async execution to finish. It auto releases Task object and moves result to caller, if available.
For example, new implementation of blocking call:

std::unique_ptr<Metadata> FilesRoutes::alphaGetMetadata(const AlphaGetMetadataArg& arg ){
return alphaGetMetadata_Async(arg)->waitForResultAndRelease();
}

[anda_skoa]

Nice, like a future's "value" getter.

Cheers,
_

[osoft]

There are certainly similarities. DropboxTask essentially can be described as typed representation of Json QNetworkReply data, something:

(Reply -> Json) -> (t, e)

where 't' is result type and 'e' is exception type, DropboxException derived.

On other note, we started something similar to dropboxQt for a subset of Google API - gdrive, gmail, gtask.

https://github.com/osoftteam/googleQt

Now we can compare both APIs. Dropbox at the low level (the endpoint of all routes) consists of 3 functions while Google of 1 function. It is possible to build Dropbox API on top of 1 function as well (dropbox API is even more consistent) but it was never objective. We found fascinating that all wrapper classes can be generated out of some declarative language (STONE), in case of Dropbox all Arguments, Results and Routes are generated, in case of Google Arguments are manually written and the rest generated.

2 anda_skoa - thank for your suggestions, it really helped to shape up the async stuff.