Thinking about the different app states in relation to background applications and interapplication messaging.
Before IOS 4 this was all irrelevant there was no way to keep the application running in the background, but now if you have an application that use background audio or external appliances an interesting idea comes to mind.
Say you have a hardware jukebox or a radio headunit, and it allowed you to stream audio via ad2p through its speakers and command and control via IAP.
You want to be able to select applications from the jukebox and switch between them. A jukebox that required you to physically launch an application on the phone to connect wouldn't be much fun.
So how might this work.
Lets say you have 3 applications all compatiable with the jukebox.
When you plug the 30 pin cable into the hardware it launches the control center application, or maybe you have to manually launch the app. Now this control center application has command and control and its application selection menu is on the hardware display.
You select one of the 3 apps, lets call it RadioPlay.
The control center launches RadioPlay with an openURL
The control center is now background
RadioPlay opens the session to the accessory, the control center Closes its session, RadioPlay's menu is now on the hardware display.
RadioPlay issues an openURL request bringing control center foreground, but still maintaining the Accessory connection
ControlCenter is foreground, RadioPlay is background and still has command and control
the user issues an exit command to RadioPlay which menu is on the hardware screen , RadioPlay sends a GIP (see our proposed General interapp protocol) message to the control Center which requests The control Center to open an accessory Session.
Because only one accessory session can exist , the session associated with RadioPlay is closed, Control Center now has command and control, and RadioPlay remains in the background until suspended.
The user now can select any other application from the menu.
Comments