we all know that battery life sucks on mobile phones. especially the kind of smartphone mini computer wifi/gps/bluetooth wonders that we’re interested in.

So when it comes to LBS solutions like ours we were faced with an interesting problem.

(a) No data driven push channel easily accesible (iphone o/s 3.0 will provide one – which is great – but that’s only one platform)

(b) Requirement for always-on styled behaviour

(c)  GPS sucks battery life, 3G radio sucks battery life

What does a third party developer do ?

In the end our solution was obvious – but it didn’t seem so at the time. We first thought – Hey no problem – let’s just keep the data connection open the whole time. That way – when you get an incoming echo – you’ll see it right away. Yeah. That was a good idea. NOT.

Problem with that idea is that your smartphone battery dies in less than 3 hours. In other words our users would kill us.

Second idea was to simply Ping the central server every so often to check if there were any new events. Say every minute or every 2 minutes…for 24 hours.

Again – not so great on batteries (startup and shutdown of data connection eventually takes a toll on battery life) – but more to the point it’s kind of daft because the majority of those Pings are wasted.

What we settled on was a third idea – essentially a hybrid of a Polling ping – and using SMS to wake-up the phone you are trying to reach (if it’s asleep – in echoecho parlance)

Tuning the algorithm (how long is polling cycle, what is the frequency of pings within the polling cycle) is interesting – and will be influenced by user activity. It sets up an interesting catch-22 – because perversely if you want to save battery life (for your own phone) you shorten the polling cycle but then everybody else has to SMS you to wake up the data connection.

Yet if you kill your own battery life you save other people money.

So it’s a funny pseudo-altrustic  set of conditions. I think we optimised it well – but as ever – the market users will decide.

Hmmm (again) – this does bring up an interesting philosophical debate – given the battery/push channel constraints – a developer must decide what carries more weight in LBS systems – Time or Accurate Location…Sort of like a version of Heisenberg’s Uncertainty Principle – the more accurate the time sampling of the location the less battery life you will have (or the more accurate the location e.g. GPS – the less battery life you will have).

The solution to this will be a clean push backchannel implementation across all platforms – but we have a long way to until that happens.


One response to “batteries…hmmm

  1. Pingback: echoecho version 1.8 on android – push and lots of other stuff… | echoecho – locations and stuff…

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s