Using asFlow() from no.nordicsemi.android.ble.ktx

[natalyabl]

Hi!
Last year we upgraded our Android app to use android.ble.ktx:2.7.5 to communicate with sensors we develop. We are working on upgrading to 2.9.0 but there are a few extra changes we have to do on our side.
Recently we've noticed an increase on delays in the communication and discovered that most of the time some packages are going missing.

We decided to use asFlow to get notifications from the sensor like this:

        notificationsFlow = setNotificationCallback(readCharacteristic).asFlow()
        enableNotifications(readCharacteristic).enqueue()

which we call in the initialize function.

In our app, we scan for the sensor, connect to it and then we request some information from the sensor which we collect from notificationsFlow. For some reason, the first packet we are expecting, sometimes is not received. Is there an specific way of doing this?
I haven't found an example using asFlow(), could somebody maybe send across an example or is it not reliable to be use as it's annotated with @ExperimentalCoroutinesApi?

Thanks!
Nbl

[philips77]

Hello,
You're using it correctly. Let me check if there are no bugs on our side.

[philips77]

Could you do an experiment?
Have a look at this code:

Android-BLE-Library/ble-ktx/src/main/java/no/nordicsemi/android/ble/ktx/ValueChangedCallbackExt.kt

Lines 24 to 34 in 9504515

	fun ValueChangedCallback.asFlow(): Flow<Data> = callbackFlow {
	// Make sure the callbacks are called without unnecessary delay.
	setHandler(null)
	with { _, data ->
	trySend(data)
	}
	awaitClose {
	// There's no way to unregister the callback from here.
	with { _, _ -> }
	}
	}

In line 28 we're calling trySend(..), which may fail, if the buffer is full (last event wasn't consumed). I suspect that this is the reason why you would loose packets. The documentation for callbackFlow says:

A channel with the default buffer size is used. Use the buffer operator on the resulting flow to specify a user-defined value and to control what happens when data is produced faster than consumed, i. e. to control the back-pressure behavior.

Could you add buffer(capacity = ...) on the resulting flow and check if it helps?

Another option would be to replace trySend(data) with trySendBlocking(data), which block the sender when the buffer is full. If you have the library added as a module from source, could you modify the source and test it?

[philips77]

Could you try the PR made and

1. Check if number of lost packets dropped to 0
2. Paste LogCat logs if it didn't

[natalyabl]

Hi!
thanks for your quick reply!
I've tried the PR and it seems to be working alright but I also noticed a few other problems with our implementation that I had to change.
I'll try both trySend and trySendBlock with the new implementation and come back to you.
Thanks a lot for your help!
Nbl