EAAccessory/EASession 在后台拆卸 [英] EAAccessory/EASession teardown during background

问题描述

使用 Apple 的 EADemo 作为基础，我试图了解背景对 EAAccessories 的影响.

Using Apple's EADemo as a base I'm trying to understand backgrounding's influence on EAAccessories.

当我收到 connectNotification 时，我会获取附件、检查协议并获取流.使用流我设置委托，安排在 RunLoop 上，然后打开

When I receive a connectNotification, I get the accessory, check the protocol and get the streams. With the streams I set the delegate, schedule on the RunLoop, and open

目前，当我进入后台时，我会将其全部撕掉.我收回我所做的一切并释放所有对象.

Currently when I go into the background I tear this all down. I back out everything I did and release all objects.

我也在 didDisconnect 上进行了拆解.

I also do this teardown on a didDisconnect.

进入时，我并不总是得到一个 didConnect，所以我遍历了 connectedAccessory 列表并检查了合适的设备.

Upon entry, I don't always get a didConnect so I walk the connectedAccessory list and check for appropriate devices.

-=-=-=-

EA 演示在视图上设置和拆除会话，因此我们看不到是否存在后台持久性.

The EA Demo sets up and tears down sessions on a view so we don't see whether there is background persistence.

EA Demo 代码似乎表明只要设备本身没有断开连接，您就可以拆除并返回.

The EA Demo code seems to suggest you can tear down and go back in as long as the device itself hasn't disconnected.

然而，当 iOS 设备进入睡眠状态或将应用程序置于后台时，会话和设备有时似乎进入一种状态，并且设备将停止确认数据或更糟的是将停止从流中提取数据到小溪填满了.

The session and the device however sometimes seem to get into a state when the iOS device has slept or put the app into the background and the device will stop acknowledging data or worse will stop pulling data out of the stream to the point that the stream fills up.

问题:在使用后台时，我是否应该不拆除活动的会话/附件，除非我确实收到了 didDisconnect 通知.有了这个，我假设会话和附件结构(可能还有流)将在后台存活?

Question: When using backgrounding, should I not tear down a session/accessory that is active unless I actually get a didDisconnect notification. With this I assume that the Session and Accessory structures (and maybe the streams) will survive in the background?

推荐答案

我对 External Accessory 框架的体验是它最初的设计很差，就健壮性而言.在 iOS 4.0 之前，尝试连接到多个配件会产生此错误消息:

My experience with the External Accessory framework is that it was poorly designed initially, in terms of robustness. Until iOS 4.0, trying to connect to multiple accessories would yield this error message:

Cannot use accessory. Only one accessory can be in use at a time.

现在似乎并没有太多关注应用进入后台时配件会发生什么.我确信正确的行为是在附件断开连接时释放 EASession 实例.但我不认为进入后台的应用程序有资格作为附件断开连接.如果您记录附件的 connectedID 的值，则没有什么可做的，您会注意到它们不会仅仅因为切换到后台并返回到前台而改变.我怀疑连接的 EAAccessory 实例列表不会刷新，除非 EAAccessoryManager 收到附件更改(连接/断开连接)的通知.

Now it seems that there has not been much attention to what happens to accessories when apps go into the background. I have been assured that the correct behavior is for EASession instances to be released on accessory disconnect. But I don't think that an app going into the background qualifies as an accessory being disconnected. There isn't much to go by if you log the value of the connectedID for your accessories, you will notice that they do not change just for having switched to background and back to foreground. I suspect that the list of connected EAAccessory instances is not refreshed unless EAAccessoryManager is notified of a change (connect/disconnect) of an accessory.

我一直在尝试拆除并重新创建 EASession 实例，但失败了.我现在将尝试在整个背景/前景过渡期间将 EASession 留在原位.我担心的一个问题是我的应用程序在后台不会收到 EAAccessoryDidDisconnectNotification 和 EAAccessoryDidConnectNotification 通知.

I have been trying to teardown and recreate EASession instances and this has failed. I am now going to try leaving the EASession in place throughout the background/foreground transition. My one concern is that my app won't be receiving EAAccessoryDidDisconnectNotification and EAAccessoryDidConnectNotification notifications while in background.

这篇关于EAAccessory/EASession 在后台拆卸的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！