Separate artifacts into peripheral & central features

[matthewadams]

Just proposing that the peripheral role features should be released separately in a different artifact, like no.nordicsemi.kotlin.ble:peripheral-client-android, and the current central role features into no.nordicsemi.kotlin.ble:central-client-android. If you wanted, you could release a combined artifact under the name no.nordicsemi.kotlin.ble:client-android for backward compatibility/convenience.

I feel like the peripheral features are for a smaller audience than the central role features, and many of the features of the central role are already present that folks could use, accelerating its time to completion and GA release.

[philips77]

Hi, Great feedback! May I ask why would you want to have them separately?

I still need to write the server part, and I believe I will also need the Peripheral there, e.g. to notify about new connections, so for sure there will be some refactoring. But perhaps you have something else in mind.

[matthewadams]

I think they should be separated for a couple of reasons.

• Many more folks use BLE devices than make them, so they only need the central role. Also, albeit a minor consideration, it prevents module bloat.
• Most of the central role features are complete, according to the readme, so this gets the central role code to production sooner.

[philips77]

Then the client-android is what you need. Client allows to scan, connect, exchange information, request PHY, etc.

The server will allow to set up a local GATT Services to allow interactions from the device side. Let's take the Proximity Profile as an example. It states, that the Link Loss and Immediate Alert services should bo on both sides. Each triggers the alarm on the other. This of course could be done using notifications, but by spec notifications notify about updated characterstic value, and should not be used to control. For that, each side acts both as a client and server: writes the control values and allows the other side to control it.

The client and server are separate from advertising. A peripheral advertises, while central connects to it. Both central and the peripheral can have client and server.

[matthewadams]

@philips77 I don't understand your latest response. Please clarify, as I'm requesting that you simply separate this artifact into two artifacts, one that is intended for clients of bluetooth devices, and one that is intended for suppliers of bluetooth devices.

[philips77]

I would say that none of this code is for suppliers of Bluetooth devices. As of now, this library can only on Android. Usually, Bluetooth devices run some low lever C / Rust firmware and are using SDKs prepared by chip manufacturers, like nRF Connect SDK, Zephyr, nRF 5 SDK, etc.

This library is designed to build mobile (for now) apps that scan for them, connect and exchange data by writing / reading or observiing value changes. In some cases it is the remote device that scans and the phone acts as a peripheral by advertising and exposing GATT services. This depends on the use case. Either way, it's to make a moble app that works with them. It would also be possible to make an app for 2 Android devices that connect to each other, one acting as peripheral, and the other as central. Again, no matter which is the central and which is the periphera, both can act as a client and server simultanously.

The separation of Peripheral from client-... makes sense, as it can be by a server-... modules as well. I'm not there yet, unfortunately.

[rhkean]

just weighing in.... @matthewadams , does your company require you to use GA-only sdk's and libraries for your production releases? Are you asking for the pieces you need pulled out into a separate package so it can be labeled as non-beta?

just curious, I've worked in environments like that. :-)

[matthewadams]

No, not really @rhkean . I'd prefer production libs, but if they work & my tests pass, it's fine. Maybe I'm missing something here. Anyway, I've already ported over to use Kable for now. Not married to anything, just want the best lib for the job rn.

[philips77]

My plans for final 2.0 are big, so it will take a long time before we get there. When it comes to stability, I think we're good. The API still may change when I start implementing mocks and server side, hence the alpha.

I'm working on migrating Memfault Library to BLEK 2 and it went smoothly. That's why I'm making a lot of these alpha releases now. With each one I think that was the last one ;)