iOS crashes trying to read notification data after connection has been established.

[marcel-bluestone]

I experience 100% reproducible crashes, trying to subscribe to a notification stream after the connection has been established.
I do search for BLE devices and connect to the right one offering the service I need. After that I move on to a new screen and subscribe to a notification characteristic. This is where the crash happens.

I am on iOS 14
Flutter 2.1
flutter_reactive_ble 2.7.3

Here's my crash report:

Assertion failed: file flutter_reactive_ble/PluginController.swift, line 103
Assertion failed: file flutter_reactive_ble/PluginController.swift, line 103
* thread #1, queue = 'com.apple.main-thread', stop reason = Assertion failed
    frame #0: 0x00000001ac4afff8 libswiftCore.dylib`_swift_runtime_on_report
libswiftCore.dylib`_swift_runtime_on_report:
->  0x1ac4afff8 <+0>: ret    
libswiftCore.dylib`_swift_reportToDebugger:
    0x1ac4afffc <+0>: b      0x1ac4afff8               ; _swift_runtime_on_report
libswiftCore.dylib`_swift_shouldReportFatalErrorsToDebugger:
    0x1ac4b0000 <+0>: adrp   x8, 344158
    0x1ac4b0004 <+4>: ldrb   w0, [x8, #0x998]
Target 0: (Runner) stopped.

[werediver]

As a workaround, have you tried putting an extra delay before subscribing to the characteristic? (300–500 ms) Does it make any difference?

[marcel-bluestone]

I tried that but unfortunately it did not help.
In addition, after the connection has been established, it takes around 3-4 seconds before I switch screens and start the subscription.

[werediver]

Are you working with a custom peripheral? (that is one of the questions in the suggested issue template, by the way) Is there anything special in it's behavior?

[marcel-bluestone]

Sorry, yes I forgot to mention, it is a custom peripheral offering one service with 3 notification characteristics. There is nothing special about this device and it works without problems with the same dart-code on android devices.

Which additional information could be helpful?

[werediver]

Hm, if you know: does you peripheral always immediately sends an update when a new subscription is established? As a workaround, if you have control over this, you could try introducing a delay of a few hundreds milliseconds before sending the first update on the peripheral side.

Ah, here it is: #137. Exactly your case. You may want to check the discussion there.

[marcel-bluestone]

ok, thank you.
Inserting a delay of 200ms after receiving the subscription event and before sending notification data helped!

[werediver]

Don't get me wrong. There is still a bug in the library (we can track it in #137). But it's better to have a bug with a workaround, than without 🙂

[marcel-bluestone]

...and after a couple of test-runs it seems that the workaround only helps every 2nd time. The crashes happen on every 2nd attempt to read the subscribed notification data.
The error messages are identical to the one pasted above.

in addition, I do receive flutter messages that the connection has timed out unexpectedly:

flutter: Connection State Update Failure, Reactive Ble Backend
flutter: ConnectionError.failedToConnect
flutter: Error Domain=CBErrorDomain Code=6 "The connection has timed out unexpectedly." UserInfo={NSLocalizedDescription=The connection has timed out unexpectedly.}
flutter: Error unsubscribing from notifications: PlatformException(flutter_reactive_ble.Central.(unknown context at $1036dc3e0).Failure:1, The operation couldn’t be completed. (flutter_reactive_ble.Central.(unknown context at $1036dc3e0).Failure error 1.), {}, null)
[log] PlatformException(CBErrorDomain:6, The connection has timed out unexpectedly., {NSLocalizedDescription: The connection has timed out unexpectedly.}, null)

[werediver]

I'd suggest to read through #137 and the tickets referenced there. You may find some useful information there. I assume you tried increasing the delay on the peripheral a bit (I usually recommend 300–500 ms).

Still, this ticket appears to be a duplicate of #137.

[marcel-bluestone]

I changed the delay to 500ms and now I get a 50% change of app crash. Has the fix for #137 made it into 2.7.3 or should I pull it separately as a dependency override to test?

[werediver]

The pull-request #139 was supposed to fix #137, but it had little to no effect to the issue for those who were experiencing it.

#137 is still open. If you come up with a good structural fix, that would be a very welcome contribution. I'm not going to have a lot of time to work on it for quite a long time, it seems.