Open snaptom opened 8 years ago
I've seen that message in previous versions and haven't ran into any approval issues with it in the past.
I'm having this error too and I think it's stopping a callback somewhere from bubbling, as I'm left hanging waiting for a response in my code. It's slightly different mind you:
API MISUSE: Cancelling connection of unused peripheral,
@unclespode Do you know how to reproduce it? Some Javascript calls may be out of order, or called one too many times.
I do seem to be able to reproduce it, but I don't feel I'm doing anything wrong - it's all working fine on Android.
The issue (as far as I'm concerned) is not that these errors are happening - but that they aren't being caught / handled. For example, I have one where it gives a reason and then explains it's cancelling the connection request. However, I don't get any callback whatsoever, so my code just hangs waiting for something to happen.
At least with me, it occurred only on IOS when you try to connect to a peripheral that hasn't been discovered by your "didDiscoverPeripheral" yet.
In my case, I was storing my device's identifier and trying to connect to the peripheral without scanning for it. Always when I did that I was getting this error.
How did you know the device's UUID without scanning it? I thought those UUIDs were unique per iOS device for privacy reasons.
Hey @randdusing ,
Yeah, I think the UUID is unique per device but the first time when we were opening the app we did the scan. If we find the device we were looking for we connect to the device and store its UUID on the database. Then the next times we wanted to connect to the same device we were using connect straight without calling scan first. It works well until we kill and open the app again. When we did that IOS raised this error saying we didn't have a strong reference to the peripheral and we couldn't connect to it even the peripheral being valid.
The solution, for us, was always when we open the app, for IOS, we have to clear the UUID stored on the database forcing it to scan again instead of connecting straight.
I fixed all the API misuse errors by adjusting the code myself. I'll try and hunt out my changes - but ultimately the main one, was an additional cache to stop iOS releasing the reference.
For me, this error shows up in the XCode logs at every start of the app, unless I add restoreKey to the initialization parameters of the initialize call.
Hello and thanks for the excellent work on this plugin.
I just wanted to flag up a message I have started seeing since updating to iOS 10.
When I start using the plugin, using iOS 10.0.2 I receive the following message:
Are you aware of this? I just wanted to understand the potential impact of this from an app store approval point of view?
Many thanks, Tom.