| Hi!
My experience is that this is a benign error. I suppose you set the reference to the peripheral to null right after you call the cancelPeripheral method. This causes the peripheral to be freed. Which wouldn't be a great issue since it only shows that you don't need the value any more. But since its internal state is still not updated by CB, it thinks the object is being freed by accident.
All in all, either you keep the reference to the peripheral until the didDisconnect arrives, or you will see this message. One can argue for or against it but IMHO this message should not be shown if the peripheral is being disconnected as all the things that happen during that are just "housekeeping". I can decide in the didDisconnect callback whether that info is important or not.
My other issue was the non idempotent behavior of the disconnect method. The peripheral API does not expose whether there is an ongoing connect request, I have to keep this state in my app. If I call the disconnect method while there is no connection request or ongoing connection to the peripheral, then an error is returned. The question is if the "Connecting" state is so important for CB, then why doesn't it expose this info on any of the APIs? This info needs to be maintained by the applications too in order to be able to behave correctly.
Finally, the link to the peripheral is kept alive by iOS for 50 or so seconds. It causes more issues than it cures but we have to live with it.
Regards, Andras Same problem here!I got the following message right after I called cancelPeripheralConnection
CoreBluetooth[WARNING] <CBConcretePeripheral: 0x2002c3b0 UUID = <CFUUID 0x2002cd40> 5D0A4044-955B-C45F-C321-253F715F2D3D, Name = "Smart Finder", IsConnected = YES> is being dealloc'ed while connected
I did get didDisconnectPeripheral event, but the link still connected! Is this problem a bug? Any solution to this?
Thanks! Jeff
|