If you are developing an app on Android it can be useful to view Bluetooth packets to debug problems. Johnas Nellen has an article on Medium that describes how to verify communication between Android and Bluetooth devices.
It involves enabling the Bluetooth HCI snoop log in the Android developer options and using ADB to generate a bug report that can be analysed using Wireshark.
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.
MIT App Inventor is a cloud-based tool that allows you to build apps in the web browser. It provides a visual programming block-based environment allowing anyone, even children, to build fully functional apps for smartphones and tablets.
The first 50 registrants are being entered into a raffle to win 10 PIC-IoT boards and vouchers worth €10 and €25 for the Elektor Store.
Avoid the libraries produced by the beacon manufacturers. They tend to add little value, are usually poorly documented and aren’t changed when there are updates to underlying Android libraries. You can achieve everything with the Android APIs. The only exception is connecting via GATT to Sensoro beacons where the Service/Characteristic information isn’t publicly available and hence you have to use their SDK.
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.
However, there are some cases where you must use the manufacturer library. This is usually in cases where there the app needs to connect with the beacon (as opposed to only view advertising scans) to perform beacon specific things. The Sensoro SDK is an example where their private protocol (to prevent squatters) and sensor information can only be obtained via their SDK.
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 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.
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.