Closed sleushunou closed 6 months ago
I don't see the connection event firing so many times, but the fact is that this is another abnormal use-case you softeq guys have given me. The read operation is happening, so there isn't really a bug here.
You really need to await the connection event before disconnecting in rapid succession like this to have any hope of waiting out events.
Component/Nuget
BluetoothLE Client (Shiny.BluetoothLE)
What operating system(s) are effected?
Version(s) of Operation Systems
tested on iPhone 12 (iOS16)
Hosting Model
Steps To Reproduce
get IPeripheral from .Scan() subscribe to characteristic (call NotifyCharacteristic method from IPeripheral) call Connect() call CancelConnection() call Connect() again try to read characteristic after connection complete (call ReadCharacteristic method from IPeripheral)
Expected Behavior
characteristic readed immediately or readed with a small delay
Actual Behavior
characteristic readed with 5seconds+ delay
Exception or Log output
instead of logs. Why it happens? It happens because on method below handler of this.WhenConnected() subscription calls several times (5 and more ) at the same time, so this.Native.SetNotifyValue(false, native) calls also several times at the same time. Each call of this.Native.SetNotifyValue(false, native) is write operation to descriptor under the hood (I can see it in logs from BLE peripheral device). This write-to-descriptor operations occurs at the system level, and is performed bypassing the operation queue that you added to shiny library. It looks like there is a system queue of BLE operations in iOS, and our read operation is executed only after all five or more write operations to the descriptor have been completed
` public IObservable NotifyCharacteristic(string serviceUuid, string characteristicUuid, bool useIndicateIfAvailable = true)
{
this.AssertConnnection();
var key = $"{serviceUuid}-{characteristicUuid}";
Code Sample
`
Code of Conduct