Here are some tips from my personal experience so far with Android development. The number of tips is actually ten, so I could have called this “Ten Tips for Android Development“, but I figured there were already enough articles with that catchy title. Which reminds me of late comedian George Carlin :
I have a problem with the Ten Commandments. Here it is: Why are there ten?…Why not nine, or eleven? I’ll tell you why. Because ten sounds important. Ten sounds official. They knew if they tried eleven, people wouldn’t take them seriously. People would say, “What’re you kiddin’ me? The Eleven Commandments? Get the f*** outta here!”.
OK, now that I opened up with a joke, let’s get into more serious stuff…
1. Choice of IDE
Most of the Android development is centered around Eclipse, although I coded a few applications using IntelliJ IDEA’s Community Edition without any problem. Personally, I don’t care much about Eclipse’s UI drag-and-drop interface. which is anything but impressive. Way more work needs to be done here.
2. Develop for the masses
All of us would just love to use the latest Android version with all the cool new stuff. Unfortunately, the Android smartphones on the market don’t exactly follow the speed of official version releases. So before diving into coding, do a preliminary check. An application written for the older versions works with the newer ones, but the reverse is of course not true. At this time, version 2.3 (Gingerbread) is still the dominant one. so you might want to wait a while before biting into an ice-cream sandwich.
3. Forget the Emulator, get the Real Deal
Forget the emulator. It’s painfully slow, and you can only test a limited number of things on it. I use it only to test how my apps look like on bigger screen sizes, and that’s about it. So, if you want to save time, use a real device connected via USB. I’d say you actually need two devices, since odds are, you’ll have to test things like SMS, Bluetooth, and anything else requiring device-to-device communication. Even better if your second device has a different screen size. The more different the devices, the better you can test your app.
4. Don’t like XML? Too bad
All of Android’s UI is based on XML, which caused most of my initial headaches when I started. Although there are some tools that can assist you with some aspects of the UI, like Action Bar generators (such as the Sherlock, or the one from Johannilsson on Github), I am not aware of a complete GUI builder at this time, that would do all the low-level work and not be a Leaky abstraction . All the visual editing tools I tested were buggy or incomplete. If you happen to know a decent one, please let us XML-wary folks know.
5. Use modular UI structure
The amount of XML needed to build a decent UI can become quickly…daunting. Therefore, build components for reuse between different layouts as much as you can, using includes and fragments. Fragments were introduced in version 3.0, but you can download support libraries if you are developing for earlier versions.
6. You need a Designer
Or you need to become one yourself. There are a few online facilities for adding common GUI elements to your app, like the Android Asset Studio, but if that’s not enough, you’ll need to design your own, adapting for different screen intensities. Be sure to also read the official Android Design guidelines.
7. Use Android-specific solutions where applicable
The Android-specific solution is usually simpler and/or yields better performance. Taking multi-threading & asynchronous processing as an example, consider using an IntentService or AsyncTask before looking at the java.util.concurrent package, although in some cases, the latter might ultimately be the way to go.
8. Google is still your friend
Although the amount of documentation on the Android developer official site is extensive, it is often faster to just google what you’re looking for. As a concrete example, here’s a result search on deleting SMS messages on arrival at stackoverflow that gives more insights than the official docs.
9. Beware of Miracle Tools
Without mentioning a specific one, be wary in general of products that pretend to ease smartphone development across the board (Android, iOS and Blackberry RIM, all at the same time). I am not saying they are all crock, but be sure to test them first by developing a simple yet significant app and deploy it on all of them. Each display should look like a native app on that OS. Of course if you are only developing a Web app for mobile devices, you need not be overly concerned by this.
10. All good software practices still apply
Test extensively (using Monkey, for example), design for i18N and localization, use Design Patterns etc.
At a very bare minimum, you should make an effort to separate UI code from your business logic, even for the smallest applications. Not doing so is just asking for trouble down the road.
Developing on Android is an exciting experience, in spite of all the frustrations caused by imperfect or non-existent tools. But that is sort of logical in a relatively new environment. The bright side is, things should get better overtime, and fast.
