BLE Architecture Best Practices?

[libhide]

I am working on an Android app that needs to communicate with a BLE device. I am using Android-BLE-Library for this as this is a production-grade app. I had a question around using the library within an architecture I desire for my codebase.

I would ideally like a way to have clean separation between Nordic and business logic about the device I am working with. Specifically:

• I want a "general peripheral layer" that uses Nordic to expose a BLE API that lets me connect to a peripheral, discover services, read/write to characteristics, etc.
• Next, I want a "device-specific layer" that uses the general layer and exposes functionality to other higher layers of my app

Is an architecture like this possible with this library? My hunch is that it isn't given the recommended usage guide that recommends creating a BleManager instance. But, maybe I am missing something?

I would love any guidance possible here to help me achieve my goal. Pseudo code would be really helpful too.

Thanks!

[philips77]

Hello,
Actually, this was the whole idea behind the BleManager. The desired architecture should be that this class contains all the BLE logic and exposes high-level API, which you'd use from your app.

You may name your BleManager something.. less BLE, like a Connection, or Device API. Have a look at nRF Blinky: https://github.com/NordicSemiconductor/Android-nRF-Blinky

The device API is exposed using Blinky interface, which is implemented by the BlinkyManager. The implementation is internal and can be changed to test/etc. In nRF Blinky this is done using Hilt here.

[libhide]

@philips77 Makes sense, yeah. I had a feeling that that was the idea behind the BleManager approach.

The device I am working with has a pretty large API surface though. Won't the manager get too bloated in this case? Is there a straightforward way in your opinion to separate out services and characteristics so that they are injected into the manager rather than be created within it? 🤔

[philips77]

Well.. this lib is quite old. I had some ideas of having services divided into modules but that never materialized.

Also, when you start a new project, consider checking Kotlin BLE Library (BLEK), branch version/2.0. This is the one that are working on, with much better API, 100% Kotlin, suspendable methods, much better testability, etc. The client and scanning parts are complete. We're working on server side and mock-client.
It would be great also to get feedback.