Closed graphefruit closed 1 year ago
Howdy @graphefruit
No problems at all 🙂 ... always happy to have feedback/issues raised.
Based on what you're seeing there, I can't really think of anything obvious the plugin could do differently here. The webview is crashing, which means it's the javascript side running into problems. My assumption is some kind of memory exhaustion or call-stack limit caused by the repeated hammering of the connect
method.
This issue only happens if you connect straight after app launch without any prior scans. Based on https://github.com/don/cordova-plugin-ble-central/issues/963#issuecomment-1569272637, most of my applications tend to use option 2, so they scan THEN connect. This avoids the tight-loop you're seeing here, because I won't try to connect until the peripheral has been seen, avoiding the Could not find peripheral
error.
Android will not have this quirk as the Android stack allows us to create the proxy without a scan packet (though that leads to another issue where the first connect often fails...).
For what you're doing above, I'd suggest throttling the reconnect attempts if no prior connect has been made since application launch. E.g.,
function connect() {
let hasConnectedOnce = false
ble.connect(
(data) => (hasConnectedOnce = true),
(err) => {
const reconnectPauseMs = hasConnectedOnce ? 1000 : 30000;
setTimeout(connect, reconnectPauseMs);
}
);
}
But, you'll still have the problem that you must scan before a connect will work on iOS.
Happy for other ideas on how this problem could be mitigated thought.
Hey @peitschie , thanks for your feedback. If I remember it rightly this issue was not given with Version 1.6.3 where I already did the .connect thing and reconnecting when disconnect is triggered, but now with 1.7.0. I'll do tomorrow some more tests.
Any how, the good thing is that the "quickfix" is a timeout added, but I'm very confused, when the .disconnect is triggered and you .connect again, its going into a loop which is triggered in milliseconds
Interesting.
There are no changes between 1.6.3 and 1.7.0 that should impact this, so I don't really have a good explanation for why it worked before but not now. Is this plugin the only thing that's changed recently?
but I'm very confused, when the .disconnect is triggered and you .connect again, its going into a loop which is triggered in milliseconds
The tight loop here is because the peripheral has never been seen by the plugin, so it returns immediately. On iOS, it's impossible to connect without first scanning for the peripheral (unless you have BLUETOOTH_RESTORE_STATE set to true).
I'm closing this issue out as the key issue here is that connect
is always being called within the disconnected callback despite the reported error not being recoverable.
The suggested workaround has been detailed in https://github.com/don/cordova-plugin-ble-central/issues/975#issuecomment-1575773986, but there's no generic fix that seems useful here.
Hey @peitschie,
Sorry for another ticket here!
I've just encountered an issue on iOS:
When I run
.connect
and this triggers the.disconnect
function and I reconnect again, the log goes crazy, and the app reloads.That said, the fix was to add a timeout for 1-2 seconds, before triggering
.connect
again. (.autoConnect cant be used, after all the discussions we had on #963)The log which is thrown on iOS:
and ends with
Maybe! This issue is aswell on Android, but after I do some other magic here, I didn't test it right now tbh.
Hope this information helps you to track down :) Best regards Lars