October 25, 2014
Hot Topics:
RSS RSS feed Download our iPhone app

An Android Developer's Top 10 Gripes

  • January 11, 2010
  • By Chris Haseman
  • Send Email »
  • More Articles »

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.


Tags: open source, Google, Android, fragmentation, mobile developer

Originally published on http://www.developer.com.

Page 1 of 2



Comment and Contribute

 


(Maximum characters: 1200). You have characters left.

 

 


Sitemap | Contact Us

Rocket Fuel