These days, I spend quite a bit of time talking about how to write software for Android. I think three of the general rules are worth expanding on here because I’m increasingly convinced they apply to software in general, not just for mobile devices.
Crash-Only · An Android app doesn’t need exit code. You have callbacks for when you start up, when you become active, and for when some other app takes your place and pushes you aside; the latter two will typically be called repeatedly as the phone’s owner switches back and forth between apps.
But there’s no need for exit code because the system can, and does, nuke your process any time you’re not active and it needs the memory. What that means is that it’s your responsibility to save any state you might need in the future, and without asking anyone to select “File/Save”, either.
At some point, after I’d explained a few times why you have to write software this way on Android, I started wondering why all software, without exception, isn’t written this way by default.
Loose Address/Type-Driven Coupling · The way you hand off from one screen to another in Android is with an Intent. An Intent has a Target, an Action, a URI, and a data type (as in Internet media-type, MIME type), along with some ancillary stuff. You can specify a target, essentially a class name, and control passes to that class. Or you can specify an action (make a phone call, view something, delete something) and its URI and or media-type, and let the system pick the right software to deal with it.
So, in your app, when whenever your user taps on a URI, you fire off an Intent with the URI and the “view” action, and control passes to his or her favorite browser.
This has the nice side-effect of pushing you on the stack, so when the user gets tired of browsing and hits the Back button enough times, eventually she gets back to your app. By fiddling media-types and actions, it’s dead easy for the user to traipse naturally between Twitter, the browser, maps, contacts, photo-browsing, music-listening, and so on, never losing the use of the all-important Back button.
Gosh, this notion of tying everything together loosely with addresses, data types, and a few simple verbs seems to have legs. But since it wasn’t obvious to me from first principles that it would be a good way to construct mobile-device software, I’m wondering if maybe in general it’s a good way to do almost everything.
Remove Decoration · We advise people that, since mobile-device screens are small, that they have to focus on data not decoration; get rid of all the headers and trailers and sidebars and toolbars that you can, so that the user gets the maximum-possible amount of payload.
Computer screens, whether desktop or laptop, are by comparison huge, and this has led to a temptation to festoon interfaces with all sorts of decoration and apparatus and gadgets and widgets and whatever.
The fact that on the mobile screen there’s just not room for that stuff makes me increasingly wonder how much we really need it. With every hour I spend traversing here and there on the Web, wincing away from sites that are decoration-heavy and smiling at the ones that are all-message, the feeling grows.
Contributions
Comment feed for ongoing:
From: peSHIr (Oct 30 2010, at 07:45)
Sounds a lot like the rules Microsoft took to hart (sometimes to the extreme even) with WP7. Good stuff.
[link]
From: G. H. Chinoy (Oct 30 2010, at 09:34)
"exit" not as harmful as perceived - For "user" experience sake (sorry, used the U-word) some perception of security is given by an "exit" button - banking apps, etc, even if the application lifecycle takes care of ending session.
[link]
From: Ed Davies (Oct 30 2010, at 09:35)
"At some point, after I’d explained a few times why you have to write software this way on Android, I started wondering why all software, without exception, isn’t written this way by default."
Because most file systems are still trying very hard to emulate paper tape in order to make it as awkward as possible?
[link]
From: Peter (Oct 30 2010, at 10:11)
Most Google Android apps seem to have a header these days. Some (such as maps) seem to add nothing and just hog screen space.
[link]
From: John Cowan (Oct 30 2010, at 10:41)
Save-all-the-time is fine if you have unlimited undo back past the current session, but where do you store that undo state? It could be done using the Classic Mac style of "every app its own format", but it makes life very hard for interoperation.
[link]
From: Brian Slesinsky (Oct 30 2010, at 12:40)
This reminds me of a UI issue with a web app I'm working on. For multi-user apps, "save" sometimes means "publish". I agree that you should never have to save private data or drafts, but publishing something is often irreversible. [1] So what to do in an app that allows the user to directly edit shared data? Of course this happens less often for a very personal device like a mobile phone.
[1] An exception is "Undo Send" in Gmail Labs, which I highly recommend.
[link]
From: carlos (Oct 30 2010, at 17:12)
"I started wondering why all software, without exception, isn’t written this way by default."
Someone wrote an academic paper a few years ago advocating exactly this. They showed that software designed around the idea it may be arbitrarily killed at any time was more reliable, shut down more quickly and had a host of other benefits. Of course, at 1.08am I can't find a link.
[link]
From: Daniel Grady (Oct 30 2010, at 22:29)
"Gosh, this notion of tying everything together loosely with addresses, data types, and a few simple verbs seems to have legs."
One of the features that I use all the time on Mac OS X, and wish I could use all the time on my iPhone, is being able to put a 'URI' pointing to a mail message in a calendar event or an todo item.
[link]
From: gideon (Oct 31 2010, at 01:50)
Apps should automatically preserve state.
Also: The explicit "Save" and "Save as…" option should be replaced with "Publish" and "Publish as…"?
[link]
From: Shonzilla (Oct 31 2010, at 08:29)
It would be great if web services would embrace the application and interface/API design that is more aware of some transport (HTTP?) protocol & MIME types so that one could use the native (Android) client application to send/forward an intent to a web server application. It would basically be a HTTP-based RESTful API with a security layer (OAuth works fine for web apps&services).
One example: Let's say that I want to forward an invitation as an appointment for my preferred web calendar (not the Google Calendar) as an HTTP POST request and MIME type text/calendar. The participant list would be updated with an intent that gets converted into an corresponding HTTP PUT request.
This way no necessarily every web service would require Android, iPhone & other native application counterparts. Not sure if this web-native bridge will be made before either platform "wins", which I think will not because of the very varying user demands and requirements.
[link]
From: Robert Young (Oct 31 2010, at 13:46)
@ Mr. Davies:
Because most file systems are still trying very hard to emulate paper tape in order to make it as awkward as possible?
A man after my own heart; although it's really mylar tape.
@ Carlos:
Someone wrote an academic paper a few years ago advocating exactly this. They showed that software designed around the idea it may be arbitrarily killed at any time was more reliable, shut down more quickly and had a host of other benefits.
They're called industrial strength database engines. Not trivial to write.
In general, however, the AJAX-ian migration is the attempt to recreate a connected database application, aka VT-100/RS-232/*nix/Oracle. With a phone architecture, we have that. A connected architecture will always outperform a disconnected one, HTTP for example. Managing state goes away, since the datastore always *is* the state. With said datastores on SSD, data control relegated to the server becomes a Good Thing; while the client (phone, pad, whathaveyou) just does painting, input collection, and transfer.
[link]
From: Dave Walker (Nov 03 2010, at 12:03)
As has already been mentioned in the comments, "save all the time" makes an interesting life for storage; ZFS would fit really nicely, here.
When it comes to "don't decorate", it looks like Apple have also twigged this; have a squint at the "Lion" preview in the latest Jobs keynote on how iPhone OS (I don't like "iOs" as a name, and I'll bet Cisco don't, either) UI cues (and yes, I think "user" remains a valid term) are on their way to OS X...
[link]
From: Tobu (Nov 04 2010, at 10:55)
[Here is the crash-only paper](http://www.usenix.org/events/hotos03/tech/candea.html), via [this LWN article by Val Aurora](http://lwn.net/Articles/191059/).
[link]
From: Manjeet Dahiya (Nov 11 2010, at 10:54)
Very true esp the third one, Remove Decoration.
There are so many good apps wasting real estate by just adding their logo. I find it a big flaw in their design.
[link]
From: Bruce M Walker (Nov 24 2010, at 11:56)
Re "Remove Decoration": ah yes, reminds me of the original NeXTSTEP / OPENSTEP screen. No more decoration than required to work it. Very elegant. I seem to recall complaints from some about its "plainness" at the time.
Good points, all. I think you are right that apps should behave like that.
[link]
From: Sam Dutton (Nov 25 2010, at 13:57)
> I started wondering why all software, without exception, isn’t written this way by default. <
This is so true.
Once you get used to this requirement as an app developer, it's not that painful -- and once you get used to the benefits, as a user, it's a shock to go back to apps that don't implement any kind of fail-safe.
[link]