The Core iOS Developer’s Cookbook, Fifth Edition (2014)

Chapter 11. Documents and Data Sharing

Under iOS, applications can share information and data as well as move control from one application to another, using a variety of system features. Each application has access to a common system pasteboard that enables copying and pasting across apps. The apps can request a number of system-supplied “actions” to apply to a document, such as printing, tweeting, or posting to Facebook. Apps can declare custom URL schemes that can be embedded in text and web pages. This chapter introduces the ways you can integrate documents and data sharing between applications. You’ll see how to add these features to your applications and use them smartly to make your app a cooperative citizen of the iOS ecosystem.

Recipe: Working with Uniform Type Identifiers

Uniform Type Identifiers (UTIs) represent a central component of iOS information sharing. You can think of them as the next generation of MIME types. UTIs are strings that identify resource types such as images and text. UTIs specify what kind of information is being used for common data objects. They do this without relying on older indicators, such as file extensions, MIME types, or file-type metadata such as OSTypes. UTIs replace these items with a newer and more flexible technology.

UTIs use a reverse-domain-style naming convention. Common Apple-derived identifiers look like this: public.html and public.jpeg. These refer, respectively, to HTML source text and JPEG images, which are both specialized types of information.

Inheritance plays an important role with UTIs. UTIs use an OO-like system of inheritance, where child UTIs have an “is-a” relationship to parents. Children inherit all attributes of their parents but add further specificity of the kind of data they represent. That’s because each UTI can assume a more general or more specific role, as needed. Take the JPEG UTI, for example. A JPEG image (public.jpeg) is an image (public.image), which is in turn a kind of data (public.data), which is a kind of user-viewable (or listenable) content (public.content), which is a kind of item (public.item), the generic base type for UTIs. This hierarchy is called conformance, where child UTIs conform to parent UTIs. For example, the more specific jpeg UTI conforms to the more general image or data UTI.

Figure 11-1 shows part of Apple’s basic conformance tree. Any item lower down on the tree must conform to all of its parent data attributes. Declaring a parent UTI implies that you support all of its children. So, an application that can open public.data must service text, movies, image files, and more.

Figure 11-1 Apple’s public UTI conformance tree.

UTIs enable multiple inheritance. An item can conform to more than one UTI parent. So, you might imagine a data type that offers both text and image containers, which declares conformance to both.

There is no central registry for UTI items, although each UTI should adhere to conventions. The public domain is reserved for iOS-specific types, common to most applications. Apple has generated a complete family hierarchy of public items. Add any third-party company-specific names by using standard reverse domain naming (for example, com.sadun.myCustomType and com.apple.quicktime-movie).

Determining UTIs from File Extensions

The Mobile Core Services module offers utilities that enable you to retrieve UTI information based on file extensions. Be sure to import the module when using these C-based functions. The following function returns a preferred UTI when passed a path extension string. The preferred identifier is a single UTI string:

@import MobileCoreServices;

NSString *preferredUTIForExtension(NSString *ext)
{
// Request the UTI for the file extension
NSString *theUTI = (__bridge_transfer NSString *)
UTTypeCreatePreferredIdentifierForTag(
kUTTagClassFilenameExtension,
(__bridge CFStringRef) ext, NULL);
return theUTI;
}

You can pass a MIME type instead of a file extension to UTTypeCreatePreferredIdentifier-ForTag() by using kUTTagClassMIMEType as the first argument. This function returns a preferred UTI for a given MIME type:

NSString *preferredUTIForMIMEType(NSString *mime)
{
// Request the UTI for the MIME type
NSString *theUTI = (__bridge_transfer NSString *)
UTTypeCreatePreferredIdentifierForTag(
kUTTagClassMIMEType,
(__bridge CFStringRef) mime, NULL);
return theUTI;
}

Together these functions enable you to move from file extensions and MIME types to the UTI types used for modern file access.

Moving from UTI to Extension or MIME Type

To go the other way, producing a preferred extension or MIME types from a UTI, use UTTypeCopyPreferredTagWithClass(). The following functions return jpeg and image/jpeg, respectively, when passed public.jpeg:

NSString *extensionForUTI(NSString *aUTI)
{
CFStringRef theUTI = (__bridge CFStringRef) aUTI;
CFStringRef results =
UTTypeCopyPreferredTagWithClass(
theUTI, kUTTagClassFilenameExtension);
return (__bridge_transfer NSString *)results;
}

NSString *mimeTypeForUTI(NSString *aUTI)
{
CFStringRef theUTI = (__bridge CFStringRef) aUTI;
CFStringRef results =
UTTypeCopyPreferredTagWithClass(
theUTI, kUTTagClassMIMEType);
return (__bridge_transfer NSString *)results;
}

