http://www.developer.com/ws/android/programming/An-Android-Developers-Top-10-Gripes-3857796.htm

Back to article

An Android Developer's Top 10 Gripes


January 11, 2010

Put on your favorite self-pitying emo music and get ready for some developer frustration. I'm running down the top 10 things I love to hate about Android.

1. Open Source

Leave it to Google to place all the code for their handset platform in the hands of the masses. Not only does this mean anyone can download and roll a new version of their phone firmware, but it also means absolutely any maker can roll its own Android device. I'm looking forward to an Android-powered toaster oven any day now. What's worse is Google knows how to protect valued code; Its Maps, Gmail, and Store applications aren't open source. Figuring out when it's okay to include one of those in your own application requires a crack legal team with a hotline to the EFF. This is the most benign on this list, and it's only here because now everyone and their brother is going to make a new "Android-powered" device.

2. The Tyranny of the Activity

Through the Activity, Android forces developers to build apps in smaller, bite-sized chunks. For example, in their sample text editor code, they have one Activity for picking from a list of editable files and another Activity for actually editing a file's contents. Android also encourages developers to communicate among their Activities using Intents (more on why I hate those later).

This design would be dandy for mobile software except for one thing: exactly no one else works this way. J2ME, the iPhone, BREW, and Blackberry all work with the notion of a centralized application object (The Blackberry/J2ME Midlet or Brew's IApplet). Android, by contrast, pushes you to design everything as small, self-contained mini-applications. This decision leads to some really interesting behaviors. By default, for example, when a user rotates the screen or pushes the keyboard out, Android destroys the current Activity and then recreates it.

In the end, professional mobile developers are left with two options:

  1. They can design their software on other platforms to use the Activity/Intent model so that Android ports easily.
  2. They can hack, slash, burn, and duct-tape Android into behaving like every other mobile platform does.

I suspect you, dear reader, can guess which direction this grumpy author has had to take.

3. Device Debugging

Back in my day (and by "in my day," I mean two years ago), debugging on the handset was a trying proposition at best. I've written my own logging systems for J2ME, relied on beep codes to tell me if code had been hit under Brew, and lost sleep wondering if a particular log line was really the last log line to be rolled over before a crash. Google, curse their cotton socks, has quite literally taken a process that used to involve hours of work and reduced it to simply pressing F11. Not only is it straightforward and easy to use, but it also works on every platform out there (Mac, PC, and Linux).

Why do I hate this extremely useful tool? I hate it because it makes about 40% of my debugging skills nearly useless! Next thing you know, Google will enable anyone to design a mobile app UI using nothing but XML... oh wait.

 


Visit the Android Dev Center

 

4. Applications Never, Ever Quit

Once an application starts on Android, it never quits—ever. Your applications might be unloaded in the background, but your icon stays in the list of running tasks (in case your application is ever spun up). This strange yet central architecture decision makes for some interesting software bugs and necessitates some quirky application design workarounds. Further, it leads to "Process Killer" applications and to what one of my college textbooks correctly dubbed "The Developer Cooperative."

5. The Developer Cooperative

Remember back to college and that Economics 101 class you didn't take. In that mythical class, they might have talked about a term called the tragedy of the commons: the misuse and overuse of a collectively owned resource. In the case of Android, that common resource is the memory, processor, and battery life of the handset. The tragedy is that any application, while in the background, can use any amount of resources. This is why performance and battery life on Android handsets can be so unstable.

Google just expects programmers to use fore and background cycles wisely, which most of us do, right? However, one careless developer can single-handedly demolish a weekend's worth of battery power in a matter of hours.

6. Java—Thanks, But I'll Take It from Here

The Java language, a very powerful tool, is on this list for two reasons: It's big, and it can be very hard to optimize. As a programmer, it makes me feel like I'm getting a very slow lobotomy. While it might speed time to market by freeing us from chasing down heap corruptions and memory leaks (two of my least favorite tasks), it can make it nearly impossible to, say, write an anti-aliased font library that renders in a reasonable amount of time. Sure, a developer can write custom libraries in C with their NDK, but now we're debugging two languages instead of one.

7. "Intents"

This is a technical writer's third-worst grammatical nightmare. An Intent in Android is the class used to communicate between Activities, Services, or Content Providers. Intent is a noun that commonly also works as an adjective, but never, ever, should it be plural (And "for all intents and purposes" doesn't count. It's pretty much a colloquialism). This has led to some very awkward conversations with my copy editors in the past year or two. Every time I use Intents in a sentence (say, right now for example), I'm left feeling like my elementary school grammar teacher is doing summersaults in her grave (Although, to be fair, she probably does the same thing every time I misuse a comma).

8. Platform Fragmentation

It's not just a buzzword, it's a real problem. Quite possibly it's the problem that could sink the Android platform as a whole. While Android's design might be geared towards the hobbyist developer, having to buy 50 handsets and validate your mobile app on all of them is real ordeal for the pros. As more devices with more screen sizes arrive on the market, maintaining an application is going to be a more and more exhausting process. This process won't be made any easier as Google's already loose grasp on the platform as a whole continues to loosen.

Worse, there really aren't any easy solutions for Google to implement. As Android becomes more popular, each OEM will manufacture devices with their own quirks, bugs, and oddities. Which, unless Google counters with a liberal dose of the forbidden 'Evil' word, is going to make this platform impossible to fully support for all but the most dedicated hobbyist or well paid professional.

9. A General Lack of 'Evilness'

Sure, Google is "open;" they publish all their source code. (Except the bits that power the giant money press hidden somewhere in their Mountain View office.) OEMs may have to clear a compliance hurdle in order to get Maps, Store, and Gmail apps, but either the hurdle isn't high enough or Google isn't very good at keeping OEMs from going under it. This lack of an iron grip (which both Apple and Verizon have effectively, if obnoxiously, employed on mobile developers) is exactly what is leading to the current and future fragmentation of the platform. Who knows, perhaps NSTL will swoop in to the rescue and start regulating app developers. (Anyone who's developed for BREW will know no greater fear than hearing those four letters.)

Google, with luck, will learn when it's good to be evil and when it isn't... but there's always that pesky slippery slope.

10. Hardware, Hardware, Hardware

The current crop of Android hardware, for lack of a better word, sucks. It's come a long way since the G1, but it's nowhere near the iPhone. Further, handset OEMs seem to be chasing the iPhone rather than making their own design decisions. The Droid was a step in the right direction, and the Nexus One looks to be another big step towards real hardware viability. Frankly, I'm tired of my smug iPhone developer friends lording their platform over mine. Further, I'm tired of them being right.

That's my list. I've checked it twice. After all's said and done, I really must admit that Android, despite its relatively few flaws, is one of my favorite platforms to work with. Quite honestly, if my complaint about how the word 'Intent' makes for awkward grammatical constructions ranks in the top 10, I'd say the Android platform is doing pretty well for itself.

Oh, and you can turn off your emo music now.

About the Author

Chris Haseman is an independent software engineer specializing in wireless development. He can be found riding his bike between coffee shops in San Francisco. He's the author of the book Android Essentials (published by Apress). In his spare time, he's a resident DJ at xtcradio.com and a martial arts instructor.

Sitemap | Contact Us