Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

iBeacon - Difference between proximityUUID and region.identifier

I am a bit confused about the importance of a CLBeaconRegion UUID and the string identifier. If my CLBeaconRegion already has an unique ID, what is the point of forcing the usage of an additional, non-unique string identifier? Is it purely "cosmetic"?

Since users will not be able to scan and connect to beacon regions as they do with WiFi (and SSIDs) for example, and since the receiver app needs the CLBeaconRegion pre-coded and pre-defined in order to enter and range for beacons in a region, what's the real usage of the identifier?

I've seen examples where people are using it for place things like com.companyname.app, which I thought made more sense, in case the identifier was used to match the signing certificate of the app (but it seems no!). Others have been using it to place names like "Beacon Example", "Apple", "Kitchen".

In other words, I don't get why the receiver also needs to specify a region.identifier since it doesn't know to which broadcaster name it will connect. No matter how I name the broadcaster, the receiver will always get the identifier defined on its side.

like image 868
John Doe Avatar asked Dec 13 '13 08:12

John Doe


1 Answers

The CLBeaconRegion string identifier has nothing to do with the ids in iBeacon transmissions. It is simply a lookup key used by CoreLocationManager for keeping track of multiple regions.

You can make its value whatever you want, but people often use a package-style qualifier because it is an easy way to make an app-specific unique string.

The main purpose of the id comes if you want to modify or stop ranging/monitoring of your region. By using the same id, CoreLocation knows exactly which region you are referring to.

In the example below, we construct region1, then start monitoring for it. We then change the minor identifier that we are monitoring for in region2 and start monitoring for that. Because the exact same string identifier is used in region1 and region2, CoreLocation knows to replace the first monitored region with the second one.

CLBeaconRegion *region1 = [[CLBeaconRegion alloc] initWithProximityUUID:[[NSUUID alloc] initWithUUIDString:@"2F234454-CF6D-4A0F-ADF2-F4911BA9FFA6"] major: 1 minor: 1 identifier: @"my.made.up.unique.identifer];
[_locationManager startMonitoringForRegion:region1];
CLBeaconRegion *region2 = [[CLBeaconRegion alloc] initWithProximityUUID:[[NSUUID alloc] initWithUUIDString:@"2F234454-CF6D-4A0F-ADF2-F4911BA9FFA6"] major: 1 minor: 2 identifier: @"my.made.up.unique.identifer];
[_locationManager startMonitoringForRegion:region2];

This is most commonly used to stop monitoring for a region. Like this:

CLBeaconRegion *region = [[CLBeaconRegion alloc] initWithProximityUUID:[[NSUUID alloc] initWithUUIDString:@"2F234454-CF6D-4A0F-ADF2-F4911BA9FFA6"] major: 1 minor: 1 identifier: @"another.made.up.unique.identifer];
[_locationManager startMonitoringForRegion:region];
...
[_locationManager stopMonitoringForRegion:region];

In this second example where we stop region monitoring, it is really that string identifier inside the region object that is important in getting CoreLocation to stop monitoring that region.

like image 89
davidgyoung Avatar answered Sep 28 '22 00:09

davidgyoung