ok so it’s kind of annoying that only Apple supports push notifications really nicely. well ok and blackberry – sort of. (since they opened up their Blackberry push API).
So we did a bit of thinking and we wanted to share it with everyone else.
Let’s define push for a minute here – in the context of the five echoecho platforms. Bearing in mind that we are trying to solve the same problem any other client server messaging app needs to solve (whether it’s IM, social networking, RPG or some combination thereof)
Let’s also assume a flat rate data plan – because most of this discussion is probably moot if the users don’t have one.
So let’s see here
Iphone: push notifications work, background running apps do not
Android: no push notifications yet (I’m astounded google did not anticipate this problem), background apps ok
Blackberry: background apps and push are ok – although push is a fairly recent thing for Blackberry (we are rushing to integrate it into the next version of echoecho)
Nokia: no push notifications yet, background apps ok
Windows Mobile: no push notifications yet, background apps ok
When I say push I mean
- reliable 3rd party API accesible to most developers without onerous restrictions or fees
- polling service that does NOT drain the cellphone battery unnecessarily
- events that can be intercepted by a single application without compromising the UX
Pretty much the only solution that satisfies all these criteria is SMS. There are APIs out there for developers to code to that can easily send SMS (zeepmobile is one, clickatell is another), and clearly SMS does not require a data connection – so it makes for a convenient backchannel.
Likewise SMS can be easily intercepted by a listener daemon.
(Note that on WinMo and S60 the listener daemon can fairly easily prevent the SMS from ever reaching the inbox which is convenient if you want to use SMS to trigger an app without alerting the user) however on Android and Blackberry the user will see the SMS – so you need to make sure it is also human readable.)
So how do you do this cheaply – good question – in the US at least (and in many other countries – but not oddly enough in the UK) you can use email-to-sms gateways – for example if your number on tmobile in the USA is 3105551212 then any email sent to firstname.lastname@example.org would arrive at your handset as a text message (which could be intercepted by an SMS listener – etc you get the idea).
There are a number of email to sms gateways (in fact almost every US carrier – small and large) supports them.
But we’re not quite there yet – in order to nicely push content to your user’s application – you need to know both the user’s phone number (which you can ask them for during signup) and the carrier (so you can figure out which email to sms gateway to use).
Which brings me to the final piece of the puzzle – geoIP location from something like http://www.handsetdetection.com in order to determine the carrier.
That’s it – enjoy writing push notification like functionality – until Google gets its shit together and sets up proper push polling for Android (and Nokia does likewise).