At our last New York Scala Enthusiasts Meetup I presented on Android. I started the talk with a series of 1980s magazine ads that extolled Apple personal computers as world-changing tools for creative expression and invention. Android is a platform for hand-held computers in this proud tradition.

We’re looking for the most original use of an Apple since Adam.

After that ironic stroll down memory lane and after I presented Snapup a simple photo-snapping application I wrote to post Meetup photos, we had one of those conversations that are, ultimately, the reason we gather in public. I hadn’t gone there to talk about multitasking and didn’t have anything prepared for the subject. I didn’t hide the fact thatI knew little about the greater Android platform; I had only learned enough of its API to make my app workie.

But I had shown a number of internal background image-loading threads being created as Scala actors, and someone who did know the Android platform wanted to know if those were still chewing through valuable mobile cycles. So we opened the Dalvik Debug Monitor—my first time!—and quickly discovered (in front of forty people) that my app was stealing some cycles when it should have been idle, and actors were part of the theft.

Was this the greatest actors crime since the Lincoln assassination? Well no. I should have been telling the actors to exit after they were done. I wasn’t even really using actors, just somewhat idiomatically using an actor for a simple background thread (mentioned in the last post, actually). I assumed that the zombie activity there was negligible, but, in the Android model there is no such thing. Any wasteful polling picks the battery’s pocket all day long.

So after the Meetup I pushed ahead my plans to implement asynchronous interfaces in Dispatch using java.util.concurrent as a foundation. Once Snapup was refactored to use this higher level HTTP interface, ddms showed no activity at all from my background threads. But, there was still a significant amount of CPU burn when the app should have been idle. What was it?

It was a stupid indeterminate progress dialog animating itself off-screen. See, Android replaces the desktop concept of windows with a new concept of activities, better suited to small (or large?) touchscreen interfaces. Snapup has one activity that does nothing but OAuth token exchange, and the only face it shows to the user is a Please wait… dialog. Once it has the tokens it starts the another activity but it doesn’t stop itself. Neither, apparently, does its animation.

After stopping that nonsense, Snapup’s idle activity went down to zero where it belonged. Whether on-screen or off the process is voluntarily cryogenically frozen, the same as if the operating system had forced it to pause. Problem solved!

Yo mama

But oh my god, doesn’t this mean that your ‘mom’ or ‘wife’ is going to have a hard time using an Android contraption because of bad apps like version 0.1 of mine? First of all, That’s sexist. Secondly, No. This story means the Android human-interface to multitasking needs work.

Sure, I’m a dummy for not profiling the application before releasing it. I like making things and it worked so I jumped the gun. And there’s a lot of dummies in the world. One option is to cut us off from users and require bureaucratic approval of all software binaries before anyone can run them. Another option is to solve the problem, with design.

The old desktop software model puts users in charge of starting and quitting applications. A bit of sloppy processor use was expected, and generally harmless. When computers began to run on batteries, the task fell on users to be vigilant. Road warriors that depended on battery life learned to quit any app that they didn’t immediately need.

In the new model that’s been adopted by all successful mobile platforms, you don’t quit applications: you leave them. On platforms that support multitasking this shifts responsibility to application programmers: they are the ones that need to be vigilant. If they do their part things work great: Android’s technical implementation of multitasking is excellent. It’s up to applications to be good, or bad.

The design problem is that users (and casual programmers) aren’t exposed to this new dimension of bad. Normally you can judge software just by using it. The user interface is good, bad, or ugly. The app is fast or slow, it crashes or it doesn’t. But for battery waste the feedback loop is broken.

Android tries to address the problem with a kind of shit-list for applications. It’s is offered up when your battery runs low: Dang, who’s been using up my battery? The shortcomings of this measure are obvious. For one thing, batteries are meant to run out. Reaching the end of a cycle is not a sign that any app has been misbehaving. To find any bad apps you have to mentally subtract your historical use of each one listed. And who wants to start that investigation with an uncertain few minutes of battery life remaining?

Battery waste information, which all users now require to judge applications, is just not adequately exposed in Android.

All Activities on Deck

Where does application activity information belong? The place you go to switch running apps, at the very least. And as it happens, that place is a dump in Android right now anyway, an alt-tab popup lifted from Windows 95. In this problem domain the Palm Pre’s card metaphor is so far the only effort worthy of the touchscreen medium. There’s plenty to be inspired by there, so much as the lawyers will allow it.

Because Android doesn’t have an activity switcher worth talking about anyway, it can kill two birds with one interface and bake battery usage deep into whatever does emerge. It should be as obvious which applications are using the battery as it is which ones are running at all. This is critical information to anyone using the platform. Especially your ‘mom’ needs to know which applications are wasteful!

The Android people at Google, they’re no fools. The current lame task switcher is a sign, if anything, that there is a big fat real-task-switcher branch that their work is going into. It needs to land soon. This is the year that people are picking up and trying Android. They need to be able to say, “hey, I’m not using that app right now and it’s using my battery for no good reason.” DELETE. Otherwise, their experience will be bad.

The difference between this and the old model is simple: you don’t quit applications that might be wasting resources, you remove applications that you know are. You aren’t managing tasks, you’re firing applications. It raises the awareness of programmers making the apps too, and the incentives to write a well behaved app. By filling that information gap, we can finally reach a level of abstraction that many of us have been anticipating for decades: applications that are just there. Your trusty software is always available, right where you left it and doing only what you told it to do.

Apple thinks they can guide us into that future with an army of bureaucrats, who are surely enrolled in profiler training courses at this moment. It’s surprising how long that is taking, actually; it has made their cherished new product unveiling the butt of resonant jokes. And when they finally start to white-list ‘background’ apps it will at least be one helpful purpose of their degrading software approval exercise. But even so, a platform that enlists informed masses to collectively rank software will run circles around one administered by, well, your dad.

Just ask the first company that tried to fight off Google with an army of classifiers.