Fixes characterist data lost issue

[odahcam]

This PR refers to #60 and fixes the issue.

Also I would like to suggest the use of a buffered channel (Channel.BUFFERED) instead of just using the broadcast channel with size 1, to avoid data loss again.

[odahcam]

Just noticed that on #53 a user suggested using a buffered channel too, appart from using Flow, a buffered channel would be nice for reliability.

[LouisCAD]

How is blocking a thread helping here?

Did you try with #53 instead?

[odahcam]

That's an awesome question, but I don't have any answer. This just works, rather we like it or not.

[odahcam]

Did you try with #53 instead?

Yes, in fact I thought that had solved the issue, but turns out nothing but this solved this crazy behavior.

[sjp4]

Hey - just ran into this and have seen the issue before...

The problem is that Android re-uses the same BluetoothGattCharacteristic instance forever (i.e. in consecutive calls to onCharacteristicChanged, the same instance of the characteristic is passed - but with different values). This means that recipients must read the value from the BluetoothGattCharacteristic before allowing onCharacteristicChanged to return - otherwise the value might have changed by the time they get around to reading it.

In this case, the change to runBlocking works only if the channel is unbuffered, and the finalconsumer of the value reads it immediately upon reading from the channel. Buffering doesn't necessarily solve this either - queued instances would all be updated by Android.

There are a couple of potential solutions, without making it blocking.:

• Push a deep copy of the BluetoothGattCharacteristic object to the channel (so that it doesn't matter if the original instance value changes in the future). This is the option I went with in a work project (currently messing around on a personal project..).
• Don't push the characteristic object at all; just push the ByteArray. This does lose the convenience of all of the nice type helper functions that Android provides e.g. getIntValue/getStringValue/etc.

[LouisCAD]

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).

[odahcam]

Thanks for clearing it out @sjp4, it makes sense now. So it seems this can be solved by applying the same fix as #56. I won't update this because I can't test it right now, so I'll close this PR and hope we can fix it later. Thanks guys.