Once you are set up with an iBeacon, no matter whether it is a dedicated device or a program running on a host device, you are ready to start writing applications. The iBeacon “protocol” is simple, as we saw in the introductory post: it defines regions in space as “where I see a specified combination of UUID, major, and minor numbers.” There is no descriptive text or mapping transmitted in the packets sent by a beacon. Translation between the beacon’s transmissions and any actions are done entirely within an application running on the receiving device, even if the application is a simple text message to say “welcome to this place.”
For developing applications on iOS, the core documentation is the developer’s guide to region monitoring. For many years, iOS has enabled applications to use the physical location of a device in applications through the CoreLocation framework, which is what users enable in the Location Services settings in the Privacy panel. iBeacon functions were added to CoreLocation in iOS 7.0. Naturally, devices must have hardware support for the underlying Bluetooth Low Energy functions, which in practice means an iPhone 4S or later iOS device. Macs sold since late 2011 also have the required Bluetooth hardware.
CoreLocation provides the conceptual bridge between a beacon’s radio transmissions in the physical world and actions taken by a device to interact with the world. The core capabilities offered by the programming API are straightforward: notifying when a device has entered or left the area defined by a beacon’s transmission, and estimating the distance between a device and a beacon.
Determining when a device has entered or left a beacon’s coverage area is called monitoring. Monitoring can be done in the background, and an application can program the system with a list of up to 20 locations. The CoreLocation framework allows an app to request notifications based on the hierarchy of the numerical identifiers. An app can use the broad level of just the UUID, which would correspond to any location with a beacon. In a retail chain, the UUID alone would match any store in the chain. Apps can also request narrower monitoring functions by combining the UUID with a major number; this combination in a retail chain would be used for all the beacons within a single store. For the most specific type of notation, an app can combine the UUID with both a major number and a minor number, and that trio would correspond to a department or possibly even a single display within the store.
Once a coverage area is entered and beacon transmissions are detected, the app is allowed about 10 seconds to execute pre-programmed tasks. Monitoring services are supplied by the operating system, so an app does not need to be running to take action because it will be launched when entering the beacon coverage area. Apps can perform any task that they can be programmed to do, with common examples being to send notifications to the lock screen or call a web service for further information.
The second function that is performed by CoreLocation is determining the distance from a beacon, which is called ranging. CoreLocation can summarize the distance from a beacon as immediate, near, and far; the three constants roughly correspond to centimeters away, meters away, and within reception range of transmissions. Ranging requires more activity on the part of the app, and cannot be done in the background on iOS.
To use proximity services within iOS applications, users must enable location services (which enables CoreLocation), and individual apps must be permitted to access location services.
Bluetooth Low Energy support is not as widespread in the Android world, though many recent devices do have the necessary hardware. The Radius Networks open-source Android iBeacon library, available for Android 4.3 and later, duplicates many of the functions of the iOS CoreLocation framework, with the addition that ranging can be performed in the background (albeit at the cost of higher power consumption).