Clearly having a central Controller or Navigator application is an efficient approach, if it uses a GIP protocol it can be a central single connection to the hardware accessory , even if it doesn't it can provide the central menu structure for starting applications.
Also as previous mentioned this Control Center which presumably would be provided by the Accessory provider could also having the ability to intermix its own alternative content e.g. web content, into the streams coming from the the accessories to the third party applications.
Thus channel guides or service information could be provided and not have to be re-duplicated among partner apps.
But also as mentioned someone , presumably the OEM that created the accessory must take ownership and distribution of the Control Center application.
One more scenario is worth looking at. Side loading of the applications.
As an example of what we are refering to as "side loading", if you have two apps A and B , both able to connect to the accessory, A knows about B and B knows about A , and either can start the other.
We can presume that the GIP protocol is already embedded in a staticlib distrubuted by the MFI OEM, perhaps at least a part of the menu system we discussed could also be embedded. A means to determine other apps that may be loaded either by interating though the url schemes installed or the processs list can be provided, and would create a menu that can be added alonglides the 3rd party app menu on the hardware device.
Thus, when the User Exits App "A" , it doesn't actually close any connections, it simply shows the "application menu" from which the user can select Application "B" to start, once application "B" starts it takes over foreground and opens an accessory session causing App "A" to lose its connection.
Comments