i’m one of the nice people that brought you WebPush. That lovely tech that is probably one of the most user hated things to roll out. i work on the back-end bits. i still hold that in spite of idiot web marketing folk who don’t want us to have nice things, web push is still really useful, but that’s not important right now.
What i want to talk about today is something i’ve been asked a good deal lately:
Ok, that probably sounds like a really weird question, but let me explain a few things.
How Push works:
i’m not going to go into super detail here, but suffice to say that Web Push provides a way for servers you’re not connected to currently to send you messages that you’ve agreed to having delivered. It’s super easy for you to send messages to servers since they don’t move around and change their IP address every 15 minutes. Your phone may well do that. So what we do internally is have your phone connect to one of a bunch of servers we run, then it sits around waiting for you to send a message. For things like laptops or desktops which have big batteries or are always plugged in, that’s a great solution. For phones, however things are a bit different.
How Push works on Mobile Devices:
Your phone doesn’t want to be on. It wants to power down as much as possible so that your battery doesn’t die after an hour or so. It has LOTS of VERY AGGRESSIVE power management things it does in order to facilitate that. It will also flag any app that consumes “too much” battery and point at it like Donald Sutherland in Invasion of the Body Snatchers. Naturally, since having a reliable connection from your devices maker’s servers to your device is actually really useful, they’re very forgiving about any that they might set up. In fairness, they have a lot of neat tricks they can pull at very low levels to keep your CPU asleep and the battery usage minimal that they’re absolutely not going to let your J. Random Application take advantage of.
So instead they offer a way for you to piggyback on top of their protocols. That’s what Firefox on Android (and to some extent Firefox on iOS and Amazon FireTV) does. The data we send over these bridges is still encrypted because the decryption key is in the User Agent (the actual “Firefox” application).
The problem is, running machines that your device connect to for long periods is kind of expensive. As in people in the Accounts Payable department screaming “WHY DOES THIS BILL HAVE SO MANY ZEROES!?” sort of expensive. There are things you can do to control costs, but frankly, when you’re talking about hundreds of millions of phones calling in, you’re talking about having at least a few good boxes just to handle the loads. It’s kinda depressing how much doing nothing costs, particularly in setting up a secure link that does nothing, but that’s our problem more than yours. (Although, next time you want to buy something, if you were to search for it in the AwesomeBar, click on one of the ads and buy it from there, that’d be swell!)
That’s one of the reasons that Google put their messaging system under Google Play. It’s an app that only gets installed on authorized Google Android devices, and (surprise) it costs money to do that. You can absolutely grab a copy of the Android Open Source, customize it to fit your phone’s hardware platform and get rolling. You might even be able to sideload some versions of Google Play onto those devices, but Android is the most used phone platforms on the planet and even Google has pipers to pay.
So, how do you do Push if Push isn’t there?
Thus we come to the (potentially) million dollar question.
So, if you’ve got an off-brand Android phone, it’s probably using the Open Source release of Android, which does not have Google Play. Honestly, it probably doesn’t have a lot of services. So what options are there?
- Polling: This is probably the easiest. When your app is active (or if you set up a timer) you could have it poll a well known server address and check to see if there are any messages. You want to be careful with this, to avoid “thundering herds” where all the devices suddenly check at once and swamp your servers. You can randomize things a bit, but i’ve also seen some devices that “helpfully” round sleep timers to a nearest interval (e.g. you thought you said sleep for 5 minutes? Oh, well, we slept for 15 since that means less CPU.) Some experimentation and monitoring your servers may be required.
Pro: here is that it’s fairly straightforward and simple to do.
Con: it’s not exactly “timely”. Good for “Remember John’s Birthday tomorrow” less for “your tea kettle is boiling”.
- Active Reception: This one is a bit trickier. Basically, when your app is active, it connects to your servers using WebSocket, HTTP/2 or whatever protocol and actively pulls and listens for messages. This can provide much faster message deliveries while the user is present and attentive.
Pro: Quick message delivery with feedback.
Con: Could be complex and doesn’t work when the device is sleeping.
- Combo: This one combines the two above steps. You have a small stub program that checks a URL to see if there are any messages pending, and if so, spins up your app to do a full connection. The connection processes everything, then lets the device go back to sleep.
Pro: Almost exactly like Push, sort of.
Con: Complex, and probably buggy. Dances the line between “efficient” and “here come the howler monkeys”
Sadly, i believe that any of these would probably constitute a “savvy business opportunity” for some startup, and while i’ve not looks, i would not be surprised in the least if there was a company out there that was offering a service like one of these. i don’t think it would be free though, mostly because of the costs associated with it.