iBeacons development… speed
So now that iOS 7 is finally out – it took me a little while to get used to the aesthetics and I only have nits with default button hit-area designation (there is none) & the appearance of UIPickers (really?!) – I’ve been playing with CoreLocation / CoreBluetooth and the beacon functionality. It works pretty well 99% of the time.
However I find that the averaging of the beacon accuracy doesn’t match with the typical speed of someone walking with an iOS 7 device in their hand/pocket. The ranging trip events (immediate, near, far) or straight accuracy numbers have a lot of averaging built into them. The polling of signal(s) is easily quick enough, but walking up to my iPhone 5 takes a few seconds before correctly reporting the accuracy… accurately. Sometimes it can take a little longer than a few seconds.
This translates into a feeling of lag. The technology isn’t laggy… the averaging (however it’s accomplished) seems to be the bottleneck. No one wants flaky or intermittent reporting. But there is a fine balance here. You want UIs to be snappy and responsive.
If a user walks close to a beacon, you want that UI to fire right away. Otherwise you’re standing in front of one for a while before the UI can trigger. You may lose that user for that item as they have moved on – or you might pop a UI for something they are no longer standing in front of. A case of musical UIs gone astray.
Perhaps it’s a lot snappier on a 5S or even 5C (doubt it), but as it stands now it’s borderline production ready unless I am doing something wrong in my code.