Developing a Beacon App

Buying or deploying a Bluetooth LE capable beacon is like one hand clapping if there’s no app to hear. The power of a beacon is that it lets an app “see” the world around it: by listening for the small signal transmitting from a beacon, an app is able to calculate its proximity to that beacon. Based on that proximity, the app can be programmed to do something.

To get you started in developing a Beacon app, we’ve put together this list of links and resources.

Definitions

First, a few definitions. We’re surprised by how much confusion there can be about how beacons work. To start, check our post on Beacon hardware for some quick definitions of Bluetooth LE, iBeacon, Eddystone and Physical Web – terms that are often used interchangeably when they shouldn’t be.

Advertising Packet

One misconception about beacons is that they’re similar to WiFi: they transmit content to an app. There’s this idea that the beacon itself is transmitting coupons, offers, videos or other content to a user’s app. But unless a beacon is coupled with something else (a beacon that also includes WiFi for example) it isn’t doing anything more than sending a very small ‘packet’ of data via radio signal to the world around it.

This packet is called the advertising packet. Because the packet is small, and because the device doesn’t actually DO a lot, it’s a low-energy specification which is both good for the beacon itself and good for the user’s phone or tablet: it doesn’t take a lot of energy to detect or broadcast a signal.

At its simplest level, a packet cloud include:

  • A Unique Identifier which can be randomized (to provide security and avoid your beacon being ‘hijacked‘)
  • Beacon Identifier[s] (Numbers which uniquely identify a given beacon)
  • The Transmission Power Level (TX Power Level)
  • Local Name
  • Services

For a more complex review of the advertising packet, have a look at the Estimote description of its packets for an example, or a reverse-engineered review of the Apple beacon packet on Stack Overflow.

iBeacon – UUID and Major/Minor

Each ibeacon has a set of identifying numbers. The UUID is a general device identifier. The major/minor numbers help you to differentiate beacons and will depend on how you plan to deploy them.

The major number could represent a specific store in a chain, for example, while the minor number represents individual beacons within that store. These numbers are key to programming your app so that it responds to individual beacons.

Eddystone – UID, URL, TLM and EID

EddyStone refers to four distinct, Google originated standards. 

  • EddyStone Universal Resource Identifier (URI)
  • EddyStone Universal Resource Link (URL)
  • EddyStone Telemetry (TLM)
  • EddyStone Ephemeral Identifier (EID)

These four standards provide an interesting array of proximity-based functionality.

Eddystone URI: EddyStone URI is the most direct answer to ‘iBeacon-type’ proximity broadcast. Where the bluetooth proximity profile specifies three key numbers, the Universally Unique Identifier (UUID), the major number and the minor number; EddyStone URI simply has the Namespace Identifier (often called the ‘UID’) and the instance identifier (Instance ID). In layman’s terms eddystone URI uses two distinct numbers as opposed to iBeacon’s three distinct numbers. Otherwise, the two standards are functionally identical to a proximity developer. A native application on the user’s phone (android or iOS) detects the EddyStone URI signal and acts according to how that native application is programmed.

https://github.com/google/eddystone/tree/master/eddystone-uid

EddyStone URL: EddyStone URL allows beacons to broadcast a short URL. This is as opposed to the “numbers” broadcast by the EddyStone URI and iBeacon standards. The design intention of EddyStone URL is to allow chrome browsers on both iOS and android to present a URL to the user based on proximity to a beacon. This URL can appear as a low priority notification in the users lock screen (meaning the link is present, but does not ping when it appears).

The ‘short url’ is an important distinction and may be a limitation depending on your use-case. While current web standards do not define a limit to the length of a URL, an effective limit of 2000 characters exists in web development circles due to maximum character limits in various browsers. The Eddystone URL specification by contrast is currently limited to an effective URL length of 17 characters. 

Physical Web and Eddystone URL have overlapping use cases. The distinction is Eddystone URL can broadcast unencrypted ‘HTTP’ site links whereas Physical Web requires that a webpage be secured with an SSL Certificate and use the ‘HTTPS’ standard. A source of some frustration with physical web configuration has been situations where a specified Physical Web URL is not an HTTPS link or redirects to a non-HTTPS site.

EddyStone TLM: EddyStone TLM is a standard meant to transmit telemetry data to a smart phone from a beacon “sensor”. For example, a beacon that acts as a temperature sensor or humidity sensor. Data throughput is relatively low, but the standard allows disparate sensors to become part of a more integrated application experience using Bluetooth. For example, an integrated guitar tuner and humidity detector.

https://www.mkompf.com/tech/eddystonetlm.html

Eddystone EID: Eddystone EID is an attempt to separate the proximity broadcast, the signal resolver and the associated asset. An EID beacon requires registration with Google to function. Once registered, the google cloud acts as the resolver, delivering the correct resource to the user who detects the beacon. The can be useful where a bad actor could clone or spoof an iBeacon, EddyStone URI or EddyStone URL; EddyStone EID is meant defeat use-cases where it would be valuable to “clone” a beacon.


