D15979: [SMS App] Allow scrolling up to load and display older messages

[Simon Redman]

sredman added a comment.


  In D15979#340006 <https://phabricator.kde.org/D15979#340006>, @nicolasfella wrote:
  
  > In D15979#337683 <https://phabricator.kde.org/D15979#337683>, @sredman wrote:
  >
  > > Yes. The issue is the backend only has one message loaded from the phone. When the view first loads it requests the first 10 which causes the backend to request from the phone. Once they're in cache this isn't a problem (try opening the same conversation twice after a slight delay)
  > >  I agree this is kind of ugly but I don't know an easy way to fix it. One thought is to make ConversationsDbusInterface::requestConversation synchronous and block until it is able to serve the request. This would be good for several reasons... For one thing, it would enable having multiple conversation views open at the same time!
  >
  
  
  
  
  > Making it blocking sound like it could cause issues when a device is not reachable.
  
  When a device is unreachable, we have a whole different pile of problems. I will work on solving those "soon"... Basically as soon as we can get this patch to work for you!
  
  > Have you actually tested this?
  
  D16092 <https://phabricator.kde.org/D16092>
  
  > When opening the conversation a bunch (10) messages are requested. The problem is that once they arrive the view isn't updated, isn't it?
  
  That is a different way of looking at the problem. Maybe I am looking at it the wrong way, but my thought is it is very hard for the view to communicate to the dbus interface:
  a) Which conversations are currently being looked at (thus which conversations it wants to see updates for)
  b) Which messages of those conversations it actually wants
  My opinion is that the dbus interface should create the appearance of containing all messages, even if that is actually an illusion and it has to call back to Android. Thus, it should return the requested messages (if they exist) directly (synchronously) rather than just dropping the initial request while it scrambles around to find the requested messages.

REPOSITORY
  R224 KDE Connect

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

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