Unable to reconnect after disconnecting

[R-Emagina]

Describe the bug
Using the example code, I'm unable to reconnect to a BLE device once I've connected and disconnected from it.

To Reproduce
Steps to reproduce the behavior:
Using the example code on iOS 14.4:

1. Scan all devices (no service UUID given)
2. Connect to any (?) device
3. Disconnect from device
4. Try to connect again, nothing happens, here are the logs:

flutter: 12:19:01.355 - Start ble discovery
flutter: 12:19:05.608 - Stop ble discovery
flutter: 12:19:06.775 - Start connecting to 707FB3DF-77AF-82A5-82D7-B387097904F5
flutter: 12:19:06.797 - ConnectionState for device 707FB3DF-77AF-82A5-82D7-B387097904F5 : DeviceConnectionState.connecting
flutter: 12:19:07.843 - ConnectionState for device 707FB3DF-77AF-82A5-82D7-B387097904F5 : DeviceConnectionState.connected
flutter: 12:19:09.774 - disconnecting to device: 707FB3DF-77AF-82A5-82D7-B387097904F5
flutter: 12:19:12.526 - Start connecting to 707FB3DF-77AF-82A5-82D7-B387097904F5
flutter: 12:19:12.538 - ConnectionState for device 707FB3DF-77AF-82A5-82D7-B387097904F5 : DeviceConnectionState.disconnected
flutter: 12:19:16.846 - Start connecting to 707FB3DF-77AF-82A5-82D7-B387097904F5
flutter: 12:19:16.851 - ConnectionState for device 707FB3DF-77AF-82A5-82D7-B387097904F5 : DeviceConnectionState.connecting
flutter: 12:19:16.853 - ConnectionState for device 707FB3DF-77AF-82A5-82D7-B387097904F5 : DeviceConnectionState.disconnected
flutter: 12:19:19.128 - Start connecting to 707FB3DF-77AF-82A5-82D7-B387097904F5
flutter: 12:19:19.133 - ConnectionState for device 707FB3DF-77AF-82A5-82D7-B387097904F5 : DeviceConnectionState.connecting
flutter: 12:19:19.136 - ConnectionState for device 707FB3DF-77AF-82A5-82D7-B387097904F5 : DeviceConnectionState.disconnected

I've tried the same flow with an other device (Bose headset) and the behavior was the same.
I've tried the same flow with nRF Connect and had no issue connecting&disconnecting endlessly.

Expected behavior
Should be able to reconnect to device

Smartphone / tablet

• Device: iPhone 12 Mini
• OS: iOS 14.4.1
• Package version: 5.0.1

Peripheral device

• Vendor, model: Custom
• Does it run a custom firmware / software: yes

[cjcdev]

I am having the same issue.

[riccardocescon]

I have also encountered this problem with IOS issue #411
I tried then the library version 3.0.0 and it worked, try a version downgrade

[R-Emagina]

@riccardocescon yes I saw this issue but I'd rather stay up to date while developing my new app but most of all if this bug also happens with the example app it's worth mentioning :)

[riccardocescon]

@riccardocescon yes I saw this issue but I'd rather stay up to date while developing my new app but most of all if this bug also happens with the example app it's worth mentioning :)

I agree. Just for testing can you try out to use that version and see if it works or if it still fail? So we know if that issue is related or not

[R-Emagina]

I'm having trouble building the 3.1.1 version for now. Could it be cause by my env (like Xcode's version, 13.1)?

Here's part of Xcode's output:

