Trigger Data and Beacon Servers

The article on iOS and Android Apps explains how beacons transmit unique ids and how, in many scenarios, these ids need to match up with data held elsewhere, not on the beacon, that determines what the app does and what's displayed to the user.

This trigger data can be obtained in many ways (in order of increasing complexity):

  1. Include the data in the Android and iOS apps as fixed data

    While simple, this approach isn't flexible as you won't be able to easily change the trigger data. Nevertheless, it might be sufficient for trials or as a proof of concept.

  2. Subscribe to a commercial ready-made server-side solution

    A number of startup companies provide solutions that tie together beacons, a ready-made server and an SDK to more easily create iOS and Android apps. Sometimes they also provide the apps. These tend to be tightly focussed solutions based on retail scenarios that sometimes tie you into purchasing particular beacons and/or a commitment to a monthly server side licence fee.

    Some of the more mature solutions provide more precise location through use of bespoke algorithms and better security through the use of rolling UUIDs. However, schemes such as this that require connection to beacons will result in shorter beacon and handset battery life. The connection from smartphone to server to resolve the rolling UUIDs also relies on an Internet connection that can be slow or sometimes non-existent.

    You should consider data ownership, data privacy and service level issues when using such complete systems. They also might not be flexible enough or able to be changed for some non-retail scenarios. Probably the largest consideration is whether some of these startups will continue to be around as long as your solution and whether pricing will remain stable. Startups have already started to suddenly impose charges for, what were free, backend services after they have determined they need to make more money. Some service have been discontinued at short notice. Nevertheless, ready-made solutions provide a relatively easy, quick solution.

  3. Use or extend an open source server-side solution

    Software such as the open source SBCMS can be hosted on your own server or automatically on a Heroku cloud server instance

  4. Build your own server side-solution that matches beacon ids with trigger data (text, URLs, images)

    It's possible use any server to host a simple web UI and provide data for apps. Building your own solution doesn't always need to be complex or costly. You can use Backend As A Service (BaaS) providers such as Firebase to provide a custom server with included app APIs without any server-side development. However, as demonstrated with the demise of parse.com, BaaS providers pose similar risks to commercial ready-made Beacon CMS solutions in that they won't necessarily be around into the future. They are probably more suited to proof of concepts or trials.

    A further way of providing for an easier server side is to use Parse server. The closing of parse.com caused the server side to be open sourced. You get most of the advantages of Parse (no server side development and easy to use app SDKs) without the uncertain longevity risks of using a BaaS provider.

Read about our development services

Further Articles:

Choosing UUID, Major, Minor and Eddystone-UID For Beacons

Choosing an Advertising Interval

Choosing the Transmitted Power

Determining Location Using Bluetooth Beacons


Tags: ibeacon, eddystone