In other words, EddyStone EID is a protocol that’s trying to answer the question, “what is the physical web equivalent of a domain name service?”. On the Internet, when you enter a URL, the domain name service translates the URL you type into an IP address. This allows your system to resolve to the correct location to receive the information from the site. EddyStone EID is a similar idea. EddyStone EID allows you to deploy and “ephemeral” number which the Google Cloud then resolves to some resource. This could be a web address, a download link or another type of asset. Google calls the digital asset associated with a EID resolution an “attachment”. While this is a newer standard, it gives us a taste of a post-web world. Practically, this standard allows you to protect your beacon attached resources. Meaning, where a bad actor could clone an iBeacon, EddyStone URI or EddyStone URL; EddyStone EID is meant defeat use-cases where it would be valuable to “clone” a beacon.

Calculating Proximity

We think proximity is a big deal. It represents a paradigm shift from geographic mapping: instead of your app knowing where it is based on geography, you can now trigger actions based on what it’s close to. In most cases, you’ll think of beacons as fixed: you place one over the door of your store, for example. But this ignores the larger implication of beacons which is that they can move.

An app calculates proximity based on the power level and signal strength of the beacon. On iOS devices, Apple has created an API to make this easier to calculate and has a class that lets you determine whether you app is Immediate, Near or Far from a beacon. But you can also use the signal and power data from the beacon directly to make your own calculations – and can be as granular as you want in detecting proximity.

Challenges

Once you dive into detecting proximity to a beacon, you’ll immediately start to see the primary challenge of beacons: interference in the environment (for example, metal shelves on a store or other signals competing with your beacons) and quirks in the software running a phone or tablet will make it harder than you think to calibrate your app to your beacons. These challenges aren’t uncommon and include behavior that you might not expect:

  • Your app might detect a beacon, find a second beacon, and then toggle between the two
  • Your app might toggle between different distances, thinking that it’s Near a beacon and then Far
  • Your app might lose all contact with beacons for a very brief interval
  • There might be delays in receiving lock screen notifications
  • Your app will behave differently when it’s in background mode versus “in front” and won’t detect beacons at all if the user has hard closed the app

Don’t worry, these problems are not your fault and we encourage you to check our post on the topic for some common problems.

Building Your ‘Stack’

Similar to misunderstandings about whether beacons deliver content, there’s also confusion over the ‘pieces’ that make up a beacon experience. At a minimum you need:

But your beacon experience might also be designed to include:

  • A Beacon Management App: you might need some way to change the firmware on a beacon. Because most beacons can’t communicate directly with the Web because they lack a WiFi or other connection, you use an app that communicates with your beacon and updates its firmware.
  • A Beacon Management ‘Cloud’: You have two choices for managing your app’s response to beacons: hard code it into your app, or pull key data from the cloud. For example, you might start by deploying 2 beacons. You could hard code their ID numbers into your app. But what happens if you add more beacons? Instead of updating the app itself, you can update the data on a server and your app can ‘pull’ this information. This puts the burden for keeping your list of beacons into a cloud service and means you don’t need to push an app update every time you add a new beacon or want to change values that your app relies on.
  • A Content Management System: Similarly, and like most apps, you can either code content directly into your app or program your app so that it pulls from the ‘cloud’. For example, you might want a coupon to appear when a user is near a beacon. But instead of hardcoding the coupon into the app, you pull the content from a server. This allows you to change or update the coupon on the fly without needing to push an app update to your users.

Resources and Tutorials

This list is by no means exhaustive but might help you get started in designing your ‘beacon-ized’ experiences.

Designing the Experience

Kinvey Provides Amazing Insights on the BLE/iBeacon Experience and User Considerations

Taking Bluetooth LE for a Test Drive (Nerdery)

Key Decisions in Building Your App

Recognizing iBeacon Challenges

Common Bugs in iOS iBeacon

How Long Does It Take to ‘Range’ Beacons?

Apple faces its own challenges in iBeacon Roll-Out

Android vs Apple: Differences Between Devices

Tutorials, Tips and Examples

An Arduino Alternative to iBeacon and Using Evothings Studio

How Do iBeacons Work? (Warski) – An excellent overview with lots of links to Stack Overflow and other sources.

DevFright Tutorial

iBeacon Tutorial: Focus On Estimote

Using a Timer to Overcome Region ‘Toggling’

Getting Started with Estimote (and the Follow-Up)

iBeacon, Sencha Touch and Phone Gap

iBeacon for Android: Library

Virtual Beacons

Turn Your Mac Into a Beacon

The Estimote Virtual Beacon

Have Code? Have Tips?

Let us know – we’ll add them to the list. In particular, we’d like to hear about GitHub code repositories that will help give examples of how you’ve solved some of the common challenges.

And don’t forget to jump on our weekly mailing list!

3 thoughts on “Developing a Beacon App”

Leave a comment