Consequences of an Open OS, Part 1

A great deal has already been written debating the pros and cons of Apple’s “closed” iOS on one hand and Google’s “open” Android OS on the other. While I do have a strong opinion about which is “better” I will try to withhold those opinions for this piece. My intention here is simply to provide a few anecdotes which demonstrate the side effects of having an OS which is totally open. Indeed, I have experienced an equal number of headaches developing for iOS as I have for Android and perhaps someday I will chronicle the consequences of a closed OS. But for the time being, I’ll focus on Android…

The amazing disappearing, reappearing button text

A few years ago when I first started developing for Android, a ticket popped up in my queue which was titled something like “Text missing from Submit button”. Puzzled by how I could have missed something as big as this, I immediately checked the code to make sure I wasn’t doing something silly. Satisfied by how everything looked I fired up the build in question and there, clear as day, was some nice bold “Submit” text. Seeing that the code for the button in question was a whopping two lines I saw no way that I was possibly doing anything wrong. So, I chalked it up to user error, resolved the ticket as “won’t fix” and moved on with my life.

Several weeks later the same ticket appeared in my queue which left me totally perplexed. I spent another good chunk of time looking at the code wondering how in the world something so simple could be causing problems. I tested on several emulators and two physical phones (a Nexus One and a MyTouch 3G) and finding no problems I decided to seek outside help. Suspecting it may be an issue with a specific device, I sent a blanket email to my colleagues asking if everybody with an Android phone would kindly test the latest build and report back if they noticed any problems. As luck would have it, somebody did indeed notice the missing text. The problem device? A Motorola Droid X.

Still a little skeptical, I asked if my colleague could send me a screenshot and the button text was indeed missing! Not only that, but the button itself, which on all test devices appeared light gray, was actually dark gray. I zoomed into the image and squinted my eyes. There, very faint but still visible, was the elusive “Submit” button text. I finally had my eureka moment! Here’s what was happening…

The default text color on all Android devices I had used was a piercingly pure black. In an attempt to soften up the UI a bit, I had applied an app-wide style which made all text a very dark gray instead. The problem is, Motorola had decided the default light gray button background wasn’t cool enough for their edgy new Droid X, so they tailored the Android OS to make the default button color dark gray. So now my custom dark gray text was being displayed on a default dark gray button. Thanks Motorola, there’s several hours of my life I’ll never get back.

This experience taught me a valuable lesson about developing for Android: if you want to guarantee a consistent look and feel across devices, you can never rely on default UI elements. One of the implications of “openess” which is now obvious to me is that carriers and phone makers can change literally anything they want in the OS.

– Martin Patfield, Mobile Software Engineer