Bluetooth Low Energy (BLE) based proximity beacons were first under the spotlight when Apple announced the iBeacon standard. Since then a lot has changed and there are now multiple beacon vendors and offerings on the market. Enterprises are also looking to add proximity based intelligence to their mobile offerings. In this article, we introduce you to beacon technology and show you how you can build support for beacon based interactions in your MAF application. We will will also take a look at Oracle's cloud based offerings that can enhance this experience and provide valuable 360º insight in to the data.
In this article, we will quickly review what iBeacons are, the various standards and solutions on the market today, and how you can build standards based support for beacon technology in your MAF applications. We will also show how you can leverage local notifications in MAF (available since MAF v2.1.1) to trigger based on the proximity to beacons even when an application is not running. Although proximity detection and beacon interaction are essentially client oriented activities, Oracle's cloud offerings play a vital role in transforming these client side interactions into two-way, context-aware, customer conversations for real world applications. We will see how a real world application is built with the Oracle technology that provides context and intelligence support for proximity based applications.
[caption id="attachment_31314" align="alignnone" width="250"] A beacon triggered Local Notification from a MAF application on iOS. The application was in the background when the device detected its proximity with a beacon and triggered the alert. The device was not locked for the screenshot, but the behavior is the same.[/caption]
iBeacons at its core are simple Bluetooth transmitters with a power source that broadcasts a signature. This broadcast signal can be picked up by any bluetooth capable receiver like a smartphone when it is within the beacon's broadcast range and the smartphone or tablet can then perform actions based on this proximity information. The iBeacon standard defines that an advertisement packet emitted by a bluetooth device should include the following bits :
|An identifier chosen by the application development team to identify beacons at a high level based on their own use-cases.|
|An identifier to narrow down the beacon to a particular region or subset.|
|An identifier to further qualify the beacon. The combination of UUID+Major+Minor should uniquely identify the beacon (and therefore the region the beacon is representing)|
An example of this might be Acme Supplies, a nationwide retailer would choose a UUID across all their stores, to uniquely identify their beacons from other beacons that might be nearby. The major number may signify the store number, so the combination of the UUID and the major number now identifies a particular Acme Supplies Store. The Minor number may be used to identify fine grained regions within a given store like sporting goods or home furniture.
Apple Inc., who created the iBeacon specification describes it as "a new class of low-powered, low-cost transmitters that can notify nearby iOS 7 or 8 devices of their presence." As such, iOS provides native support and APIs for interacting with transmitters that adhere to the iBeacon specification which lays down guidelines that bluetooth device manufacturers have to meet in order to certify their devices as iBeacon compatible.
Android does not have native support for iBeacons like iOS, but since iBeacons are simple bluetooth transmitters, apps can be built on Android that directly use the bluetooth stack provided by Android to interact with bluetooth devices of any kind - including iBeacons. The closest standard that offers interoperability is the Alt Beacon proposal by Radius Networks Inc. This article will show you how to use the Alt Beacon android library to integrate it with a MAF application for iBeacon support on Android as well.
Applications can use beacons in a variety of ways that include providing context awareness and proximity based cues for people to find locations nearby or interact with their environment. To simplify application development, the concept of a beacon region is used. A Beacon Region is an abstraction for identifying one or more physical regions based on their beacon attributes like UUID, Major and Minor. A region can be defined in three ways :
Applications keep track of beacon regions and primarily use two techniques to do so : Ranging and Monitoring
Ranging is accomplished by a set of APIs that provide a list of all beacons that are visible to the device(smartphone/tablet) in a given region, together with an estimated proximity indicator and signal strength from the device to each beacon. Ranging gives the application very fine grained detail on proximity and iOS also applies some filters to further quantify the proximity as follows :
|Immediate||Very close or touching the beacon. Highest confidence level in the proximity measurement.|
|Near||Strong signal reception indicative of a clear line of sight. Usually 1-3 meters in distance, but obstructions can cause signal attenuation which may cause the device to report a different proximity range based on signal strength.|
|Far||Lower signal strength. This may not always be due to the signal originating from afar, but maybe due to signal attenuation. This indicates that the confidence in accuracy is too low to classify it as Near or Immediate.|
|Unknown||The proximity could not be determined. Could be because there were far too few measurement samples to report a proximity measurement.|
Ranging is supported when the application is running in the foreground, and has a higher power consumption impact.
Monitoring is a more passive form of getting proximity based alerts that work even when the application is in the background or even when the application process is not running at all. With region monitoring, and application may track up to 20 regions (remember however that a region may correspond to multiple physical locations) and can be alerted when the device enters or exits a region. Monitoring does not require the app to run in the foreground, but can be combined with MAF support for local notifications to enable the user to launch the app based on proximity to a region. Monitoring has a lower impact on power consumption but does not include active signal strength measurements or proximity filters. An application can register a list of regions that it wants to be notified by the underlying APIs, and whenever the OS detects that the device is in range of one of the beacon regions that an application has expressed interest it, it notified that application. this notification is usually an entry event which signals that the device just entered in to range of a region or an exit event that signifies the opposite. The OS takes on the responsibility for notifying the interested applications.
The iBeacon standard relies on an iOS device for intelligent communication, since the beacon itself is a disconnected "lighthouse" that keeps broadcasting the same bits of information (like a signature) repeatedly. Most beacon manufacturers however implement features to differentiate their products on the market by implementing features outside the iBeacon standard's specifications. These typically range from sensor based information like temperature, or altitude at the beacon's current position, to enterprise grade cloud platforms to manage the fleet of beacons. Needless to say, these custom extensions are made available through vendor specific APIs which when used, will lock the application down to a single beacon manufacturer. The sample that we present here, does not leverage any vendor specific API (and therefore vendor specific functionality) and sticks to the iBeacon specifications.
This paves the way for a general architecture for implementing basic functionality for applications that interact with beacons. with most applications we have two fundamental use-cases to achieve. The iBeacon capable App needs to know and update itself of the beacon signatures it needs to listen to, and the enterprise needs to configure how the application reacts to specific beacons in the context of a business use-case. In other words, the app needs to be decoupled from the beacons themselves while having the ability to discover the beacon signatures that the app should be listening and reacting to. The enterprise needs to change how the application should react to a beacon in order to achieve a business goal.
Since MAF has been designed with easy extensibility and the ability to interface with the native layer using Cordova, developing support for Beacons becomes a simple exercise. MAF uses the Cordova layer to facilitate communication bridges from the WebView component, within which a MAF application runs, to the lower level native APIs. In this exercise, we will use both a pre-built Cordova plugin to demonstrate how MAF's support for Cordova immediately makes your application development faster and also develop extensions to this Cordova plugin to examine how the plugin works and how to interface with the native platform APIs. Since MAF applications should ideally support both IOS and Android, we use a common Cordova interface to expose the different underlying native APIs as a consistent unified API that the MAF application can use regardless of the platform to which the application is deployed.
In an application designed to support beacons, a lot of use-cases revolve around the ability to provide context sensitive information to the user inside the app, (like walking up to a museum exhibit or a kiosk). However, the true power is harnessed when the application can intelligently inform the user without the user's active participation, in other words when the phone is locked and in the user's pocket or hand bag. MAF, since v 2.1.1, has added support for Local notification feature that helps you do this. In our example we will cover this scenario and examine how a Cordova plugin in conjunction with MAF Local Notifications can create an application that can react to proximity based events even when the user does not have the phone in his hand.
Therefore, we can split the solution into the mobile app, and a service that can manage the business use-case across the fleet of deployed beacons. The mobile app accomplishes the beacon monitoring, ranging and leverages device sensors and functionality to interact with the use in a context aware manner. The service application lets the business users control how the application reacts when its within the vicinity of a beacon, including managing the fleet of beacons. For example, a department store might wish to rollout a special offer on say, home furniture in the north eastern stores alone based on the user's loyalty profile. This would translate to identifying the beacons in the "home furnishing" department (minor number) in a set of stores (a set of major numbers) for that store chain/retail brand (UUID). Now the service can attach an offer to these beacons and the service can provide this offer to users based on their loyalty profile.
The general architecture of the application takes the form of :
The general architecture of the service would be :
The Cordova plugin tries to mimic these classes to keep the programming model familiar and aligned with the Native APIs.
Implementing beacon functionality on Android is slightly more involved mainly because iBeacon is an Apple specific feature where the iOS platform provides native support in the form of services and APIs. Android unfortunately does not have the same level of deep platform level support of integration with the iBeacon standard published by Apple. We do however have access to the bluetooth stack on the Android device, through Cordova. This means that we need to implement some of the API features that iOS provides out of the box as part of our plugin. Fortunately, there is an alternative open standard being proposed by Radius Networks, called Alt-Beacon, which promises interoperability. we will leverage this library in conjunction with the bluetooth stack on the device to identify bluetooth signal broadcasts from devices identifying themselves as beacon (as opposed to a wireless headset, speaker, or a fitness tracker) and accomplish both monitoring and ranging functionality. Since this will be the same application developed in MAF, using a different code path since it will be running on android, the architecture and the JS API we use on the MAF layer will be the same. The complexities of the Android implementation due to lack of platform support are encapsulated in the Cordova plugin implementation. The sequence of events are runtime would be :