By Carlos Chang-Oracle on Apr 13, 2015
Want to alert your customer to a special loyalty discount offer when they enter the menswear department in one of your retail stores? Want to present information about a famous artist’s life when a visitor to your museum nears one of the artist’s paintings? These are just two of the many real-world scenarios made possible by the use of iBeacon technology.
This blog post provides an introduction to iBeacon technology and a description of how to build two different MAF apps – one that pretends to be an iBeacon and another that detects iBeacons and uses the local notifications functionality provided in MAF 2.1.1 to inform the user, even when the app isn’t even running.
To deploy these apps to iOS devices you will need an iOS developer account.
What is a beacon?
A beacon is a device that is intentionally conspicuous to draw attention to a location, such as a lighthouse sitting on the edge of a cliff.
In in the Internet of Things (or IoT), a beacon is a small electronic device that transmits a regular radio signal according to the Bluetooth v4 Low Energy spec (otherwise known as “BLE”). A beacon typically does no more than advertise its existence by transmitting a unique identifier and can last for months on a single cell battery.
Any BLE-enabled device, such as a modern smartphone, can detect a beacon by listening for BLE-based transmissions.
Whilst the possibilities appear endless, typical applications for beacons currently include retail stores, exhibition halls, museums, places of employment and homes, where users can be alerted to information pertaining to their current location within a building.
What is (an) iBeacon?
iBeacon is a technology introduced by Apple in iOS 7 that defines a standard for how a beacon identifies itself (or “advertises”) in its BLE transmissions. Any beacon that implements this standard can be called an iBeacon.
Most beacon manufacturers implement the iBeacon standard by default, whilst some can also be configured to use their own proprietary protocol. It’s also possible to configure a post-2012 iOS device, or Mac running OS X Mavericks (not Yosemite), to act as an iBeacon.
Whilst the iBeacon technology is included in the iOS Core Location framework since iOS 7, any BLE-enabled device can detect iBeacons and various libraries exist for use on devices running Android 4.3 or above.
How does iBeacon work?
The iBeacon standard defines three properties that determine a beacon’s identity:
- A proximity UUID (universally unique identifier), which is a 128-bit value that uniquely identifies one or more beacons as a certain type or from a certain organization.
- A major value, which is a 16-bit unsigned integer that can be used to group related beacons that have the same proximity UUID.
- A minor value, which is a 16-bit unsigned integer that differentiates beacons with the same proximity UUID and major value.
Every iBeacon must advertise a proximity UUID, whilst the advertisement of major and minor values is optional. All beacon manufacturers allow customers to modify these values on their purchased beacons.
A typical iBeacon deployment (e.g. within a retail store chain) would see all beacons advertising the same proximity UUID, those in a particular location (e.g. a single store) advertising the same major value, and the minor values being used to uniquely identify each beacon.
When using iOS Location Services, an app wishing to detect iBeacons must start by monitoring for an iBeacon region. A region is defined by the proximity UUID and optionally major and minor values, and can therefore represent one or more beacons. Consider an app for a retail store chain that monitors for a region defined only by the proximity UUID. This app will be notified when any of the retain chain’s beacons are detected. Alternatively, if the region being monitored is defined by proximity UUID and major value, the app might only be notified when a beacon from a particular store (represented by the major value) is detected.
Once an app has been launched and the user has given permission for the app to monitor for beacons, the app will be notified when the device enters a beacon region that is being monitored, even if the app is not running and even if the device has been restarted. If the app is not running, iOS launches the app for a short period (around 10 seconds), allowing the app to receive and react to the event. Typically, the app fires an immediate local notification to notify the user.
When a user’s device enters a beacon region, the app can start ranging for individual beacons within the region to determine its relative proximity to each beacon. This is used to determine when the user is in the immediate proximity of a particular beacon, so that information related to that beacon can be displayed to the user. The relative proximity is an approximation that can be affected by physical objects including walls, water and the human body. Most beacon manufacturers allow customers to modify the transmission power and advertising interval on their purchased beacons, so as to fine-tune the distance at which the relative proximity is considered ‘immediate’.
When iOS Location Services determines that it can no longer detect any beacons in the region, it notifies the app that the beacon region has been exited. In practice, I’ve found that this takes around 30 seconds, but some bloggers have reported much longer times.
Libraries exist for Android that provide similar functionality to iOS Location Services, but I have not explored these (yet).
How to create an iBeacon client app
Click here to continue reading the full post.