How to get services for the peripheral

[carillem]

Hello, potentially a silly question but how do I get the services from the peripheral using the Compose-Multiplatform example? So far I have updated the Delegate function didDiscoverServices, added it as a new DeviceEvent, and have updated the ViewModel's delegate.setListener for the new event but I'm unsure how to get the services and characteristics list.

[Reedyuk]

Do you want to put a pull request in and i can have a look.

Usually when a device is 'discovered' then
android would do

blue-falcon/library/src/androidMain/kotlin/dev/bluefalcon/BlueFalcon.kt

Line 296 in 07ea44b

bluetoothGatt.discoverServices()

bluetoothGatt.discoverServices()

iOS will expose a peripherial with the services already populated.

[Reedyuk]

All periperials should already have 'services' pre-populated.

[carillem]

Hi @Reedyuk, I figured out what I was missing after some fiddling last night. What I was doing was storing the connected device information immediately after connection and wasn't waiting for the discoverServices to be completed. So what I did was:

• Updated DeviceEvent with a new data class:

data class OnServicesDiscovered(val btPeripheral: BluetoothPeripheral): BTDeviceEvent

• Updated the didDiscoverServices function in Delegate to pass in the bluetoothPeripheral:

onDeviceEvent?.let {
            it(BTDeviceEvent.OnServicesDiscovered(bluetoothPeripheral))
        }

• and then in my ViewModel, added a new case for the new event:

is BTDeviceEvent.OnServicesDiscovered -> {
log("in viewmodel: ${event.btPeripheral.services[2].name.toString()}")
// TODO: Store connected device information here

Somewhat related question, do you have a recommended MVVM approach for leveraging BlueFalcon? I was planning on doing 1 viewmodel per view but then I would have to keep passing the connected bt information from view to view.

[Reedyuk]

I'm glad you have got it working.

My recommendation with any sdk, is to always wrap them in their functionality and then communicate via a common interface, this way you wont accidently tightly couple an integration. It also gives you more flexibility if you decide to change to another sdk.

For example, Blue-Falcon is a bluetooth service, so you could have a BluetoothService object that directly interacts with Blue-Falcon and holds all the references, then this bluetooth service could set the 'peripherials' in a 'Repository' which you could fetch.

You could then access all of this via Use-Cases that perform the required logic/merging of repositories and services and your ViewModel would directly interact with the use-cases further abstracting implementation

[carillem]

Awesome. I will give that a try. Thanks for all your help and this amazing library!