You must work at the leaf level with these functions—at the level that declares the type extensions directly. You cannot reference the parent types. Extensions are declared in property lists, where features like file extensions and default icons are described. So, for example, passingpublic.text or public.movie to the extension function returns nil, whereas public.plain-text and public.mpeg return extensions of txt and mpg, respectively.

The former items live too high up the conformance tree, providing an abstract type rather than a specific implementation. There’s no current API function to look down to find items that descend from a given class that are currently defined for the application. You may want to file an enhancement request at bugreport.apple.com. Surely, all the extensions and MIME types are registered somewhere (otherwise, how would the UTTypeCopyPreferredTagWithClass() lookup work in the first place?), so the ability to map extensions to more general UTIs should be possible.

MIME Helper

Although the extension-to-UTI service is exhaustive, returning UTIs for nearly any extension you throw at it, the UTI-to-MIME results are scattershot. You can usually generate a proper MIME representation for any common item; less common ones are rare.

The following lines show an assortment of extensions, their UTIs (retrieved via preferredUTIForExtension()), and the MIME types generated from each UTI (via mimeTypeForUTI()):

xlv: dyn.age81u5d0 / (null)
xlw: com.microsoft.excel.xlw / application/vnd.ms-excel
xm: dyn.age81u5k / (null)
xml: public.xml / application/xml
z: public.z-archive / application/x-compress
zip: public.zip-archive / application/zip
zoo: dyn.age81y55t / (null)
zsh: public.zsh-script / (null)

As you can see, there are quite a number of blanks. These functions return nil when they cannot find a match. To address this problem, the sample code for this recipe includes an extra MIMEHelper class. It defines one function, which returns a MIME type for a supplied extension:

NSString *mimeForExtension(NSString *extension);

Its extensions and MIME types are sourced from the Apache Software Foundation, which has placed its list in the public domain. Out of the 450 extensions in the sample code for this recipe, iOS returned all 450 UTIs but only 89 MIME types. The Apache list ups this number to 230 recognizable MIME types.

Testing Conformance

You test conformance using the UTTypeConformsTo() function. This function takes two arguments: a source UTI and a UTI to compare to. It returns true if the first UTI conforms to the second. Use this to test whether a more specific item conforms to a more general one. Test equality using UTTypeEqual(). Here’s an example of how you might use conformance testing to determine whether a file path likely points to an image resource:

BOOL pathPointsToLikelyUTIMatch(NSString *path, CFStringRef theUTI)
{
NSString *extension = [path pathExtension];
NSString *preferredUTI = preferredUTIForExtension(extension);
return (UTTypeConformsTo(
(__bridge CFStringRef) preferredUTI, theUTI));
}

BOOL pathPointsToLikelyImage(NSString *path)
{
return pathPointsToLikelyUTIMatch(path, CFSTR("public.image"));
}

BOOL pathPointsToLikelyAudio(NSString *path)
{
return pathPointsToLikelyUTIMatch(path, CFSTR("public.audio"));
}

Retrieving Conformance Lists

UTTypeCopyDeclaration() offers the most general (and most useful) of all UTI functions in the iOS API. It returns a dictionary that includes the following keys:

kUTTypeIdentifierKey—The UTI name, which you passed to the function (for example, public.mpeg)

kUTTypeConformsToKey—Any parents that the type conforms to (for example, public.mpeg conforms to public.movie)

kUTTypeDescriptionKey—A real-world description of the type in question, if one exists (for example, “MPEG movie”)

kUTTypeTagSpecificationKey—A dictionary of equivalent OSTypes (for example, MPG and MPEG), file extensions (mpg, mpeg, mpe, m75, and m15), and MIME types (video/mpeg, video/mpg, video/x-mpeg, and video/x-mpg) for the given UTI

In addition to these common items, you encounter more keys that specify imported and exported UTI declarations (kUTImportedTypeDeclarationsKey and kUTExportedType-DeclarationsKey), icon resources to associate with the UTI (kUTTypeIconFileKey), a URL that points to a page describing the type (kUTTypeReferenceURLKey), and a version key that offers a version string for the UTI (kUTTypeVersionKey).

Use the returned dictionary to ascend through the conformance tree to build an array that represents all the items that a given UTI conforms to. For example, the public.mpeg type conforms to public.movie, public.audiovisual-content, public.data, public.item, and public.content. These items are returned as an array from the conformanceArray function in Recipe 11-1.

Recipe 11-1 Testing Conformance