Monthly Archives: December 2009

I can get some satisfaction…

in our continued attempt to use existing tools at our disposal to efficiently code and communicate with the echoecho userbase – we recently created the echoecho community on get satisfaction.

Seeded with some initial questions and answers – we hope and expect this to grow into a vibrant community that we will continue to foster.

Whether it’s to query particular functionality or recommend new features/mashups – by all means hit us up…

you learn something new every day.

some people have asked why there was such a long delay between the previous two posts – well let’s just that the development cycle on non-iphone platforms is errm just a little teensy weensy bit more convoluted than on the iphone.

I could give you a few examples – but I’m only going to need one.

Blackberry…

Leaving aside the absurdity that users must give any individual 3rd party blackberry application explicit permission to do absolutely anything (e.g. make an http connection)

How very friendly for users 😉


Yeah no.

There’s a far more absurd problem. As the following article indicates much better than I could summarise there are SEVEN possible methods a BlackBerry can establish a data connection. Yes. Seven. And instead of the O/S cleverly deciding whether to use wifi (if there’s one nearby) or the cell data service, or MDS (the blackberry M…obile D..ata S…ervice) etc etc – like every other platform on the fucking planet (desktop or mobile) – with a BlackBerry the developer must decide this.

This is beyond moronic – but is unfortunately necessary if one wants to participate on the BlackBerry platform.

Here’s the article – Localytics btw are quite cool and we use them on all the platforms we are able to…

The thing is I really couldn’t care less why this was originally designed this way (back in the days when flat rate data only existed for Blackberry Enterprise users) – the fact is that it’s an outdated system which could clearly be replaced by a single API call – with the O/S itself figuring out the best/fastest/cheapest pathway to use.

oh and btw – Merry Christmas.

push…then push harder…

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 3105551212@tmomail.net 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).