iBeacon, Eddystone, Bluetooth, IoT sensor beacons, apps, platforms
There’s a new Capacitor plugin for Bluetooth LE. Capacitor is new way to build web apps. Capacitor’s native plugin APIs allow easy access to common functionality, such as Bluetooth, across multiple platforms.
The plugin supports the web, Android and iOS. It allows scanning, GATT connecting, reading, writing and notifications. The source code is available on GitHub.
Some manufacturers offer SDKs to allow programmatic access to their beacons from iOS and Android.
Most SDKs tend to be poorly implemented/documented, tie your code into using that particular beacon and rarely get updated to use newer mobile platform APIs. They also tend to be thin abstractions over the Android and iOS Bluetooth APIs.
If you rely on a beacon manufacturer that doesn’t update their SDK, it’s eventually the case that the underlying Android and/or iOS API changes such that your solution becomes non-optimal and, in the worse case, breaks.
Instead, when you can, we recommend you use the iOS and Android Bluetooth APIs directly to make your code independent of the beacon type. In this way you don’t end up depending on intermediate code and this has the benefit that you can more easily change beacon providers.
Alternatively, use an independent 3rd party library such as Radius Network’s iOS SDK or one of the many Android Bluetooth libraries.
We get asked a lot which beacons are the most compatible. All beacons, whether iBeacon or Eddystone, are compatible with iOS and Android. There are a few ‘tracker’ type Bluetooth devices around that don’t transmit the right Bluetooth header and can’t be seen on iOS but we don’t sell those.
Almost all beacons are slight derivations of a few standard circuit designs and firmware provided by Texas Instruments, Dialog and Nordic who produce the System On a Chip (SoC) inside beacons. Hence, they all transmit to Bluetooth standards.
The main area that can differ is the Antenna and PCB layout that can lead to different radiation patterns. The ability to detect a beacon isn’t affected and differences manifest themselves as differing beacon signal strength (hence range) and stability.
The main areas where beacons differ is not in compatibility but in physical characteristics such as battery size and waterproofing that are to be found as categories at the left hand side of our store.
One thing people don’t realise is that problems occur with phone compatibility rather than beacon compatibility. Over time, we have discovered about 5% of our customers have problems getting the Manufacturer’s configuration to app connect to beacons on Android. To be clear, this is only when apps need to connect (to change settings) as opposed to only scan for beacons so this doesn’t tend to be a problem (for end users) once everything is set up.
To answer the question, Bluetooth standards are such that all beacons can be seen on all phones and compatibility isn’t an issue. Problems we have seen have been related to phones rather than beacons. We have never had a beacon returned to us because it’s incompatible.
There’s a new app Bluetooth Sleuth by Sean McNeil for iPhone, iPad and Mac.
The app scans for advertising devices, optionally with a specific CoreBluetooth UUID, and displays them including RSSI (signal strength). It can connect to devices that are connectable and then browse device the Bluetooth Services and Characteristics. For iBeacons, it’s also possible to observe region updates for specified beacons.
The app monitors and graphs recent RSSI values. You can also set up your device to advertise iBeacon or custom services with custom Bluetooth Characteristics.
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.
Connecting programatically to a Bluetooth device involves the following stages:
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, 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.
There’s a new app for iOS called Stepping In & Out that uses iBeacons to remind you when you move into or out of an area containing a beacon.
The source code is available on GitHub. It provides an example how to create an app using Swift that triggers when going into and out of zones. This can also be used for commercially oriented applications.
Flutter is Google’s UI toolkit for building native applications for mobile, web, and desktop from a single codebase. There are plugins that add functionality to Flutter. One such plugin is the beacon_plugin that makes it easier to scan and range iBeacons on iOS and Android. The plugin is open source on GitHub.
Gluon is a Java-based cross platform tool that creates applications for desktop, Android and iOS devices using the Gluon Scene Builder.
There’s a Beacons code sample that shows how to scan for beacons or broadcast as a beacon.
