Characteristic changed BroadcastChannel losing values

[odahcam]

Some values (usually the first one) that arrive at onCharacteristicChanged never gets to be received from openNotificationSubscription.

I never seen this, why you're saying that?

Take a quick look in the code ahead:

BleGattCoroutines/core/src/androidMain/kotlin/com/beepiz/bluetooth/gattcoroutines/GattConnectionImpl.kt

Lines 278 to 280 in 4a61774

	override fun onCharacteristicChanged(gatt: BG, characteristic: BGC) {
	launch { characteristicChangedChannel.send(characteristic) }
	}

What happens is that the characteristic changed value that's missing always get to this point, but while all values are correct when comming in the method param, not all values gets to the send call inside the launch scope.

So are you saying the value gets replaced by the next value when inside the launch scope?

Yes.

---

Innitially I thought it could be a problem with the broadcast channel itself, but it seems the values never get to be sent on the channel, so it must be this launch scope messing things up. I switched the launch for a runBlocking and things seems to be running fine now. But since I'm blocking the execution now, I don't know if it's the right approach for the library, so I decided to open the issue along with a PR where I will reference this issue.

Thanks in advance.

[Jacek-Galla]

Hi, I think that the problem is with the channel capacity.

BleGattCoroutines/core/src/androidMain/kotlin/com/beepiz/bluetooth/gattcoroutines/GattConnectionImpl.kt

Line 62 in 4a61774

private val characteristicChangedChannel = BroadcastChannel<BGC>(1)

Now capacity is 1, so every new notification will overwrite the old one. I think, that this channel should be BUFFERED

[odahcam]

I also thought that, but changing the channel doesn't solves the issue, as the issue is within the scopes and the callstack execution order and something else I don't remember how to explain, hehe. But some good folk explained very well in a PR a few weeks ago, I believe this is the explanation: #61 (comment)

[LouisCAD]

Quoting myself for future reference as I'll work to fix this:

Hello @sjp4, thanks a lot for sharing your analysis, I now understand how runBlocking can fix it.

I'm not going to merge this quick fix because blocking a thread here can lead to other issues in a mobile app, including slower operation in edge cases.

I think I'll make a deep copy of library created instances of the BGC and BGD classes for now, it will have the benefit of not breaking the API (although other changes might break it a little, namely replacing channels by flows).

[LouisCAD]

Related to #56