D16475: [SMS App] Make requestMoreMessages asynchronous, blocking, and caching

[Simon Redman]

sredman marked an inline comment as done.
sredman added inline comments.

INLINE COMMENTS

> apol wrote in requestconversationworker.h:34
> Two things:
> Do we still need threads now that we don't have the QEventLoop? I don't think so.
> If we did, maybe it would be useful if this class inherited QThread.

We still need something to solve the same problem as the QEventLoop was trying to solve. That is, we need some way to wait until the remote (Android) device replies with the messages we requested, otherwise we don't have anything to return to the user request and the GUI remains annoyingly empty until they make a second request. If we wait on the main thread, the event loop can't process the incoming packet, so we can never stop waiting

This could be done by inheriting from QThread, but the Qt people are very firm that inheriting from QThread to do a simple task is the wrong way to do it. The way I have done it is the recommended way

REPOSITORY
  R224 KDE Connect

REVISION DETAIL
  https://phabricator.kde.org/D16475

To: sredman, #kde_connect
Cc: apol, nicolasfella, kdeconnect, skymoore, wistak, dvalencia, rmenezes, julioc, Leptopoda, timothyc, jdvr, yannux, Danial0_0, johnq, Pitel, adeen-s, SemperPeritus, daniel.z.tg, jeanv, seebauer, bugzy, MayeulC, menasshock, tctara
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdeconnect/attachments/20181028/19e0e51d/attachment.html>