title: EAAccessory/EASession teardown during background
body: <p>Using Apple's EADemo as a base I'm trying to understand backgrounding's influence on EAAccessories.</p>
  
  <p>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</p>
  
  <p>Currently when I go into the background I tear this all down. I back out everything I did and release all objects.</p>
  
  <p>I also do this teardown on a didDisconnect.</p>
  
  <p>Upon entry,  I don't always get a didConnect so I walk the connectedAccessory list and check for appropriate devices.</p>
  
  <p>-=-=-=-</p>
  
  <p>The EA Demo sets up and tears down sessions on a view so we don't see whether there is background persistence.</p>
  
  <p>The EA Demo code seems to suggest you can tear down and go back in as long as the device itself hasn't disconnected.</p>
  
  <p>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.</p>
  
  <hr>
  
  <p>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?</p>