Are you one of the people who have a love-hate-relationship with Bluetooth? It feels magical if your smartphone automatically connects to your wireless headset. But other times setting up the Bluetooth connection is a lot more cumbersome than plugging in an audio cable.
Why is it that Bluetooth works great within, for instance, the ecosystem of Apple products, but your iPhone just won’t connect to your car or kitchen appliances – especially because the Bluetooth technology has been around for more than 20 years? Can it be that hard?
Having implemented several Bluetooth-connected mobile apps, we have faced many challenges with all kinds of devices – from cars to coffee machines. We have tested endless hardware configurations, worked hand-in-hand with hardware producers and chip vendors, and saved our clients countless pitfalls creating companion apps for their hardware or use case.
If you consider making your product(s) Bluetooth enabled and providing an outstanding app to your users, then keep reading: we will share our thoughts, insights, and learnings along with why we strongly believe Bluetooth can be a game-changer for your business.
To start, find a short video about how Bluetooth and Bluetooth Low Energy (BLE) work:
In the current Internet of Things (IoT) era, anything is becoming connected to the World Wide Web. Given collective data gathered via sensors, trackers, and wearable devices – combined with the power of machine learning – new, smart services can be created. It can be as simple as a Bluetooth enabled heart rate monitor that keeps logs of your readings on your mobile device or some AI-powered irrigation systems that waters your crops depending on the weather forecast and actual soil conditions.
Oftentimes, however, limitations such as device dimensions, manufacturing cost, or power consumption prevent devices to use WIFI or LTE to connect to the Internet. Leveraging Bluetooth – in particular Bluetooth Low Energy (BLE) – enables developers to mitigate these problems and still enable wireless connections through our mobile phones without additional costs.
Bluetooth Classic vs Bluetooth Low Energy (BLE)
Bluetooth has been around for more than twenty years and is still evolving. With Bluetooth version 4.0, released in 2014, Bluetooth Low Energy (BLE) was introduced. BLE significantly differs from Bluetooth Classic.
Bluetooth Classic serves well for use cases that require the transmission of large amounts of data with fast data rates such as audio streaming. After scanning for available devices, an end-to-end connection can be established, maintained, and data be continuously transferred.
Bluetooth Low Energy (BLE) on the other hand was specifically designed for low power consumption devices such as temperature sensors or fitness devices that have fewer restrictions in terms of data transfer speed.
Advantages of BLE
BLE is built around the concept of a Generic Attribute Profile (GATT). A profile is a structured approach of how a Bluetooth device exposes data to e.g. a mobile phone for a specific use-case. In essence, a profile is a defined set of services and each service includes a collection of characteristics to transfer data (read, write, or subscribe to notifications) – much like an API. Characteristics can also be protected and require prior device pairing and key exchange before data can be transferred.
There are many predefined profiles and services for different use cases – such as the “Health Device Profile (HDP)”. If hardware vendors stick to these specifications, the integration of, for instance, a heart rate monitor with mobile phones should be effortless. Oftentimes, small discrepancies in either implementation, unfortunately, lead to incompatibility and consequently frustrated users.
Another advantage of BLE is that devices regularly “advertise” their presence by broadcasting some data that can be picked up by “listening” Bluetooth devices. In contrast to Bluetooth Classic, BLE can add a small payload – for instance the latest temperature reading – to the advertisement data. Thus, receiving devices don’t even need to actively connect to the sender to receive relevant information. This is also commonly referred to as “Beacon applications”.
Recipe for success:
our 7 hands-on tips and tricks
We are driven to build an outstanding app experience for users. Especially with Bluetooth connectivity in mind, the project can be set up for success by making fundamental design and process decisions before any line of code is written.
1. Work hand-in-hand with the hardware vendor
Most frustrations in any Bluetooth related project can be avoided by having the hardware vendor – the one building and programming the Bluetooth enabled device – and the app developers join forces and work closely together. In some cases, close collaboration even with the Bluetooth chip vendor can be beneficial and timesaving as already subtle differences between chip or Bluetooth stack versions can have a significant impact on the communication between your devices.
That being said, if you build different kinds of devices and expect them to connect to the same app, ensure to use the same Bluetooth chip in all devices to save yourself countless hours of testing different hardware configurations over and over again.
2. Bluetooth specification
Familiarize yourself with Bluetooth Classic and BLE. If possible, use BLE as it has proven to be a lot more reliable, easier to work with, and less battery consuming which therefore leads to better user experience.
3. Supported mobile platform version
Although Android supports Bluetooth Classic since very early versions and added official support for BLE in Android version 4.3, it’s highly recommended to only build Bluetooth enabled apps for Android 5.0 “Lollipop” or later versions (>85% of all Android users). In later versions, the platform’s Bluetooth stack implementation is a lot more stable.
iOS 5 introduced support for BLE. As Apple is a lot more radical with its update and support strategy you should not have to deal with devices that don’t support Bluetooth.
4. Android vs iOS
Both platforms implemented their own interpretation of the Bluetooth standard to simplify the Bluetooth integration for their respective developer community. Unfortunately, this causes behavior one would not necessarily expect. For instance, on iOS, you can make many sequential write requests without having to wait for one to complete before triggering another write. If you did the same on Android, you will find that some messages might be dropped. On Android, it’s crucial to queue messages and write them one after another.
Consequently, we recommend an acknowledgment-based communication protocol to ensure messages have been delivered/received successfully and a transfer can be easily retried if needed.
5. Testing, testing, testing, …
As Android devices are very fragmented, come in all forms and shapes, and differ from Apple devices significantly, you have to continuously test different hardware combinations to ensure the compatibility of your changes. Moreover, we highly recommend to also run your tests in real-world situations, e.g. with other Bluetooth devices and signals around, with multiple devices of the same type, with phones disconnecting because they go into battery safe mode, and any other scenario you can think of.
Please note that some Android devices might cause false-positive Bluetooth pairing issues if you test error scenarios over and over. Due to a bug in the Android system, their Bluetooth error stack is not cleared and hence they need to be restarted from time to time to trigger a reset.
6. Bluetooth Debugging
Bluetooth communication is generally very time-critical and hence step-by-step debugging is not very useful as it alters the actual behavior and execution times. Therefore, you should implement fine granular, isolated logging for Bluetooth in your app. If, in addition, you can have access to the Bluetooth device logs you can actually compare sent/retrieved data and see if they match the specifications to determine the root cause of your error.
Another handy tool is a Bluetooth sniffer. It records the Bluetooth traffic – much like a man-in-the-middle proxy – and can provide insights into actually transferred data.
Lastly, we recommend using tools like BLE Scanner to validate if your Bluetooth device is actually available and behaves as expected, independent of your own app implementation.
7. Separate Bluetooth implementation from business logic
You might have gotten the feeling by now, that Bluetooth communication is very fragile if not implemented properly. To separate responsibilities and concerns, it has been proven very effective to extract the Bluetooth related implementation into its own library and call this library from your actual app and business logic. Now, you can easily test your Bluetooth implementation without restrictions and vice versa, test your business logic without relying on Bluetooth communication.
While implementing such a library, you could also consider creating a data type converter. Bluetooth transfers data as bytes, whereas your data types in your app will likely be texts and numbers. Having a single point of conversion between respective data representations can save you a lot of headaches.
In a nutshell
Creating Bluetooth-enabled devices with companion apps can be intimidating – but it does not have to be. If you fully commit and follow our recommendations, your users will be delighted.
We are more than happy to share our learnings with you or support you on your Bluetooth connected applications. What’s the biggest take-away for you? Please provide feedback and drop us an email at firstname.lastname@example.org.
Interested in finding mobile app development experts? Here you can find more information.
#bluetooth #ble #bluetoothclassic #classic #embedded #embeddedevices #android #iOS #development #engineering #IoT #internetofthings #beacon #gatt