8

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

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.

I also do this teardown on a didDisconnect.

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

-=-=-=-

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

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

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.

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?

Dru Freeman
  • 1,766
  • 3
  • 19
  • 41

1 Answers1

3

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.

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.

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.

westsider
  • 4,967
  • 5
  • 36
  • 51
  • 2
    My understanding is that Did[Disc|C]onnectNotifications are cached by the parent wrapper process that controls the backgrounding. We've entirely stopped querying the EAAccMgr list because it tends to get out of sync. We rely entirely on the notifications. – Dru Freeman Dec 16 '10 at 05:11
  • 2
    I get a EAAccessoryDidDisconnectNotification immediately after the app enters background. – iter Aug 19 '11 at 09:23