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.
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.
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.
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.
Martin covered scanning, GATT, how to maximise data rates, speed vs reliability and using different PHY for enhanced range or data rates. The second part of the talk covers Bluetooth Mesh and proxy nodes.
One thing not mentioned in the slides, to be careful of, is that connection via a proxy node is relatively slow because it’s limited by the GATT connection. Proxy nodes are good for controlling (sending small amounts of data into) a Bluetooth Mesh but poor if you want to use the connected Android device as a gateway for all outgoing data.
We recently came across a library ‘iBeacon scanner android’ for Android that allows you to scan for iBeacon and receive notifications when one or more specific beacons enter or exist range. The source code is on GitHub.
Artem Gapchenko has created a new Android Bluetooth scanning library called Luch that looks for beacons when the app is in the foreground. Unique features include it’s lightweight at a just over 50Kb, it performs RSSI smoothing and it calculates distance based on the RSSI.
We recently started selling beacons that can advertise LINE. This post explains LINE advertising with information on the packet format.
LINE Beacons are used with the LINE messenger service that allows users to send text, video, and voice messages on smartphones and the PC. It’s currently available in Japan, Taiwan, Thailand, and Indonesia. LINE have iOS and Android developer APIs that allow you to hook into the LINE service and include LINE services in your app. The LINE beacon allows your LINE code, called a bot, to receive beacon webhook events whenever a LINE user enters the proximity of a beacon. The beacons allow you to customise your bot app to interact with users in specific contexts. There’s also a beacon banner feature, available for corporate users, that causes a banner to appear in the LINE messenger app when it comes close to a LINE beacon.
Unlike iBeacon, LINE Beacon packets have a secure message field to prevent packet tampering and replay attacks. The secure data is 7 bytes long containing a message authentication code, timestamp and battery level. Secure messages are sent to the LINE platform for verification.
LINE recommend LINE beacon packets be sent at a very high rate of every 152ms. In addition, LINE recommend advertising iBeacon (UUID D0D2CE24-9EFC-11E5-82C4-1C6A7A17EF38, Major 0x4C49, Mino 0x4E45) to notify iOS devices that the LINE Beacon device is nearby. This is because an iOS app can only see iBeacons when in background and LINE beacons can’t wake an app.
We observe that the high advertising rate and concurrent iBeacon advertising aren’t battery friendly and the beacon battery isn’t going to last long.