A recent feature request stipulated that the user’s location be visible in the various different maps that appear within the app. This is a common enough request and very easy to implement, but what does this mean for battery life of the device? The GPS radio on any iOS device is the most battery-intensive onboard radio and so having GPS running frequently is a bad idea. Time to profile the GPS radio usage!

Given that MKMapView is pretty mature having been around since iOS 3.0, I suspected that it would be intelligent enough to only use the GPS when necessary to determine the user’s location, such as first using wifi, the device’s IP address or some other less battery-intensive operation to determine if the user’s location is actually within the bounds of the displayed map before getting a more accurate reading to display on the map view.

It appears, however, that this is not the case. Rather surprisingly, as soon as showsUserLocation is set to YES until the time it is set to NO or the MKMapView is deallocated, the GPS will run hot, sucking up your juice. Not only will it do this when the user’s location is nowhere near the bounds of the map view, but also when the map view is not even visible to the user, so it turns out that it’s pretty important to manage this property carefully if you don’t want to drain your users’ batteries.

Written on June 6th, 2014 , All, Dev & Test, Mobile, Tech, Uncategorized


There’s been some discussion recently in the blogosphere about how the business of social software is becoming more and more of a winner-takes-all proposition. It’s at least partially true as everyone wants to be where their friends are and social software products are not perfectly replaceable like Coke and Pepsi. The cost of switching from a Facebook to a Bebo is much higher than simply changing your mind at a vending machine. You grow a social network on one platform over the course of months and years, and it can be a daunting task to embark on a wholesale switch.

Surely this is why Facebook blocks the other players from accessing their API, including Google. The resultant portability of data would make the barrier to switching infinitely less daunting. Thus it seems that there can be only one key player in each major social market, to every other competitors’ detraction.

But does this issue extend to niche social software offerings? At first it might seem true. In the location-based services arena, for instance, it may seem that there can be only one Loopt, or Whrrl, or BrightKite for the same reasons that Facebook is so far ahead of all other players in the broader consumer social sphere. But technologies like OpenSocial, Facebook Connect, Google Friend Connect, MySpaceID, OpenID and oAuth mean that this does not have to be the case. In fact, it is hardly a necessity to even build social features into your products anymore when your products can piggy-back on the platforms of the existing major networks. Thus it seems likely that the winners in the niche market spaces will be ones that eschew building their own propriety networks in favour of augmenting existing networks. If you can bring your service to existing networks rather than having to build your own network then you overcome one of the great barriers to user adoption of social apps: building a trusted network of friends and contacts within the system.

Written on January 27th, 2010 , Uncategorized

richardrauser.com is proudly powered by WordPress and the Theme Adventure by Eric Schwarz
Entries (RSS) and Comments (RSS).