iOS 6.0 in Sydney? No suburb for you!

September 27, 2012, 4:08 am

Just discovered an interesting bug in the iOS CLGeocoder object.

At goCatch we use the reverse geocoder to get a good estimate of the passenger's pickup location, so having the passenger appear in the correct suburb is pretty important. When you get a response from the CLGeocoder you get the following fields:

@property (nonatomic, readonly) NSString *name; // eg. Apple Inc. @property (nonatomic, readonly) NSString *thoroughfare; // street address, eg. 1 Infinite Loop @property (nonatomic, readonly) NSString *subThoroughfare; // eg. 1 @property (nonatomic, readonly) NSString *locality; // city, eg. Cupertino @property (nonatomic, readonly) NSString *subLocality; // neighborhood, common name, eg. Mission District @property (nonatomic, readonly) NSString *administrativeArea; // state, eg. CA @property (nonatomic, readonly) NSString *subAdministrativeArea; // county, eg. Santa Clara @property (nonatomic, readonly) NSString *postalCode; // zip code, eg. 95014 @property (nonatomic, readonly) NSString *ISOcountryCode; // eg. US @property (nonatomic, readonly) NSString *country; // eg. United States @property (nonatomic, readonly) NSString *inlandWater; // eg. Lake Tahoe @property (nonatomic, readonly) NSString *ocean; // eg. Pacific Ocean

The two that I am particularly interested in this case is locality and subLocality. Because we want to show the most relevant neighborhood to the taxi driver, we prefer subLocality over locality. This has worked fine right up until iOS 6. Unfortunately with the iOS 6 release, the API has started returning the two values reversed. So for Ultimo (suburb or neighborhood) in Sydney (city), we get back:

[locality Ultimo] [subLocality Sydney] [administrativeArea New South Wales]

I checked the same results for the mission district in San Francisco] and it is working fine. I guess Apple would have noticed if that area was similarly broken:

[locality San Francisco] [subLocality Mission] [administrativeArea California]

With the iOS 6 release we stated getting a lot of taxi drivers complaining about jobs coming up in "Sydney" as opposed to a specific suburb. Ouch!!

We have added an iOS 6 specific hack which swaps the values until Apple gets around to fixing the issue.

Permalink - Comments - Tags: Development,iPhone,iPad

48 hours of coding FTW! Literally

September 23, 2012, 10:13 pm

Last week Vodafone Australia held a 48 hour hackathon where developers team up with a charity to build an app to fix a pain point in their organisation. The winning charity receives a 30,000 prize decided by a panel of judges including Guy Kawasaki.

The dev team at goCatch decided to leverage our experience tracking taxis in realtime to help St John Ambulance with managing volunteer first aid workers in the field at events like New Years Eve in Sydney.

We built an app that we think will help save lives at these events and the judges agreed.

We won! Here are some photos from the 48 hours of lunacy.

Permalink - Comments - Tags: Development,iPhone,iPad

New icon for Ballet Index

July 18, 2012, 7:25 am

Pretty happy with the new icon design for Ballet Index (and Ballet Lite). Thanks to Lindz.AD and 99Designs.

Permalink - Comments - Tags: Development,iPhone,Ballet Index

How accurate is the iPhone GPS?

July 2, 2012, 12:26 pm

I have written in the past about the inaccuracy of location data provided with "Significant Change" background location updates. The solution to this problem is simply to use Significant Change as a trigger (ignoring the data it gives you), then use CLLocationManager startUpdatingLocation to get the quality location data.

So how accurate are the updates that you get from this approach?

At goCatch we track the locations of thousands of Taxis driving all over the world. The data gives us some useful insight about how to measure the proximity of passengers and drivers, hopefully you will find it useful too.

For the 650,704 location updates I used in my tests, I found the average accuracy radius was 246m. 85.1% of updates had an accuracy of less than 100m. Indeed if you eliminate the wildly inaccurate values (>1km) the average accuracy radius is only 91m.

In this last chart you can see the spread of accuracy updates over the first km. I am guessing the outlying (>1km) values are for phones with no GPS and no nearby Wifi that are relying on the cell tower triangulation (same as Significant change) to get a location.

N.B. When I say "GPS" in the title I am actually talking about all the sources of location data that the iPhone passes to the app (GPS, Wifi and Cell proximity).

Permalink - Comments - Tags: Development,iPhone

Photoshop hex RGB to a UIColor

February 2, 2012, 1:16 am

Adam (the awesome goCatch designer) and I got sick of converting from hex RGB colors to decimal UIColor initialisation params, so I wrote this script.

import sys if (len(sys.argv) != 2): print ("convert.py <hex color>") sys.exit () color = sys.argv[1] if (len (color) != 8): print ("convert.py <8 char hex color>") sys.exit () # get the two character chunks red = color[:2] green = color[2:4] blue = color[4:6] alpha = color[6:8] decRed = int (red,16) / 255.0 decGreen = int (green,16) / 255.0 decBlue = int (blue,16) / 255.0 decAlpha = int (alpha,16) / 255.0 #iOS code print ("[UIColor colorWithRed:%.4f green:%.4f blue:%.4f alpha:%.4f];" % (decRed, decGreen, decBlue, decAlpha)) #Android code print ("private static final int COLOR = 0x"+alpha+red+green+blue);

Yep it also does an Android static final int. We love Android too ;)

Permalink - Comments - Tags: Development,Android,iPhone