Best Practices from Oracle Development's A‑Team
-
Technologies / Mobile
April 7, 2015
Building iBeacon based apps with Oracle MAF
Introduction
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.
Main Article
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_31313" align="alignnone" width="250"] | [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]
iBeacon Basics
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 :
| Field | Size(bytes) | Description |
|---|---|---|
| UUID | 16 | An identifier chosen by the application development team to identify beacons at a high level based on their own use-cases. |
| Major | 2 | An identifier to narrow down the beacon to a particular region or subset. |
| Minor | 2 | 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.
How applications use beacons - Beacon regions
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 :
- With only UUID: which will define an abstract region that may correspond to multiple physical locations. For example: with the Acme Supplies example above, a region with just the UUID (common for all beacons deployed by Acme in all their stores) may be called "Acme Store Vicinity" and matches the proximity of any acme store.
- With UUID and Major: matches all beacons using a specific combination of UUID and Major. For example: An Acme Store that is located in Redwood Shores, CA, and matches al beacons deployed in that one store
- With UUID, Major and Minor: matches a single beacon. For example, the Sporting Goods department in the Redwood Shores location of Acme Store.
Applications keep track of beacon regions and primarily use two techniques to do so : Ranging and Monitoring
Ranging
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 :
| Proximity | Description |
|---|---|
| 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
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.
General Architecture for Beacon enabled 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.
Implementing iBeacon support for Oracle MAF applications
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 :
- Invoke a rest service on application startup (from a background thread so as not to hinder the start-up performance)
- The rest service delivers a JSON array containing the beacon identifiers we have deployed and a decision tree to use to deliver notifications.
- For example, the JSON array might include something simple like a Beacon UUID and a String message which the application can interpret as "when within the vicinity of <UUID> then show a notification with <message>"
- The decision tree can be updated at regular intervals to keep it current.
The general architecture of the service would be :
- Provide a REST service that returns information based on the user identity (and further attributes of the identity like the loyalty profile)
- The rest service delivers a JSON array containing the beacon identifiers we have deployed and a decision tree to use to deliver notifications.
- For example, the JSON array might include the beacon UUID, Major and minor which identifies the home furniture department in a store and a message about a special offer, which the application can interpret as "when within the vicinity of <UUID> then show a notification with <message>"
- The decision tree can be updated at regular intervals to keep it current.
- The application uses Local Notification to let the user know about the event.
iOS approach
Implementing the Cordova plugin for iOS is relatively simple since iOS natively supports both ranging and monitoring of beacons with the native APIs. The approach here is to simply build the Cordova layer on top of the Native support to expose the Native APIs to the Javascript layer. The native API works as follows :
- The application asks for the user's permission to use location services.
- The application invokes a REST service that returns information based on the user identity (and further attributes of the identity like the loyalty profile)
- The application can now use the cordova abstraction of the native APIs that signals the iOS platform of the beacon identifier information the app is interested in, and to inform the application when the device is in range of one of those beacons.
- CLLocationManager - Keeps track of the beacon regions and notifies the app when a beacon that it is interested in is within range.
- CLBeaconRegion - Looks for devices whose identifying information matches the information you provide. When that device comes in range, the region triggers the delivery of an appropriate notification.
- CLBeacon - This class represents a beacon that was encountered during region monitoring.
- The application starts monitoring for beacons providing the API with a list of BeaconRegion objects.
- Whenever the device is within the vicinity of a beacon, the platform identifies that the application had expressed interest and notifies the application.
- The application is woken up momentarily to receive the message if the application was in the background or killed.
- The application receives the beacon information in this message and can react to the beacon in any way. (In our case, we will use a local notification to alert the user)
The Cordova plugin tries to mimic these classes to keep the programming model familiar and aligned with the Native APIs.
Android approach
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 :
- The application asks for user's permission to use location and bluetooth functionality at the time of installation.
- When the application starts up, we start an android service to monitor for beacons based on the advertisement PDU in the bluetooth signal broadcast.
- This is how we can distinguish between beacons and other bluetooth signals.
- The service is packaged as part of the application itself.
- Expose an API similar to iOS with abstractions for Monitoring and Ranging.
- The application level logic remains the same - The app will invoke the same REST service that returns information based on the user identity (and further attributes of the identity like the loyalty profile)
- When the application moves into range of a beacon, the bluetooth service (and not the platform, like in iOS) will let our app know about that event.