wire-android_legacy
wire-android_legacy copied to clipboard
wireapp
Queue messages to be sent when offline
Feature request: Please allow me to "send" messages when offline by putting the message in a queue such that wire will automatically send the message when it next gets internet connectivity (without me having to click resend).
Expected Behaviour
Wire should not assume that there is always Internet, and it should have queues and retry logic to send messages when possible (like WhatsApp). This means two things:
1. Wire should automatically download new messages in the background when my device is asleep in my pocket and suddenly gets an Internet connection
I don't have a SIM card, and I live in a city where wifi is abundant, yet spotty.
As I walk around the city on any given day, my Android phone will sit in my pocket and scan for wifi connections. Usually, when I do check my phone at some point after walking around, I notice that I have a bunch of unread messages on WhatsApp. That's because WhatsApp detected that I had internet and automatically downloaded all my messages during the brief ~60 seconds during which I was walking past a wifi hotspot. This is great.
2. Wire should automatically send all unsent messages in the background when my device is asleep in my pocket and suddenly gets an Internet connection
Moreover, once I notice the messages, I can proceed to write back replies, even if I don't have Internet at this time. In WhatsApp, this works fine.
Whatsapp will just queue up the messages for sending. The next time I walk by a wifi hotspot, it will blast all my previously-failed-to-send messages out to the Internet. Great!
Actual Behaviour
In Wire, this doesn't work. If I try to send a message when offline, it just tells me that it fails.
Wire expects me to then walk to a wifi hotspot, pull my phone out of my pocket, and click "retry" .
Sometimes (eg when traveling long distances in the wilderness or on a bicycle), I go weeks without Internet. This means I'll send a few dozen photos to several dozen people. In this situation, Wire expects me to click retry a few hundred times. This is terrible UX.
The Solution
Wire should implement retry logic so that this "just works" as it does with Whatsapp:
- Wire should automatically download new messages in the background when my device is asleep in my pocket and suddenly gets an Internet connection
- Wire should automatically send all unsent messages in the background when my device is asleep in my pocket and suddenly gets an Internet connection
Regarding better retry logic (but specifically on poor network connections), see also https://github.com/wireapp/wire-android/issues/1517
Regarding auto-resend (related to about half of this ticket), see also https://github.com/wireapp/wire-android/issues/1233
I always regarded it as a bug that it doesn't automatically retry, rather than a feature request. Also on desktop, it'll just keep being gray and never send, with no retry button. This cannot be intended behavior. Similar with fetching messages in the background, it used to work and then it broke (like two years ago). It's a bug, not a feature.
@correctmeifimwrong33 if no queue exists, then I would guess it's a feature request and not a bug (from a developer's or product team's design perspective).
So I guess that begs the question for the Wire team: Is there currently any data structure that stores a queue of unsent messages?
Hello everyone.
Whilst I find very unlikely that this will be solved for this current project, we already have some improvements on this front in the new Android client which still doesn't have a public release, but should replace the current client on the PlayStore soon. For a sneak-peek of what it looks like, checkout the video here. It's a complete rewrite of the application and reimagination of the user interface.
It's more stable and faster under changing network conditions, and also implements a rudimentary "send while offline and then try to send all messages when recover internet connection" kind of mechanism which works for now but can be improved (automatic retry of files/images doesn't work right now).
So I'll leave this issue here as closed – won't fix. Improvements will be delivered as the new Android client is released.
@vitorhugods great news to hear that the new app is moving along, but honestly "react-to-messages-with-emojis" isn't a very high-priority compared to actually making sure that messages are actually delivered (which is what this issue was to address).
implements a rudimentary "send while offline and then try to send all messages when recover internet connection" kind of mechanism
Can you please link to any documentation that shows how the new app is designed to actually address this issue to ensure that messages sent when the machine doesn't have Internet will queued and sent automatically when the internet connection is available again?
(automatic retry of files/images doesn't work right now).
Should we open a new bug report to fix this on the new app? Or is there one already?
[the new app] should replace the current client on the PlayStore soon
What about on F-Droid?
@vitorhugods great news to hear that the new app is moving along, but honestly "react-to-messages-with-emojis" isn't a very high-priority compared to actually making sure that messages are actually delivered (which is what this issue was to address).
I linked the video mostly as it was what I had laying around to depict how extensive are the changes. Reacting with emoji is far from a high priority! It just happens that to be a simple party trick.
Can you please link to any documentation that shows how the new app is designed to actually address this issue to ensure that messages sent when the machine doesn't have Internet will queued and sent automatically when the internet connection is available again?
We haven't fully designed and implemented this yet. I just noticed a quick win for retrying when failing due to lack of connection messages when developing the new message sending mechanism. So we don't have anything written in stone yet.
Should we open a new bug report to fix this on the new app? Or is there one already?
As it's still under-development, I wouldn't consider it a bug yet. We do have internal tickets for tracking progress.
What about on F-Droid?
I don't have a timeline for any of the two releases, but F-Droid is one of the highest priorities we have at the moment.
One other thing that I can say, which will become obvious once the app is released, is that some features will be dropped in the initial versions.
Stability and reliability are prioritised, and from there we can rebuild features.
The most important thing is that the core of this new client is faster, more reliable, and easier to maintain. The core is also multiplatform and can be run from a terminal.
As it's still under-development, I wouldn't consider it a bug yet. We do have internal tickets for tracking progress.
GitHub issues are useful to both bugs and feature requests. As an open-source project, it's a bit concerning that you're not using GitHub issues to track these things.
It also gives the impression to the community that you're not making progress, even if you actually are.
Stability and reliability are prioritised, and from there we can rebuild features.
:+1: