So now we come to the end of this series, the final cut if you will ,we hoped you found it both educational and enjoyable.
So looking again at our Marathon runner traniee. She has the pulse rate monitor band wrapped around her left wrist, and the jambra headset behind her right ear. The heart monitor "talks" to the applications on her phone using the same ANT+ protocol used by the resident Nike application. The headset allows her to control a springboard application on her iphone using Siri (or perhaps Nuance) over the new WB band 16 khz SCO channel.
As Before she has several audio applications including her favorite Radio application. The device also has the HealthMonitor application and a hypothetical version of HealthShare using a GIP protocol.
As Before she starts HealthMonitor with a voice command, HealthMonitor connects to the accessory then does an openURL transfer back to the launcher.
She now starts Pandora which becomes the forground application. When she is done with Pandora she exits and returns to the launcher.
She now issues the voice command to start HealthShare which sends the launcher to the background.
HealthMonitor continues to send updates from the background, whenever it has an update for HealthShare it retrieves HealthShares "SharedMessageQueue" (a uipasteboard) and encodes the update as a GIP message. Messages greater then 2048 bytes are broken into smaller messages, each message contains a protocol frame header. Multiple messages are in the form of a circular linked-list and have a message id to indicate the message the frame belongs too. Again each frame is no more than 2048 bytes.
After adding the message to the sharedMessageQueue HealthMonitor sends a notification to HealthShare that it has an update. Remember this protocol is in early development, perhaps it may be better from a message traffic prospective if the HealthShare just had a background task that watched the Uipasteboard named sharedMessageQueue every 100 ms or so. In any case, HealthShare gets the update and sends it to facebook. It may also update the runners location to facebook checkin.
The one drawback here is that when the runner swaps HealthShare for another application, HealthShare will become suspended, A workaround may be to have healthShare receive periodic location changes which allows it to join the list of Blessed background applications.
So ends our saga, this seem to be a fairly nice mechanism for interapp communication. Undoubtedly there are holes that may be need to be filled, but all in all theoretically it should work.
The technique is also quite cross-platform compatible and may be duplicated on android using Intents.
Comments