Cascades Development

[AllSystemGo]

Ok so I'm starting to use more and more slot/signals and would like to understand some stuff. I'll post some code and I'll ask my question after.

	QString queryUri;

    queryUri = "somewebsite";

    QUrl url(queryUri);
    QNetworkRequest req(url);

    QNetworkReply* ipReply = netManager_->get(req);
    connect(ipReply, SIGNAL(finished()), this, SLOT(onReply()));

    return _feedReply;

 If I understand correctly even if I declare my signal/slot my code continues, cause _feedReply is always empty, and _feedReply was getting populated in my slot. So how can I make my code stop and wait for the result of onReply() to continue and return _feedReply. 

Maybe I'm doing it all wrong. But I would like to understand.

Thank you!

[Zmey · Accepted solution]

That's correct. Network requests are asynchronous, they do not block.

Qt application relies on events queue. The events are processed in a event processing loop. You shouldn't wait inside of a function, otherwise the event loop will stop and the application will become unresponsive.

If you absolutely need to do this, in Qt there's QApplication:rocessEvents function which can be called periodically while sleeping in function. I don't know if there's a Cascades equivalent, but it's a bad design and is not recommended.

A better approach is declaring your own signal in header file, and emitting this signal from onReply() slot after the reply is processed:
emit mySignal(myData);
Then subscribe to this signal and do further processing there.

[zezke]

You can't and you shouldn't want to. The point is that you launch a network request (for example by pressing a button) and then wait for the result WITHOUT BLOCKING THE UI! If you would be able to wait in the same method the UI thread would be blocked and the user would experience a non-functioning UI.

Just process your results in the onReply method, there's no good reason why that wouldn't work.

[simon_hain]

Regarding network requests there is something to add though:
While the request itself is async, the processing of the response is not!
If you do heavy processing you should not do that in the response method.

We are using QtConcurrent::run to process the network responses (soap or xml parsing).

[zezke]

Excellent point simon, forgot about it.

[AllSystemGo]

Thank you all for your answers. I really appreciate. I'll continu reading to get better at this.