The reason why I haven’t wrote much here on the blog lately is that since I’ve got my android phone I’ve spent most of the free time tinkering with it. And by tinkering I mean developing simple applications and learning the framework. From my perspective spending a few hours coding something which in the end makes a simple (and some might say stupid) blink on the screen is way more entertaining than playing AngryBirds or Teeter.

Everything started with a question my friend C asked me after he got his Android phone: “Could you look at this Eclipse development environment? Do you think it’s hard to develop some simple applications?” At that time I said: “How hard can it be?” and quickly downloaded the environment and the emulator. After some days play with the emulator I could not wait to get my hand on the real thing.

Why? Mainly because you soon realize that this small phone is a computer much more powerful than the one you had wrote your first computer program on and also it’s packed with so many other interesting devices: touchscreen, camera, sensors. Not to mention that the screen density is 3 times higher than what you could get on a new laptop (see more on this sad topic).

So, how hard it is to start developing on Android platform?

After a few tinkering weeks, my answer is that it can start as deceptively simple but then you might end spending lots of time learning how to do aparently easy tasks.

As you start with your first application, one of the first things you will notice is the xml for defining the gui. Since I’ve worked extensively with flex in the last years this seems normal at first, but there are still some major differences. There are many people who complain on the net that there is no gui tool for editing the xml but from my perspective working on linux you don’t often get to have a gui tool so this is not a problem. What is a problem, however, is the fact that the xml is too much machine like. If you are supposed to edit the xml by hand why not make it brief and simple? Changing the android: namespace to a: would make a great difference for instance.

Another difference from the flex world is that you will imediately miss the bindable properties. Let’s say you want have a TextEdit and a Button and you wish to have the button enabled only when you entered some text. In flex, this is only a matter of writing something like:

<pre lang="xml"><button enabled="{myText.text.length > 0}"></button>

there is no equivalent on android and you end up writing something like:

<pre lang="java">((EditText)findViewById(R.id.name)).addTextChangedListener(new TextWatcher() {
 public void afterTextChanged(Editable s) {}

 public void beforeTextChanged(CharSequence s, int start, int count, int after) {}

 public void onTextChanged(CharSequence s, int start, int before, int count) {
 if(s.toString().length() == 0){
 ((Button)findViewById(R.id.save)).setEnabled(false);
 }else{
 ((Button)findViewById(R.id.save)).setEnabled(true);
 }
 }
 });

Of course you won’t have to develop huge screens with lots of buttons and events for a small android application and you write similary complex (lots of) code when developing a Swing, AWT of SWT java application. The XML definition for the gui is a step further from the standard java gui development, but compared to flex it’s a step too short.

So your get your refuge in the SDK doc but there again something is missing. And what I’m missing is the example section which I got so used when using the flex docs. You end up having a steeper learning curve than expected until you familiarize yourself with the widgets and the more strange naming attributes (such as “gravity”). Not to mention that you end up doing too many google searches for things you should find written in the docs. I was expecting better from google.

One of the other important differences which you have to get used to is the application lifecycle. It might seem marginal at first but in fact you have to start designing your application with this in mind otherwise you will have to refactor later. So, design considering the application lifecycle. And still, even if you do so you still might have surprises. For instance your Handler.postDelayed timer only counts uptime time. When your phone locks there is a good chance it won’t fire. But that’s a completely different, and too detailed point (for later).

What about the sensors? This incorporated game controller will surely get most of your interest. Well, it’s easy to write an application which gets sensor data, there are tons of examples on the net. But once you start digging into the data will soon realize that it does not always makes the sense you tough it would. I have just a conclusion here: don’t use the orientation_sensor, it’s bad, construct the data yourself.

In conclusion, getting an Android phone should be a great gift for any of you geeks out there. It will give you some great fun.