In this continuation of the last post "playing with app states" we are going to look at two hypothetical case studies.
Case Study I Hardware jukebox
Whether the jukebox is meant for a motor vehicle or the dressing table is irrelevant. The design is a simple display of some kind and a voice interface. All command and control is via the accessory, once the IPhone or IPod touch is placed in the dock it can be ignored.
We will assume we have two applications, RadioPlay which we mentioned before, a simple radio streamer and InfoPlay which provides, news, weather and alerts . How the apps are voice enabled again is irrelevant, will just assume they are using one of the several api libraries available .
The user puts the IPhone into the dock connector, and the default application launches. This might be automatically or require clicking an "open Application" popup depending on the implementation level of the accessory. In either case the Jukebox application is now foreground and RadioPlay and infoPlay are available on the menu. Perhaps these applications are part of a suite of apps that can be purchased and downloaded. Newly downloaded applications would get added to the menu on next app start.
The JukeBox is the only application that has a connection to the accessory. The Jukebox was developed by the company that developed the certified MFI device. The developers of RadioPlay and InfoPlay are irrelevant.
The user issues a voice command to start RadioPlay .
- RadioPlay launches, Jukebox goes to background stays connected to accessory
- RadioPlay stays foreground
- RadioPlay connects to the JukeBox via a GIP protocol, all command requests as well as binary data is "relayed" via gip to the jukebox which sends it to the accessory.
- The user issues a command to start InfoPlay, RadioPlay goes background but is not suspended because it has the "app plays audio" key for background mode.
- InfoPlay is now foreground and relays the temperature through GIP to the Jukebox displaying it on the Hardware LCD.
Case Study II return to the Pulse monitor
This is the pulse monitor wrist band we discussed earlier. It is an ANT device controlled via a bluetooth headset.
In this implementation only a single application HealthMonitor directly receives updates from the accessory. Since it is attached to the accessory it can run backgrounded.
HealthShare is a third party application, it provides a snapshot of pulse activity over some time slice as a histogram which can be posted to the user's Facebook wall. HealthShare does not need to be aware of the physical connection to the accessory or even the fact one exists. The implementation is totally hidden. It just needs one piece of data, the pulse update that it gets via a GIP connection to HealthMonitor.
Analyzing both use cases above we can draw some conclusions.
- Only one connection to the accessory is required, the actual MFI covered implementation is hidden yet at least in the first Use Case the radioPlay is delegated full command and control over the accessory. this would seem to circumvent MFI and may not go over to well with the Apple Reviewers and could be construed as a violation of contract, However in reality we think for a third party company to pull together such a tight integration would require the close ties with the company that built the accessory and most likely covered under the NDA anyway.
- The relay stream between the application connected to the accessory and the infoPlay application allows the Jukebox application to interlace its own data into the stream , e.g., ads from the internet, traffic alerts , system health , etc.
- Finally in the last Use case we have set up a scenario that JUST MAY be acceptable to the Apple reviewers to allow non MFI third party freelance developers access to existing accessories. The Accessory implementation is totally hidden, and the app requires a single piece of data coming only very indirectly from the accessory.
Comments