iBeacon Round-Up: Move (to) Me

ibeacon-xcodeWe spent the weekend building and playing with beacons. And there’s good news: if you’re developing with Bluetooth LE you’ll get a lot of exercise. Either that, or you’ll build a little pulley system and attach your beacons to it so you can test without leaving your chair.

Because the problem with beacons is that you can’t use the XCode simulator. So you have two choices: either leave your phone plugged into XCode and move your beacons around to simulate coming into range, or lose the access to the error logs and wander around with your phone.

iBeacon is the Nike of the programming world: they help us aspire to be more fit! Just get used to the stares as you pace back and forth stepping into and out of beacon zones.

Beacons Move
With location-based technology you have a map and then you try to track people and things against it.

With proximity technology, you have a beacon and you track people and places against the beacon.

It seems like a small difference but it’s profound: it doesn’t matter if you move your cash register or the potato chip aisle: you don’t have to update your store map to figure out where to send the coupon for shampoo. The beacon travels. It moves.

And that makes a big difference: you can install beacons in someone’s store but you don’t need to do a big geomapping or planogram project. Just plop the beacon onto the organic kale chip display stand and even if the store owner moves the display your beacon will still work.

Listen/Don’t Listen!
Having said that, triangulating and figuring out how to get your app to listen to the “right” beacon when there’s a bunch of them around can be complicated. Your app will guess which beacon is closest and then change its mind.

This weekend we threw a little timer into the code and it radically changed the user experience. We pushed a ViewController when a user comes into immediate proximity of a beacon, turned off ranging on push, and turned it on again when the user exits the VC. But how to prevent rapid toggles back and forth? A quick little timer:

– (void)restartRange:(id)sender
[self.locationManager startRangingBeaconsInRegion:self.beaconRegion];

– (void)viewWillAppear:(BOOL)animated {
[self performSelector:@selector(restartRange:) withObject:self afterDelay:4];

We also threw a counter in to prevent those sudden toggles you get because Apple incorrectly calls a didExitRegion. But it seems like an inelegant solution – any better ideas out there?

Beacons move us. And beacons move. The Apple API is a bit of a moving target. It’s Monday so it’s good to have the blood flowing.

Any tips you’d like to share? Would love to hear them. Drop them in the comments below.

Let’s Talk

Join our weekly mailing list for ‘BEEKn unplugged’ – I rant a little each Friday and share stuff that doesn’t make it on the site.

Be the Beacon!

5 Responses to “iBeacon Round-Up: Move (to) Me”

  1. Hi Doug, great stuff! Your blog keeps me up-to-date with the latest BLE/iBeacon developments.

    I’m also having a bit of trouble working with multiple beacons that are all close to each other. Assuming there are two beacons in close proximity and both of them have the same UUID but different major values, if I create a region with that UUID, will the app receive separate entry and exit notifications for each beacon? Or is it necessary to create a different region for each beacon by specifying the UUID as well as each beacon’s major value?

  2. Hey Joe – sorry to be so slow.

    Beacon ranging is based on finding ANY beacons that have the UUID you specify in your app. So, your app will say that it has “found a region” regardless of major/minor.

    If it leaves the range of BOTH beacons, it will exit region. But if it’s still in range of at least one, it will say that it’s in the region.

    You might want to think about triggering your actions based on Proximity alone – don’t do anything once it finds or exits, just do something once it comes into a specific proximity value.

    Make sense?

    Or, as you suggest, search for regions twice: but you’ll need two different UUIDs. Then, it will trigger an didExitRegion once it leaves the range of the beacon with the UDID that you specify.

    Kind of depends on your use case – so far, we’re finding didEnterRegion and didExitRegion pretty much useless other than to set the app back to its “non beacon” state a minute or so after you exit a region. (Don’t bother with LocalNotification, the delay is so pronounced it generally creates a weird user experience).

    • Is it the delivery of the notification that’s being delayed by the system or is it the detection of the event that’s slow or both?

      I also noticed that if the user enters the region and then turns off their Bluetooth, the app doesn’t get an exit notification until long after they turn their Bluetooth back on.

  3. (Oh, and to make things even more complicated – your app will falsely call a didExitRegion. We’re using a timer to repeat the check for didExit before we trigger the event to make sure that the call is “real”)


Leave a Reply to Doug Thompson

Click here to cancel reply.

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>