/Users/vercors/MainLocal/Dev/Mumming/flutter_reactive_ble-1/ios/Classes/ReactiveBle/Tasks/CharacteristicNotify/CharacteristicNotifyTaskController.swift:7:23: error: reference to generic type 'Task' requires arguments in <...> private let task: Task ^ <Any, <#Failure: Error#>> _Concurrency.Task:2:23: note: generic type 'Task' declared here @frozen public struct Task<Success, Failure> : Sendable where Failure : Error { ^ /Users/vercors/MainLocal/Dev/Mumming/flutter_reactive_ble-1/ios/Classes/ReactiveBle/Tasks/CharacteristicNotify/CharacteristicNotifyTaskController.swift:9:18: error: reference to generic type 'Task' requires arguments in <...> init(_ task: Task) { ^ <Any, <#Failure: Error#>> _Concurrency.Task:2:23: note: generic type 'Task' declared here @frozen public struct Task<Success, Failure> : Sendable where Failure : Error { ^ /Users/vercors/MainLocal/Dev/Mumming/flutter_reactive_ble-1/ios/Classes/ReactiveBle/Tasks/CharacteristicNotify/CharacteristicNotifyTaskController.swift:13:53: error: reference to generic type 'Task' requires arguments in <...> func start(characteristic: CBCharacteristic) -> Task { ^ <Any, <#Failure: Error#>> _Concurrency.Task:2:23: note: generic type 'Task' declared here @frozen public struct Task<Success, Failure> : Sendable where Failure : Error { ^ /Users/vercors/MainLocal/Dev/Mumming/flutter_reactive_ble-1/ios/Classes/ReactiveBle/Tasks/CharacteristicNotify/CharacteristicNotifyTaskController.swift:18:34: error: reference to generic type 'Task' requires arguments in <...> func cancel(error: Error) -> Task { ^ <Any, <#Failure: Error#>> _Concurrency.Task:2:23: note: generic type 'Task' declared here @frozen public struct Task<Success, Failure> : Sendable where Failure : Error { ^ /Users/vercors/MainLocal/Dev/Mumming/flutter_reactive_ble-1/ios/Classes/ReactiveBle/Tasks/CharacteristicNotify/CharacteristicNotifyTaskController.swift:22:37: error: reference to generic type 'Task' requires arguments in <...> func complete(error: Error?) -> Task { ^ <Any, <#Failure: Error#>> _Concurrency.Task:2:23: note: generic type 'Task' declared here @frozen public struct Task<Success, Failure> : Sendable where Failure : Error { ^ /Users/vercors/MainLocal/Dev/Mumming/flutter_reactive_ble-1/ios/Classes/ReactiveBle/Tasks/CharacteristicNotify/CharacteristicNotifyTaskController.swift:14:24: error: value of optional type 'CBService?' must be unwrapped to refer to member 'peripheral' of wrapped base type 'CBService' characteristic.service.peripheral.setNotifyValue(task.params.state.isOn, for: characteristic) ^ /Users/vercors/MainLocal/Dev/Mumming/flutter_reactive_ble-1/ios/Classes/ReactiveBle/Tasks/CharacteristicNotify/CharacteristicNotifyTaskController.swift:14:24: note: chain the optional using '?' to access member 'peripheral' only for non-'nil' base values characteristic.service.peripheral.setNotifyValue(task.params.state.isOn, for: characteristic) ^ ? /Users/vercors/MainLocal/Dev/Mumming/flutter_reactive_ble-1/ios/Classes/ReactiveBle/Tasks/CharacteristicNotify/CharacteristicNotifyTaskController.swift:14:32: error: value of optional type 'CBPeripheral?' must be unwrapped to refer to member 'setNotifyValue' of wrapped base type 'CBPeripheral' characteristic.service.peripheral.setNotifyValue(task.params.state.isOn, for: characteristic)

[riccardocescon]

It may be, i remember i had issues similar to this one. You can fix those issue with xCode helper (fix button) and then try building again

[remonh87]

Versions of this library below <4.0.0 do not work with XCode13 since apple introduced breaking changes in version 13. I will check if I can reproduce this behaviour in the weekend

[remonh87]

I can reproduce the issue locally the issue is introduced by #406 . I will spend some time on fixing it and if I cannot fix it this weekend I will revert and publish a new version.

[R-Emagina]

Being quite a beginner on Dart, I'm not sure how this works and if it could help, but while trying out some stuff, I realized that listening to the connectedDeviceStream on device_list fixes the bug.
I insist on the fact that I'm too much of a newbie with Dart to really figure out why this works, but it does.

[werediver]

@remonh87 Indeed, this is due to the buffering: because an app initiates a disconnection by unsubscribing from a device-specific connection status stream, there is no event sink at the platform side when the "disconnected" event is reported by the system, thus it gets buffered and replayed from the buffer whenever a listener appears. And a listener appears when the app is initiating another connection.

@R-Emagina Good observation, and it's coherent with the above hypothesis: the app can drain the connection status buffer by listening to the multiplexed connection status stream, thus avoiding that erroneous event replay. This is, of course, a workaround. There is an issue in the library now.

[remonh87]

fixed with version 5.0.2

[R-Emagina]

Thanks a lot, I will try it out this afternoon!

[cjcdev]

fixed with version 5.0.2

I verified this has been fixed for me in 5.0.2. Thank you so much for taking care of this critical bug so quickly!