Re: Apps that work together – on iPad
Brent Simmons lays out the case for setting up a sort of gentlemen’s agreement between iPhone OS developers, or at least an agreement in behavior for the apps – in order to facilitate inter-app communication. The title of his article refers to iPad, but the concept applies well to all iPhone OS apps, and he asks if his solution is sensible or silly:
But we don’t have an easy way to get back to the calling app. Imagine a hypothetical case like this:
- You’re in Twitterrific, looking at a web page, and there’s a link to a feed. You want to subscribe to that feed.
- So you choose a “Subscribe in NetNewsWire” command. It opens NetNewsWire and subscribes to the feed.
- Now that you’ve done that, you want to get back to your place in Twitterrific. You want it to be exactly as if it never quit.
We can do #1 and #2. It’s #3 that’s tricky.
So I have an idea. It just came to me, so I don’t know if it’s good or bad — but it’s worth posting, at least.
What if the calling app added, as a parameter to the URL, a URL to call when the task is completed?
Seems pretty sensible to me. It would be fantastic for Strip. I’ve been looking for ways to make our password manager more easily accessible from other apps so that it’s easy to take that very round-trip he describes into Strip and back out to another app to either store some data in Strip and go back, or to retrieve some data from Strip to use. It’s pretty easy now, but it could be better, it could just work.
I think Bret’s idea is a really good one, and provides for a lot of flexibility going forward. However, there’s still no way an app could “discover” what other apps are available and what services they provide under this scenario, and that’s really clutch for this sort of thing, for providing a button like “Fire a flame thrower in NetNewsWire” and knowing that it will in fact launch NetNewsWire and run some fictional “Fire a flame thrower” command.
Maybe apps should broadcast their services over Bonjour to the localhost? Right there we already have a very solid model for advertising and discovering “services,” although it doesn’t quite lend itself to application switching. And on iPhone OS 3 and lower, no application that isn’t running could advertise a service in the background.
In iPhone OS 4, that will no longer be the case, it would seem. Perhaps one could just run a bonjour advertisement for a service in the background in an NSOperationQueue? What an awful kludge that would be. I don’t understand why this isn’t a basic feature of iPhone OS 3 already.
Thursday, May 27, 2010
Matt Kanninen says:
Yeah! Some sort of URI pattern! Some sort of…. intent based system~
Thursday, May 27, 2010
Dave says:
Innovate! Innovate like you’ve never innovated before!
And if you’re lucky, you might end up with Android 1.0.
Thursday, May 27, 2010
Tobias Klonk says:
We could use a persisted UIPasteboard with a specified name to share information about available services between applications.
Thursday, May 27, 2010
Billy Gray says:
Tobias – that’s a very clever idea. I like it a lot.
Thursday, May 27, 2010
Marco Arment says:
We can’t lay out capabilities, but if we agreed on some standards and arrange a centralized database, we CAN auto-detect which other supported apps are installed on the device.
All supporting apps register for publicly documented URL schemes, then they use UIApplication’s canOpenURL: to determine whether any other known apps are installed. (This is how I detect installed Twitter and Tumblr apps for Instapaper Pro’s Share popup.)
Granted, it’s not perfect — apps need to be updated whenever a new supported app is available — but it works.
Tuesday, June 01, 2010
Billy Gray says:
> We can’t lay out capabilities, but if we agreed on some standards and arrange a centralized database, we CAN auto-detect which other supported apps are installed on the device.
Sounds good to me!