Re: About CoreBluetooth disconnect behavior
Re: About CoreBluetooth disconnect behavior
- Subject: Re: About CoreBluetooth disconnect behavior
- From: Etan Kissling <email@hidden>
- Date: Tue, 29 Jan 2013 19:15:19 +0000
- Thread-topic: About CoreBluetooth disconnect behavior
Jason,
imagine an iPhone X with central-based apps A, B and C, and an iPhone Y with peripheral-based app P.
All three apps on iPhone X are connected with app P.
Am I correct in the assumption that P cannot distinguish the three apps on iPhone X,
and that only iPhone X can evaluate which data packets from P are to forward to which A, B or C?
This would explain why a peripheral cannot terminate a link (as it cannot know with how many apps it is
talking), and also, why it is not possible to receive reliable connected/disconnected events on the peripheral.
It would still be beneficial to have a way to leave peripheral mode altogether, disconnecting all centrals in
the process. Or at least getting a callback on the first received connection and on the last ended connection.
Depending on the use case, it may make sense to only perform computationally expensive tasks while a
central is connected.
Etan
On 29.01.2013, at 18:55, Jason Conn <email@hidden>
wrote:
>> If my case use two iDevices, one in central and one as peripheral, how can I make sure the connection disconnected immediately?
>
> You can't guarantee that, and shouldn't rely on it. By it's nature, the multi-process architecture of iOS means that there may be another application running who still wants that connection up, even if you don't.
>
> On Jan 29, 2013, at 9:49 AM, Khaos Tian <email@hidden> wrote:
>
>> Thanks for your remind :)
>>
>> So you suggest that the most reliable way to cause a physical disconnection immediately is to initiate it from the peripheral side. If my case use two iDevices, one in central and one as peripheral, how can I make sure the connection disconnected immediately? As what I knew there isn't possible to initiate cancel connection on CBPeripheralManager side.
>>
>> Best Wishes,
>> Khaos Tian
>>
>> On Jan 30, 2013, at 1:35 AM, Jason Conn <email@hidden> wrote:
>>
>>> This was very much an intentional change, but one that comes with an arguably subtle caveat. As explained in the updated headerdoc:
>>>
>>> /*!
>>> * @method cancelPeripheralConnection:
>>> *
>>> * @param peripheral A <code>CBPeripheral</code>.
>>> *
>>> * @discussion Cancels an active or pending connection to <i>peripheral</i>. This command is non-blocking, and any <code>CBPeripheral</code>
>>> * commands that are still pending to <i>peripheral</i> may or may not complete.
>>> * It extremely important to note that canceling a connection does not guarantee the immediate disconnection of the underlying physical
>>> * link. This can be caused by a variety of different factors, including other application(s) that hold an outstanding connection to the
>>> * peripheral. However, in this situation, you will still receive an immediate call to @link centralManager:didDisconnectPeripheral:error: @/link.
>>> *
>>> * @see centralManager:didDisconnectPeripheral:error:
>>> *
>>> */
>>>
>>> Thus, if your use-case requires a physical disconnection of the peripheral, the only way to guarantee that happening in a timely fashion is to initiate it from the peripheral.
>>>
>>> On Jan 29, 2013, at 2:42 AM, Etan Kissling <email@hidden> wrote:
>>>
>>>> Khaos,
>>>>
>>>> I can confirm disconnect delays of about 1-3s under the final iOS 6.1 version.
>>>> Seems that it is intended and we can remove "remote disconnect" workarounds.
>>>>
>>>> Etan
>>>>
>>>> On 29.12.2012, at 14:25, Khaos Tian <email@hidden> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> On iOS 6.1 beta 4 I noticed that after I called
>>>>> cancelPeripheralConnection: the connection between iDevice and
>>>>> peripheral closed in about 1~2s.
>>>>>
>>>>> Is that Apple finally decided to remove the 30s disconnect delay in iOS 6.1?
>>>>>
>>>>> Best Wishes,
>>>>> Khaos Tian
>>>>> _______________________________________________
>>>>> 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
>>>
>>
>
_______________________________________________
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