Closed smashteevee closed 2 years ago
The library maintains 4 states per device: CONNECTING, CONNECTED, DISCONNECTING and DISCONNECTED. New connections are only made to devices that are in DISCONNECTED state. Similarly, cancelConnection only tries a disconnect if the device is CONNECTED.
Thanks. This is better. I now only send a cancelConnection if the connectionState != DISCONNECTED and I haven't hit any issues since.
Again, really appreciate the when you've done here!
I've posted your Medium blog post code snippets to implement a command queue to sequentially perform GATT operations. This mostly works, where given a list of BLE scan discovered peripherals, I connect to each, read some characteristics, then disconnect before moving on to the next.
However, my connection attempts sometimes fail (error or terminated by GATT server, as expected) and in my code, before disconnecting, I check to see if the peripheral exists in Central's connected peripherals ListArray before calling cancelConnection. This is to avoid calling cancelConnection for something NOT connected.
1) Is this the right way to check if I can call cancelConnection? Sometimes, an errored connection peripheral will be present and my code ends up calling cancelConnection and hangs as there is no Disconnect callback event
2) what actually happens if I call cancelConnection on a disconnected peripheral? It doesn't seem to trigger any events per Logcat debug. Ideally I can detect if it fail or times out
Thanks!