Apps and Docs in iOS
The Macintosh has always had a notion of documents associated with an application. Double-click a document’s icon in the Finder and the associated application launches and opens that document. This mechanism has had its ups and downs over the years, becoming sometimes more sophisticated, sometimes more crude (see “Snow Leopard Snubs Document Creator Codes,” 6 September 2009). But at least it’s easy and it generally works.
Starting with iOS 3.2, the iPad (and now, with iOS 4.0, the iPhone and iPod touch) has had a mechanism for associating document types with apps. But the two are scarcely comparable: the Macintosh mechanism is like a rocket ship, and the iPhone mechanism is like one of those jalopies that flaps its wings and crashes into a barn in the silent movies.
Under iOS, there is no Finder, and there’s no file system visible to the user (the normal user, at least, who hasn’t jailbroken the device). So it’s up to individual apps that handle documents to offer the user the option of opening a document in some other app. Most iOS apps don’t deal with specific document types, or if they do, they don’t choose to offer this option; so that’s the end of that.
If an app does want to offer the user such an option (as does, for example, Safari or Mail), it calls the system to perform a limited range of actions. The system can present a preview of the document; it can present an Options dialog; or it can present an Open In dialog. These amount to pretty much the same thing, ultimately. For example, the Options dialog is likely to offer one choice of app in which to open the document, along with an option to present the Open In dialog. In the end, therefore, it comes down to the Open In dialog, which is a list of apps that can open the document in question. The user either taps a name in the list or taps Cancel to dismiss the dialog without doing anything.
Note that the app is not presenting the Open In dialog and knows nothing of its contents. The dialog belongs to the system. The app has no way of querying the system to learn what other apps can open a document of a certain type. This would appear to be an instance of the iOS’s “sandboxing” policy: apps run in a strictly delimited space, and are not allowed to tread on, or even know about, one another’s territory.
(As usual, though, Apple’s own apps can be privy to system information that other apps can’t obtain. This must be the case with Mobile Safari, because it doesn’t present the Open In dialog; it uses its own interface, and that wouldn’t be possible if it didn’t have some way to query the system as to what apps can open a given file.)
For the same sandboxing reason, there isn’t any central document repository in which an app can look to find a document. You won’t find an iOS app with a standard Open dialog, because there are no standard Open dialogs in the iOS; there is no built-in provision for perusing the file system as a whole. An app can keep documents within its own sandboxed file system, and can present its own custom interface for perusing that file system; but it can’t see outside its sandbox.
That being so, how can one app open a document that currently lives in another app’s sandbox, in response to the Open In dialog? It’s all up to the system. Just as apps can’t see which other apps can open a document of a certain type, but the system can, so too an app can’t move a document from its own sandbox into another app’s sandbox, but the system can. If, in the system’s Open In dialog, the user elects to open the document with a second app, the system takes charge. It places the document in the second app’s Inbox folder, which is inside the second app’s sandbox. Then it launches or foregrounds the second app and sends it a message asking it to open that document in its new location.
How does the system know which apps can open a certain type of document? That, at least, is similar to Mac OS X. An app’s bundle contains an XML resource called Info.plist, which the system reads to learn various important things about the app, such as where its icon file is and which of its nib files contains its startup interface. The Info.plist can also list document types the app is willing to open; it specifies those types by their uniform type identifier, or UTI. (The UTI is the modern equivalent of the old four-letter creator code and also enables mappings between file extensions and MIME types; for more gory details, see that creator code article cited earlier.)
I’ve omitted two pieces of the puzzle, because they’re not really pieces of this puzzle. First, you’re probably aware that you can copy documents into some apps via the File Sharing interface in iTunes when the iOS device is hooked to your computer. That’s a separate mechanism. It’s a simple on-off switch: either the user can or can’t copy files to and from a certain directory in this app’s sandbox using iTunes.
(To further muddy the issue, iBooks, of course, has a special relationship with iTunes, because it’s Apple’s own app. There’s no accounting for how iBooks acquires files in the iTunes Books category.)
Second, there are also custom URLs. An app can define a URL scheme, such as “myScheme://something/or/other”, and may be contacted when such a URL is tapped in a Web view or otherwise sent to the system. But this has nothing to do with document types. It’s more like a secret code for sending a message, defined by an app and usable only if the user or another app knows the secret. And how an app responds when it receives such a message is entirely up to that app.
To summarize: You can’t arbitrarily pick a document and ask for some app to open it. You can’t even arbitrarily pick a document; you see the Open In dialog only if some app that encounters a document feels like showing it to you. You can’t easily find out what apps are prepared to open a given type of file, for the same reason that an app can’t. There’s no easy way to look inside an app bundle to view its Info.plist, and there’s no system call that an app (other than one of Apple’s own apps) can use to perform such an inquiry. The entire process of getting iOS to work with documents is like trying to tell someone how to knit, while they’re wearing mittens and earmuffs, and you’re blindfolded.
Why not just write an app for your Take Control ebooks? Here's a recent reference from PrMac that might be helpful: "Xcode Projects - Publish a Book on the App Store - Video Demo Released" --
We certainly could in theory, but we don't want to get into the software development business if we can avoid it.
This article hits the nail right on the head - I work in education and want to make iBooks with ePub that I can store on web servers and get users to download from MobilSafari and then open in iBooks. I didn't think it would be harder than adding the MIME type to the server. I got it to work once but not since and this is very frustrating. I think Apple are missing something here as students would use their iDevices and iBooks more if they could easily get lots of content.
Maybe this is all being held back so that Apple can grab the iBooks market more securely and universally with another slightly smaller than iPad device and an integrated bookstore behind it with the new cloud based/ server farm running the show.
Whatever, Apple need to look at iBooks seriously and make it easier to integrate video and get the infrastructure in place.
At the moment iBooks is over looked and forgotten but mybe, again, this is why iBooks was not included as part of the system, so it can grow separately
I don't think there's any way to get an EPUB from the Web into iBooks at this point in time. iBooks simply doesn't register itself as handling the EPUB UTI.
There is - but not ePub though. I just used a PDF linked from a web page on my home mac server and looked at it through WiFi on an iPodTouch. Mobile Safari finds the page, you have a link to the PDF this is opened with an iBooks link button. In iBooks you can click an absolute URL link. I tried an M4V (of Southend United beating Manchester United) and it worked fine. iBooks jumps to the QuickTime helper, it downloads and plays. A user has to go back to iBooks manually but its still open where you left it.
Not the best solution, I agree, but for now, it means you can make interactive PDFs and link to video resources and deliver the whole thing on line.
Also PDF is one of the default types for podcasting/ RSS.
It would be great if Apple could get the ball rolling on this but until then, this will do - also with PDF you can do any layout you like..
Plain and simple. The iPhone and iPad both need a Finder. The Finder can be made safe, or sandboxed by not allowing an app to be launched from it. What I need, particularly on my iPad is a Finder that enables me to open and Save data from multiple different apps - just like on my Mac.
I'm not so sure it needs a Finder, which implies a lot of hierarchical filing in folders and the like, which would be cumbersome in the iOS. But a Documents app that merely lists all the documents on the device, separated perhaps by type (since multiple apps can open documents of the same type) would go a long way toward resolving this. Would it scale sufficiently? That's another question, and it would probably need some serious thought.
The last sentence of the article (about encumbered knitting instructions) reminded me of the marvelous scene in "Murder by Death" with the blind butler (Alec Guinness) giving (spoken) instructions to the deaf hired-for-the-event cook (Nancy Walker) who is "talking" by writing and holding up notes. [Go ahead, watch that with a straight face.] In fact, watch the whole movie.
(About the movie: http://en.wikipedia.org/wiki/Murder_by_Death )