The Gameshelf

Software Multitasking

As everyone has noted, the iPhone supports software multitasking; it always has. Apple's apps can do it, and yours can't. (Gruber wants to say "App Store apps can't," but I don't know what the hell his point is. Apple makes the rules for you and me, and they don't apply to Apple, and that's the game.)

App Multitasking

This is where life gets interesting. Alvares writes:

On a desktop computer, I would have a Safari web page open in one window, and floating beneath or beside it, is a TextEdit window. I can research multiple articles using different tabs, all the time copying stuff over to TextEdit for my research. Some variation of this is the most common form of a multi-tasking workflow on a computer.

Clearly correct, and I say so because I'm doing exactly that right now. Browse, check reference, browse, add to blog post, repeat. Or Ihnatko's list of things you can't do on an iPhone:

Download the file attachment from my editor's email, cut 3000 words that were utterly essential to the story, then email it back. Or download the column from cloud storage and open it in my word processor. Or write a whole new piece and attach it.

The first crux for this kind of workflow is copy and paste. When copy-paste hit the iPhone, it enabled a level of multitasking that people were desperate for, even though they didn't call it that. Browser to email, email to calendar item, calendar note to Google Maps lookup. Doing crap that involves several apps.

The second crux is fast swapping between apps that save their state. I don't care if my editor is exiting and restarting, or just hiding its window, as long as I can jump in and start editing my file.

The other second crux is some kind of document exchange between apps. We've already heard rumors of this for the iPad. (And between the iPad and its host desktop machine.) It's copy-and-paste grown up... and a blow to the "users should never ever see the filesystem" camp, because as soon as you need to find files from a general pool, you need... a Finder. Of some sort. (It doesn't need to display /etc or /usr/lib, but OSX got that right ten years ago, okay?)

(Chewing out the exact affordances needed by an iPad Finder is a problem for another day and another howling Finder argument. As if we were short of those. Drop it for now.)

User Multitasking

I'll tell you a story: Monday night, I started installing OSX 10.6 on my laptop. I stuck in the disk and pushed the shiny button. "Okay," I said to myself, "now I will start writing that blog post on multitasking."

Total failure. What? I was using my desktop Mac. But the laptop was whirring away on the desk behind me... a miserable distraction. I kept turning around to peek at the progress bar. I wound up reading Livejournal until my eyes bled -- on the desktop Mac -- and didn't get a damn thing done except supervising that install. "Supervising." Later, I installed XCode.

I suck at multitasking.

But some kinds of multitasking, I'm used to. I can run a chat client in the background, and keep an eye on a couple of chat rooms. I've started doing the Twitter thing, and I'm learning to keep an eye on that too. In the background.

Then there's sensory multitasking. The two obvious multitasking apps on the iPhone today are iPod (music playback) and the telephone (voice chat). The two favorite third-party background requests are Pandora and Skype. All audio apps, and that's not a coincidence: a human being can look at one thing while listening to another. We're good at that kind of multitasking.

Outside the audio realm, "multitasking" is sometimes -- not always -- a euphemism for "fast user task-swapping". That's why this talk of iPad widgets is interesting; you could wind up popping up small "at a glance" apps without leaving the app you're in. (Shades of Desk Accessories in System 6!)

Note how here, too, "background" almost begs the question -- in terms of our familiar desktop metaphor (on our desktop computers!) My chat room sits in a window behind all my work windows, partially obscured. In the background. On a non-windowed interface, the metaphors will change; Palm's WebOS uses cards, Google's ChromeOS uses panels. The implementation -- whether these are persistent processes, run-fast programs, or snippets of Javascript in a browser context -- are almost irrelevant.

The Collisions

...Almost irrelevant.

Sometimes software multitasking does matter.

I want to run SSH on the iPad, to connect to remote servers. (Like my web server.) It will be possible. There are several SSH iPhone apps. I don't use them -- the pop-up keyboard does not mix well with Emacs, but the iPad's size will solve that tidily.

SSH, and other remote login apps, only make sense with a persistent network connection in the background. If you switch out to read a twitter message, and the SSH app shuts down, you've lost what you were doing. (Oh, sure, you can run "screen" on the server, but there's still reconnection time, and basically it sucks. It's not what you want.)

Only crazy Unix people want SSH -- but there are other examples. IM clients generally want a persistent network connection. I use Jabber (same protocol as Google Chat); it's designed to be really fast in normal usage, at the cost of being a little bit slow to start up. If the client had to start up and connect every time you glanced at it, the performance would be terrible.

These are not invisible "implementation detail" issues. They're real. Look at Twitter. It's effectively an IM system with no persistent connection. Every Twitter client has a "refresh" command -- because there's no persistent connection, so the client has to authenticate and poll, over and over again. It's slow. Sometimes you have to kick it. That's the way it is. In contrast, a Jabber client displays messages instantly, it doesn't need a refresh button, and it takes less battery power because it doesn't have to log in and poll a server repeatedly.

(Yes, that's right. Battery power is a red herring. Any well-written app -- and Cocoa makes it easy to write apps well -- will use no CPU, and thus no battery, while waiting for network input. Background file downloading (or uploading) takes no extra battery power, because you were going to do that download anyway. Background music playing takes the same amount of power as foreground music playing.)

(The real bottleneck for software multitasking is RAM. It's tight on the iPhone, better on the 3GS. I have not yet seen a source for how much RAM the iPad will have.)

The Workarounds

Every discussion of "iPhone multitasking" flies off the road into the weedy scrub of appropriate workarounds. Push notifications? Copy and paste! (See, I did it too.) A commenter in the Alvares post writes:

The ESPN Radio app handles this seamlessly, by having a "Play in Background" function that basically launches Safari and plays the stream from there.

Will Safari become the Swiss army engine of getting crap done in the background? It's not like other mobile devices haven't played the "all in the browser" card... Come to think of it, so did the iPhone, once. Briefly. But needs must when the Apple drives, and hackers will use any crack they can wedge their tools into.

...That sounded dirtier than I was expecting.

The point is, there are a lot of possible "workarounds" for the "multitasking" problem, and they each work around different corners of the different problems camped under that banner. Sharing data between apps? Loadable code modules plugged into other apps? (That was how the old Sys6 Desk Accessories worked, and OSX had them too although they're going away.) What about simply keeping an Internet connection alive in the background and letting an app start up with the connection already going? Suggestions abound.

But you can't evaluate a suggestion until you have a good account of the problems.