使用 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 通知.有了这个，我假设 Session 和 Accessory 结构(可能还有流)将在后台继续存在?
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 在后台拆除的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持跟版网！