Android Development

It has been a while since my last dev related posting but here it goes. I decided to pick up android development to see how it goes and if it is as hard as people say it is. This blogpost will give you a little insight in the things I stumbled upon. Be warned. This blogpost is not written in some chronological order. It just a bunch of things I have to remember when doing android development. Therefore this post can be updated in the future.


When following the default tutorials from android you start with creating an activity. An activity is a screen with all your controls on it for that state of the application. If you have a simple soundboard application that is a fine approach. But when you want to have a more complex application with multiple ‘states’ it can become somewhat complicated because of the lifecycle each activity has.

Something I don’t like about the standard tutorials is that afterwards you end up with a big activity that holds all the logic etc of your application. Imagine what happens if you have a big app that uses one activity? Spaghetti code! And that is something I try to avoid. Therefore when I started development I already thought about activities as my ‘view’ and the various listeners defined in there as my controllers all other stuff that is not directly bound to the view is done in back end classes. And here comes the problem with that. When you design a application and add a listener to it you have to do something with the ui again. Lets say you send some data and you want the result to show up in a simple textbox.

Having the following code will give you a nice little exception

you need to initiate a extra call

When I first got the exception from the first code snippet I remembered this was also happening when developing eclipse plugins. The problem with the first snippet is that the code could block your UI (since you are doing something in the same thread) and android/eclipse has covered for that.


If you want to communicate between activities you need to use intents. Intents are also used for inter app communication. The problem with this approach is that when the second activity is started the previous one will be ‘paused’. That means that no code should be running. Just be aware of that when designing a app that needs to listen on the background for something. I used a singleton for that which is initiated at the first Activity and whenever an activity gets destroyed (not paused!) that singleton is destroyed as well. All activities that need to know something about the state of the listener can subscribe to its events (using observer/observable) and will add himself or remove himself from the list when created/resumed  or paused/destroyed.


As with other things (like xpages.. ) be aware of the lifecycle! Aargh.. I hate these things..

Android LifeCycle

Before you start doing something fancy be sure to implement all methods in your activity and add a log call to it so you can see what happens when and in which order.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.