May 2010

More on Apps that work together – on iPad

Bill Gray: “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...”

Excellent point. It can be done without, but so much better if we had that.

Universal Back Button app

Daniel Stødle: “The idea is to provide a back button that takes you back to the task you were working on, before you opened a file, clicked a link, or similar.”

Clever and interesting. I bet I never would have thought to use the Apple events debug option to make this work. Cool.

Re: Apps that work together — on iPad

Rainer Brockerhoff: Re: Apps that work together — on iPad: “I was thinking about the same issue, coincidentally, and one idea which occurred to me is to use the equivalent of the http referrer URL.”

Universal back button?

On ollicle.com appears an extension to my idea about URL schemes on iPad: a universal back button on Macs. Very interesting. I like it.

Shared code management

We have five Cocoa apps at NewsGator: TapLynx, Social Sites, and three versions of NetNewsWire. They share code.

(You may not have heard of Social Sites. Written by Nick Harris, it’s an iPhone client for our Social Sites enterprise social networking app.)

We’ve just been doing the copy-files thing. Not good. So below I present an (ever-so-slightly edited: took out two words) internal email I just sent about managing the shared code. This is as a sanity check: I think, given our tools, this is the best way to manage this stuff, but I wouldn’t mind hearing that there are other, better ways.

The email: “Shared Code Plan”

Here’s the issue: we have a bunch of code that’s shared between two or more apps. We don’t have a way of managing this right now other than just copying files — which is inconvenient at best, and leads to files being not-quite-the-same in different places as bugs are fixed and features added.

Here’s the solution I’m thinking of. If any of this sounds like the wrong way to go, let me know.

  • Code shared between two or more apps will all live together in an RSCore repository. (If Apple can keep using NS, we can use RS. I just find the initials more poetic than NG, and that actually, bizarrely, matters to me.) This way the shared code will all be the same for each app.

  • Existing and new projects will include the RSCore repository as a Mercurial sub-repository (a sub-folder in the project folder).

  • The RSCore repository will have Foundation and UIKit sub-sections. (This way NetNewsWire/Mac can still use the Foundation stuff.)

  • A given project will include just what RSCore files it needs. It won’t be presented as a static library, since that makes debugging a pain, and leads to including unnecessary code.

  • However, RSCore will have a unit tests project, so we can verify code changes before committing, so we can avoid breaking all our apps at once.

  • Category methods on Foundation and UIKit will begin with an rs_ prefix, to avoid namespace collisions.

  • New classes in RSCore will be prefixed with RS.

  • We’ll be conservative about what we add. Only things that are for sure used in more than one app will go in there.

The idea is not to make additional work, but to make less work in the future, to make all this manageable, to increase productivity.

Make sense? Not make sense?

Apps that work together — on iPad

On Macs we have a long-standing culture of apps working together. I can think of a few examples from my own Mac app: you can send a podcast to iTunes, send an article to Twitterrific to tweet it, or send an article to MarsEdit to post it to your weblog.

Of course, on a Mac, the calling app doesn’t quit when you do these things. It stays open. You can get right back to it. (In some cases, the calling app stays in front the whole time, like when sending a podcast from NetNewsWire to iTunes.)

On the iPad (and iPhone) we can sort-of do the same thing. We don’t have AppleScript or Apple events, but we do have the URL scheme thing for inter-application communication. It’s technically possible to do some of these same things.

But we don’t have an easy way to get back to the calling app. Imagine a hypothetical case like this:

  1. You’re in Twitterrific, looking at a web page, and there’s a link to a feed. You want to subscribe to that feed.

  2. So you choose a “Subscribe in NetNewsWire” command. It opens NetNewsWire and subscribes to the feed.

  3. 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?

This way the helper app (NetNewsWire in this case) would know, once the task is complete, how to get the user back to their place in the calling app (Twitterrific in this case).

The helper app wouldn’t even have to know anything about the calling app — it’s opening the URL that it was handed. (Maybe there’d be a spot for a success/fail return code of some kind too, but that’s a small side issue.)

Sensible? Silly?

Adam Curry on creating the Big App Show

curry.com: “If my intuition is right, I think we might even see app programmers become the heroes of a generation, where fans can’t wait for the release of the next magical app their idol has become famous for.”

Sounds like the end of C4

Wolf: “Software engineering is advancing, albeit at a glacial pace. I spend most of my days writing in languages and using tools that were obsolete over a decade ago.”

Wolf talks about the lack of outcry over section 3.3.1. I’ve not cried out. I’ve been apathetic about it.

Well, maybe not totally apathetic — mostly I was glad because I don’t like Flash. I don’t like Flash because I’ve wasted too much time over the years dealing with Flash crashes.

But mainly I’ve been apathetic. Even though 3.3.1 isn’t all about Flash.

I don’t have time to care about everything. Should I make the time for this? I just don’t know. I don’t expect it will ever affect me personally, so it makes it that much tougher to care about. That’s not a laudable position, but it’s accurate (for me).

But there’s one notable thing here: there is no App Store for Macs, and no section 3.3.1 for Macs. C4 began as a Mac conference, and it could remain a Mac conference. I’ve been to every single one, and I’d love to go again. They’re been hugely valuable to me.

Regardless, Wolf deserves another huge round of applause and the heartfelt thanks of many people for putting on C4. It was always awesome.

I’m standing, saluting, and trying not to cry.

Cool Things

Some things I’ve recently become a fan of. Some things I like.

Mercurial
BitBucket
Dropbox
UserVoice
Negra Modelo

Nashville flooded

I follow Nick Bradbury on Twitter for the obvious reasons: he writes FeedDemon and he’s a friend.

But lately his tweets have done extra duty of getting the word out about the catastrophic flooding in Nashville. For some reason it seems like the national broadcast media have been slower than normal in getting to this story.

Look. When a city is in trouble, we have to pay attention and we have to help. We all know this.

Nashville is not the dark side of the moon: it’s home to a civilization of people who get out of bed, work, play, feed the cat, watch TV, make things, wonder about the future, learn things, drink a few beers, mow the lawn — and who are united now in wishing the rains hadn’t fallen like this, and who now need help.

Nick’s Twitter page has good links, including links on how to donate.

Archive