You are not always connected.
You are not always connected.
You are not always connected.
Truely you aren’t.
I know you like to think you are, but get over it – this isn’t the case.
From the unveiling of AWS IOT platform @ re:Invent 2015
Every week I need to take my daughter to her artistic gymnastics lessons. And then I have 90 minutes of quality time. With myself. While I usually use it to continue reading on my Kindle, I try once in awhile to actually work at that time. The problem is, that the cellular reception in the waiting hall is less than satisfactory and the mosquitoes make it impossible to sit outside – where it is a lot nicer with much better reception.
I quickly learned that working there is close to impossible, as reception is flaky – not something I can rely on with my line of work which requires an intravenous internet connection at all times. But there are quick things that I can do at that time – which most usually than not includes messaging.
Offline Messaging
Here’s what I found out about the 3 top messaging apps on my phone recently:
WhatsApp rocks when it comes to be able to send messages even when I am offline. It uses the store and forward technique both on the client and on the server:
- If the user has no internet connection, the message is stored locally until such a connection is restored. This approach works only for text messages – you can’t share images or videos with it while offline 🙁
- If the receiver has no internet connection, then the message is stored on the WhatsApp server until a point in time when the recipient is available – this works for all types of messages
You just can’t ask for more.
Google Hangouts
Google Hangouts is rather poor when it comes to offline behavior. I does manage its own store and forward mechanism on the server side, which means that if you send a message when you are online – the recipient will see it when he becomes online.
But, you can’t send anything if you aren’t online. Hangouts isn’t kind enough to store it locally until you are online.
This makes for a poor experience for me in that gymnasium waiting room, where the network comes and goes as it pleases. Or when I am riding the elevator going downstairs from my apartment and need to send some quick messages.
Slack
Slack needs to be connected. At least as far as my understanding of it is.
If you open the app, it tries to connect. If you send a message while it is connected – great.
If you try sending when it isn’t connected – it will fail.
But sometimes, it believes that it is connected and it isn’t. In such a case, killing the Android app and restarting it will be the only remedy to be able to send anything out.
Yuck.
Offline Frameworks
Communication frameworks are tricky. The idea is that you have a network to be able to communicate, but as we’ve just seen – this isn’t always the case.
So where do we stand with different frameworks? I had these 3 examples readily available out the top of my head for you:
Matrix History Storage
Matrix (interviewed here in the past) also went to great lengths to deal with offline scenarios. In the case of Matrix, it was about decentralization of the network itself, and how can you “self heal” and synchronized servers that go down min-conversation.
This makes it easy to add and remove servers during runtime, but it doesn’t help me in my daughter’s gymnasium class. I haven’t found any information stating that Matrix can (or can’t) send a message while the sender client is offline.
UPDATE: Matthew Hodgson contacted me, stating that Matrix prides itself of supporting unconnected messaging in the SDK itself – it stores messages locally and sends them when it connects to the server.
Twilio and Message History
Twilio announced its own IP Messaging capability. While this isn’t yet generally available, the concepts behind these APIs are outlined on that page.
To make things simple – it includes store and forward on the server (recipient can be offline when sender sends and vice versa); but it probably doesn’t include sending while the sender is offline.
As this is still under development/testing, my suggestion would be to add the “sender is offline” scenario and support it from the SDK.
Amazon Device Shadow
At AWS re:Invent 2015, Amazon unveiled its IOT platform – the building blocks it has on offer for the Internet of Things.
In many ways, the Internet of Things is… connected. But in many other ways it might not be connected at all times. I’ve seen several interesting IOT frameworks overcome these in various means. Here’s AWS take on it – they create what they call a device shadow.
Werner Vogels does a great job of explaining this. I suggest viewing the whole session and not just the 1 minute explainer on device shadow.
Why is it important?
We are never always truly online. As messaging becomes one of the central means of communicating – both between people as well as devices – it needs to take this into account. This means covering as many offline use cases as possible and not just assume everything is connected.
Doing this can be tricky to get right, and in many cases, it would preferable for developers to go with a solid framework or a service as opposed to building it on their own. What most frameworks still miss today is that nagging ability to send a message while the user is offline – storing it locally and sending once he comes online.