A Few Tips for Beginning Android Development

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.

Update:There is also Android Studio IDE which is based on IntelliJ IDEA.

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.

Update: As you may have already inferred from the preliminary check link, Android 4.xx is now the dominant version. The advice still holds if you plan to support the older versions. That of course, will become increasingly less relevant as time goes by.

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.

Update: The emulator performance can be improved with the Intel x86 Emulator Accelerator (HAXM – thanks to Ron Eisele for the info). There is also the Genymotion Emulator with Oracle VirtualBox.

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.

.

This article is also available at JavaLobby.