Re: cancelPeripheralConnection misbehavior?
Re: cancelPeripheralConnection misbehavior?
- Subject: Re: cancelPeripheralConnection misbehavior?
- From: Andras Kovi <email@hidden>
- Date: Sat, 03 Nov 2012 21:11:56 +0100
Hi Etan,
yes, I know, this is the ordinary way of handling things.
I understand that the client app should hold the reference as long as it may encounter it. But the framework helps itself and calls the didDisconnect with the correct peripheral, it is just creates a new object for it.
I know this is not going to change any time soon, it's just annoying to deal with. Additionally, I have not seen it documented anywhere.
A bigger problem is that the didDisconnect is not called every time the cancel is called. It depends on whether there is a connection pending for the peripheral (connecting/disconnecting), and this state is not visible in the CBPeripheral structure. So, this is another state the app has to take care of while the framework handles it as well. I feel this could be simplified by exposing this "connectionPending" property together with the isConnected.
Thanks,
Andras
On 2012.11.03., at 20:38, Etan Kissling <email@hidden> wrote:
> Try setting the peripheral reference to nil after receiving the diddisconnect callback instead of when you cancel connection.
>
> On 03.11.2012, at 15:15, "Andras Kovi" <email@hidden> wrote:
>
>> I observed that after I cancel a peripheral connection and set the peripheral reference to nil, the peripheral object is collected by ARC and a warning is shown that the peripheral was still in use (disconnecting if it was connected earlier).
>>
>> So I have two questions:
>> 1. Can I turn this warning off? If I cancel a peripheral connection, I don't care what happens to the peripheral object later.
>>
>> 2. If I have to be aware of the connecting and disconnecting states, then why isn't there a flag on CBPeripheral that shows it? Every application will have to reimplement this anyway.
>>
>> Thanks,
>> Andras
>>
>>
>> _______________________________________________
>> Do not post admin requests to the list. They will be ignored.
>> Bluetooth-dev mailing list (email@hidden)
>> Help/Unsubscribe/Update your Subscription:
>>
>> This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Bluetooth-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden