Mobile Forms for Eddystone and iBeacons

We recently came across TracerPlus, a system that allows you to scan and collect Eddystone and iBeacon data into forms on iOS and Android.

A desktop application builder is used to design the forms:

The system can be used to efficiently take inventory and capture additional data from beacons for example, unique identifiers for items, battery life, temperature and URL information.

TracerPlus provides semi-custom mobile applications at a fraction of the cost of custom software.

Reactive Bluetooth Programming

Connecting programatically to a Bluetooth device involves the following stages:

  1. Scanning for peripherals’ advertising
  2. Connecting to the peripheral via GATT
  3. Discovering the peripheral’s services
  4. Discovering the peripheral’s characteristics
  5. Reading and writing to a characteristic’s value and/or monitoring characteristic value change via a Notify

Each of these stages is asynchronous because each takes a relatively long time in computing terms. This means the code needs to call something but continue running to remain responsive to other events and later process the result of a stage via a callback from the Bluetooth library. The connection isn’t reliable because it’s wireless. Different kinds of failure, also notified via callbacks, require the code to go back one or more stages depending on the severity of the error.

All this gets very messy, confusing and difficult to understand in the resultant code. Reactive (Rx) programming attempts to solve such asynchronous complexity problems by using the Observable Pattern to broadcast and subscribe to values and other events from an Observable stream.

There are Reactive implementations such as RxSwift on iOS and RxJava on Android. There are also Bluetooth specific libraries such as RxBluetoothKit for iOS/OSX and RxAndroidBle that make asynchronous Bluetooth code in Swift/Java much easier to understand and maintain.

Reactive programming used to be very popular not just for asynchronous programming but also for general Android programming. It has fallen out use for general programming mainly due to Kotlin which is now the ‘latest thing’.

Naive developers have a tendency to want to use the ‘latest thing’ or ‘clever techniques’ while experienced developers choose the right tool for the job. A common error is to over-use and combine design patterns, such as observables, in simple scenarios, which hinders rather than simplifies understanding.

The nature and relative complexity of your project should determine whether it’s worth using Reactive code. It’s not necessary an ‘all or nothing’ decision. It’s possible to choose to use observable pattern techniques only in parts of code with extreme asynchronous complexity rather than in all the code.

Cordova Bluetooth LE Plugin Updated

Cordova, previously called PhoneGap, is a mobile cross platform development tool that uses web pages and Javascript.

Don Coleman of Chariot Solutions maintains the open source cordova-plugin-ble-central custom plugin (blue area in above diagram) that provides a Bluetooth API for scanning, connecting to service characteristics, reading and writing values and characteristic change notification. Examples are provided.

The recent updates provide support for new permissions and API changes in Android 10+. It’s great to see the plugin updated because the problem with many tools and libraries is that they rarely keep up to date with changes in the underlying iOS and Android APIs.

Which Beacons are Compatible with iOS and Android?

We often get asked the question which beacons are compatible with iOS and Android. All beacons, whether iBeacon, Eddystone or sensor beacons can be used with iOS and Android. The compatibility is achieved through the implementation of common Bluetooth standards on these mobile platforms.

However, there are some caveats:

  • Android only supported Bluetooth LE as of Android 4.3. Older devices can’t see Bluetooth beacons. Over 95% of users are on Android 4.3 or later so most people can see beacons.
  • Apple iOS doesn’t have background OS support for Eddystone triggering. While iOS apps can scan for, see and act on Eddystone beacons, the iOS operating system won’t create a notification to start up your app when there’s an Eddystone beacon in the vicinity.

Rather than beacons being compatible with iOS/Android, we find that there are more problems with particular Android devices not seeing beacons, when in background, due to some manufacturers killing background services.

Also see Which Beacon’s Are the Most Compatible?

View iBeacons

iBeacon Scanning and Region Monitoring on iOS 14

On iOS 14, Apple has changed the permissions required for iBeacon region ranging and monitoring. There’s a new Precise Location permission that needs to be set to ON for the app to continue to work. Apps that granted location permissions prior to iOS 14 default to Precise Location ON after upgrading so as not to break old code.

Apps should now detect if Precise Location is enabled. Apple has unfortunately deprecated the class function authorizationStatus(). The best way of determining whether you can detect iBeacons is to examine the location accuracy.

There’s an explanation on Medium by Nick Patrick and there’s a post on StackOverflow with an example how to detect whether Precise Location is on by examining the location accuracy.

Remote Team Management Using iOS as an iBeacon

S Sindhumol of Cochin University of Science and Technology, Kochi, India presents recent research into Implementation and Analysis of a Smart Team Management System using iOS Devices as iBeacon (pdf).

The key thing about this research is that it uses iOS rather than a beacon to advertise iBeacon. The system allows the entire team to determine the location of other members, perform location based tasks, receive announcements and communicate via instant chat.

iBeacon Team Management Screens

The paper contains some useful analysis of accuracy of distance measurement on distance, interference, measured power and obstructions:

Effect of iBeacon distance accuracy with obstructions
Effect of iBeacon distance accuracy with presence of another iBeacon
Effect of measured power variation on proximity and accuracy
Effect of obstructing objects on RSSI and Accuracy

On iOS it’s only possible to advertise iBeacon if the app is in foreground:

The major limitation of the proposed app is battery drainage while keeping the app active all the time in the foreground

A more practical system would have been implemented by having the users carry a separate wearable beacon. This would have allowed presence to be detected when the app isn’t in foreground and there wouldn’t have been a problem with excessive iOS battery use.

New iOS CoreBluetooth Mock Library

Nordic Semiconductor, the manufacturer of the System in a Chip in beacons and other smart devices has a new iOS CoreBluetooth Mock Library. The library allows an app to be used with dummy Bluetooth calls rather than real APIs.

The main use is for automated testing. If testing code on a server or test bed you want tests to run reliably and predictably so that you can get a pass or fail indication. Replacing the wireless part of the app allows other parts of the app to be tested.

The library also has other uses:

  • Taking screenshots without setting up a particular physical scenario
  • Developing code quicker through better repeatability
  • Developing code without need of a physical phone or tablet
  • Developing code when a Bluetooth peripheral isn’t available yet and/or is still under development

A caveat is that this library is for CoreBluetooth and not for CoreLocation. The former is intended for communication with devices that are not iBeacon. Apple forces you to use CoreLocation to detect iBeacons because they don’t provide the standard Bluetooth advertising via CoreBluetooth when seeing iBeacons.

The CoreBluetooth Mock Library is useful for detection of non-iBeacon Bluetooth devices such as fitness trackers, health monitors, Eddystone beacons and sensor beacons.