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 <conn@apple.com> 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 <khaos.tian@gmail.com> 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 <conn@apple.com> 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 <kissling@oberon.ch> 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 <khaos.tian@gmail.com> 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 (Bluetooth-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/bluetooth-dev/kissling%40oberon.ch
This email sent to kissling@oberon.ch
_______________________________________________ Do not post admin requests to the list. They will be ignored. Bluetooth-dev mailing list (Bluetooth-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/bluetooth-dev/conn%40apple.com
This email sent to conn@apple.com
_______________________________________________ Do not post admin requests to the list. They will be ignored. Bluetooth-dev mailing list (Bluetooth-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/bluetooth-dev/site_archiver%40lists.... This email sent to site_archiver@lists.apple.com