So now we have a fairly useful multi-application usage scheme. The runner can use her voice to start and swap between applications. She can also connect or disconnect applications to the heart monitor that perform different functions.
But there are definite refinements that can be made surrounding HealthMonitor and HealthShare. Since the monitor accessory only allows a single connection only one of the applications can be getting updates from the monitor. HealthShare in particular would benefit from a persistant connection because as implemented it can only deliver a log of resperatory activity over a particular time slice.
Also any applications which like HealthShare collect statistics from the monitor need to be certified by the MFI program, leaving potential but small independent developers out in the code. It would be far more efficient and benificial if the HealthShare application could just get the pulse updates from HealthMonitor then directly from the accessory, but in a way that did not require changes to the firmware to add newer Apple protocols. It turns out such a mechanism exits and we will examine that now.
This mechanism is the Pasteboard which was introduced by Apple to provide cut and paste between and within applications. The Pasteboard is often thought to be like simple clipboard but this is not an entirely true anology.
There are two types of pasteboards that an application can interact with. The first is the general, systemwide pasteboard. This pasteboard can be accessed by all applications on the system and is the default pasteboard that is used by UITextView, UITextField, and so on.
The second type is a named pasteboard. These pasteboards are created by your application and given a name. Other applications that know the name of your pasteboard can also access that pasteboard and retrieve your data. In this way, you can share data amongst a select set of applications if you need to. Local notifications can be set up between applications. System pasteboards are persistent by default named pasteboards can be made persistent by setting the persistence property.
The UIPasteboard class provides the mechanism by which applications interact at a low level with both the general system pasteboard and specific named pasteboards that they themselves create.
To access the general system pasteboard, you call the method generalPasteboard on the UIPasteboard class. This returns the general pasteboard singleton.
To access a named pasteboard, you call the method pasteboardWithName:create: on the UIPasteboard class. If you would like the UIPasteboard class to create a unique name for you, then you can pass nil as the first parameter. The second parameter indicates whether or not you want the UIPasteboard class to create the pasteboard for you if it does not exist.
You can get a reference to the pasteboard as follows:
UIPasteboard *pasteboard = [UIPasteboard generalPasteboard];
You can then place a string on the pasteboard by using this:
pasteboard.string = @"here is some data";
After launching your app via a call to openURL:, you can then retrieve the string from the pasteboard by writing this:
UIPasteboard *pasteboard = [UIPasteboard generalPasteboard];
NSString *myString = pasteboard.string;
The UIPasteboard class contains convenience properties like this for NSString, UIImage, NSURL, andUIColor.
Pasteboards are implemented as an array of items. Each item may have multiple representations, and is represented by a dictionary. For instance, a URL can have a number of representations:
- A text representation (kUTTypeUTF8PlainText) for text editors
- A URL representation (kUTTypeURL) for tools that accept URLs
- An image representation (kUTTypePNG or kUTTypeJPEG) for tools that accept images
To retrieve a pasteboard’s items, invoke items. To add an item, create the appropriate dictionary and add it to the pasteboard with addItems:.
NSDictionary* item
= [NSDictionary dictionaryWithObjectsAndKeys: string, kUTTypeUTF8PlainText,
url, kUTTypeURL,
png, kUTTypePNG, nil];
[pasteboard addItems:[NSArray
arrayWithObject:item]];
Standard UTI types are used to access each item but you can also define custom keys if needed.
Due to a limitation of the iPhoneOS, the size of each item on the pasteboard cannot exceed 5~8 MB. If an item is greater than 5120 kb it should be broken into smaller items of less than 5120 kb.
Using Pasteboards it is not hard to imagine that you could come up with a protocol for sharing information between applications. A company called INTUA markets an application named BeatMaker that uses such a custom sharing protocol to share audio data between BeatMaker compatible applications. They have opened source the protocol under MIT license.
BeatMaker uses this UTI to achieve copy and paste operations of uncompressed audio data with other applications.
Items with type kUTTypeAudio contains audio data in a specific sample format.
BeatMaker assembles all contiguous items of type kUTTypeAudio, into one audio file.
Each item is added to the pasteboard and made available to other applications.
INTUA audioCopy only works for pcm audio but its not much of a stretch to devise a general protocol for interapplication sharing. Mooncatventures is in the process of developing such a General Interapp Protocol (GIP) and we will provide more details soon.
Comments