Android Code Day

After a much-awaited Release Day and the obligatory pub afterwards, last Thursday marked the end of January and Android Code Day in London and Tel Aviv. It was my first time in Israel, which made it more exciting As much as I'd like to visit Israel, I wouldn't be able to justify the expense (it might happen in the future with the current trend in ticket prices). The good news is that the train journey into London is relatively short and painless.

After waiting around in the lobby, we were eventually escorted through brief NDA-signing (is it legally binding if there's no expectation for you to read it at all?) and then upstairs, into a meeting room just big enough to hold 40 people and their laptops without feeling crowded.

The first half of the day was taken up by a brief presentation by Jason Chen, interleaved with a not-so-brief and highly interactive question-and-answer session. Then there was lunch, with the usual perks (who wouldn't work for Google for a freezer full of Ben and Jerry's?) and some insight into Google's business strategy.

Top-secret plans

We started the afternoon with a brief demo of an Android app from an audience member. It was pretty decent for only two days' worth of code and some borrowed sprites -- maybe Android phones will compete with the PSP (in keeping with tradition, they've tested Quake on Android prototypes, with reasonable performance).

A familiar game…

... stretched by OpenGL in landscape mode

The "hackathon" commenced, but as the average level of experience was "has compiled and run the hello world app" (and the documentation is written in the traditional Javadoc style that never manages to tell you how to do what you want to do), I don't think much coding actually happened -- that wasn't really the point of the day. Jason Chen is a Developer Advocate; so's Dan Morrill (the first link in this article). He writes "I get to travel the world to meet developers and talk about cool technologies. I can't believe I get paid for this!" though Google is keen on hiring more Developer Advocates.

It's not hard to see why: the room seemed to consist of people from handset manufacturers, mobile OS companies, people wanting to see if Android is worth investing time into, and people there just to keep track of what Google was up to -- in fact, the last category seems to cover everyone.1 One of the most promising things about Android is an abundance of cool, novel, well-written, currently nonexistent apps -- it's a chicken-and-egg, and Google can only hope that apps are easier to produce than users (what do you think the Android Developer Challenge hopes to accomplish?).

Of course, it's really future users that give decision-makers the incentive to spend money on a particular platform. Until we invent time machines, we'll have to settle for a significantly high probability of a significant number of future users. The greatest impediment is actually having phones for sale, but the problems there are largely political, and if I started on politics I'd be here all day. Once phones are on the market, there's another problem:

Android has to be good.

And by "good", I mean better than the next phone on the shelf. Of course, customers define what's "better", but what do you see when you go phone shopping?

  • The brand is difficult to change.
  • The design is difficult to do well, but at least the OHA has Motorola.
  • The "specs" that the shop decides to show are rather arbitrary.
  • The price matters, but in the UK, it's largely "free on contract" (at least Android is free, so manufacturers can save on licensing fees).
  • What your friends say is even harder to change.

Word-of-mouth is often mentioned as the most important form of advertising, and also the hardest to get right (should I be worried that nobody seems to know what Android is?). But personally, if there's anything that'll make me recommend one phone over another, it's the UI, probably because it's the thing which irritates me every time I use a phone -- it's also where Android has a chance to shine, since (in theory) you can rewrite everything, even if you end up with a bloated home screen app that does everything under the sun.

Without going into technical details (there's plenty on YouTube), Android has a few distinguishing features; the most notable is that it tries to be designed around the user experience. Intents are a key idea -- they encapsulate what the user wants to do. The system passes the request to whichever app says it can fulfil the intent -- apps aren't replaced, intents are.

The problem arises when you have many apps which want to provide some basic enhancement. If I have Skype on my Android phone, here's what I'd like to see:

  • Skype status shows up in the contact list.
  • Calling a Skype-online contact makes a Skype call over Wi-Fi.
  • Calling a Skype-online contact asks me before using HSDPA, in case I don't want to end up with a big phone bill and violate the no-VoIP clause of the ToS.

It's conceptually easy, with one catch: you don't want to replace the contacts and dialler, because apps can't access another app's data. It's difficult to do the right thing when you change contacts apps between adding, removing, editing, and renaming contacts, and it doesn't work with Google-talk or Gaim Pidgin, let alone a psychic dialler which reads my brainwaves and calls the right person without me asking.

What users expect is the concept of a global address book, with each contact (an ID) optionally linked to names, phone numbers, e-mail addresses, snail-mail addresses, WGS84 coordinates, IM usernames, and anything you might associate with a person (or group of people).2 Similarly, apps which handle intents ("send a text message") can also advertise a "quality factor" (RFC 2616) that changes dynamically, so that Jabber's "quality" drastically decreases when I move out of range of Starbucks and my phone starts using roaming HSDPA, hopefully going below a threshold which prompts the phone to ask me first. Suddenly, my phone has a better IM client than my computer: it'll switch to SMS when Wi-Fi isn't available, connect to the office's SIP server, and give me the directions to tonight's party.

There's been little work on any platform to address these; as a result, there always tends to be one app that ends up on top with everything else struggling to catch up -- IM clients throughout the decades have followed this trend. Phones are a different matter, and unless something reaches critical mass, we'll just end up with a lot of fragmentation. While compatibility issues aren't an aspect of fragmentation that the audience seemed to be worrying about (people seemed more worried about OEMs taking Android and making it proprietary), they're important to the user experience: seamlessly integrating apps together is an important part of a good UI.

Another thing which doesn't exist in Android is input methods -- the current emulator only supports primitive touch screen and a keyboard. How will multitap work? What about graffiti, handwriting recognition, or an on-screen keyboard? These tend to require extra screen space, which means it has to be coded into each app or provided by the system; there's currently no easy way to give another app a certain portion of your screen. Besides, the keyboard should only appear when I've selected a text field (and it should let me write/graffiti directly into a text field). What about gestures? Or force-input?3

When you control nearly everything about a device, it's much easier to make a good UI instead of just a decent one -- the iPhone kept coming up as an example of a good UI throughout the day.4 Android will stand between everybody's apps and the underlying hardware, whether there are 30 keys or none, and it needs to provide enough abstraction so that developers can rely on the system to do the Right Thing and still give a good user experience. It's what Android is designed around.

At last, the day came to an end, and I left for King's Cross. Though the room was teeming with skepticism, Android is something that I'd like to succeed, and I'll be watching the OHA's four handset manufacturers closely over the next few months (maybe Motorola will finally make a phone that looks pretty but doesn't irritate me every time I try to use it).

There's going to be another Android Code Day in Boston on the 23rd. It's worth going to, especially if the impending SDK update, happens first. Besides, you can always enjoy the Ben & Jerry's on the mission to uncover Google's master plan.

  1. Working with mobile software imparts a strong urge to know what everyone else is doing, possibly to learn from those who have done it better than you, or in search of the next great platform which is reasonably profitable and both a joy to use and code for (my recent experiences with a certain OS/IDE/build system can be summarised as it should not be this difficult!). 

  2. One can only hope that it won't be implemented using XML. 

  3. Want to turn the alarm off? Hit it. This is probably patented. The W380a lets you turn off the alarm by waving at the camera. 

  4. The iPhone and the BlackBerry the two phones which I hear described as good, not just better-than-something-else. 

Teanlorg Chan
in Opinion

Airsource design and develop apps for ourselves and for our clients. We help people like you to turn concepts into reality, taking ideas from initial design, development and ongoing maintenance and support.

Contact us today to find out how we can help you build and maintain your app.