Unused module dependencies

Do you have a large project with a lot of modules? Adding a new dependency between modules is easy, removing one not so. You have to remove it, check that your build still runs, and repeat this for every dependency you suspect is not really needed.

Well, until now. In keeping with the tradition of starting a project and then abandoning it for a new idea, I’ve now developed an Intellij IDEA plugin which does just that – shows you module dependencies which are not needed.

Want to give it a go? Download the prebuilt plugin from github: https://github.com/asocaciu/idea-moduledependencies-plugin/blob/master/UnusedModuleDependencies.jar
Copy it in your IDEA plugins directory, restart IDEA and you’ll find the ‘Find unused module dependencies’ action under the Analyze menu.

Want to contribute? Here’s the code on github: https://github.com/asocaciu/idea-moduledependencies-plugin

City Quiz released

I’ve just released my latest Android App, a City Quiz application!

Questions are generated from a database of 8000 cities. There are 6 question types of questions in the Free version:

  • On which continent lies country X
  • In which country is the city X
  • What is the approximate distance between cities X and Y
  • What is the capital of X
  • Which city lies further to the N/S/E/W, X or Y?
  • Guess the Population of city X.

Enjoy it, and let me know what you think! Here’s the Android Market listing.

Playing with the Freeduino

I finally got around to doing something I’ve wanted to do a long time. 2 years ago I got a Freeduino 1.20 kit as a present from my friend and colleague Andreas. This Christmas I got a soldering station, so nothing stood in my way to micro-controller heaven was free!

Although I have no previous soldering experience (apart from taking apart my Canon 300D to replace the shutter mechanism), I found some great video tutorials and all went smoothly. I didn’t even need to re-do any soldering!

Here are some pics from the process:

Since I don’t have any components (yet) to build something, I’m just blinking the LEDs. Here’s the first program I wrote. You enter a digit from the computer keyboard and it will blink the LED #13 that many times.

void setup()  {
  pinMode(13, OUTPUT);

void loop()  {

  while (Serial.available() > 0)
    int cmd = Serial.read();
    int digit = cmd - '0';
    for (int i = 0; i < digit; i++) {
      digitalWrite(13, HIGH);
      digitalWrite(13, LOW);

Next up, this cool project! Though I’ll try to do it with IR instead of Laser, cause I’m having trouble finding suitable (as in decently priced) Laser components over here.

Detecting memory allocations with Android ddms

To detect memory allocations you use the ddms tool, which is to be found in your Android SDK directory, under /tools. Start ddms by running:

I sometimes get the following error when ddms starts:

Could not open Selected VM debug port (8700). Make sure you do not have another instance of DDMS or of the eclipse plugin running. If it’s being used by something else, choose a new port number in the preferences. Continue reading

Managing Memory when working with Bitmaps

One of the (very few) errors I had with Jumping Jack was an OutOfMemoryError that happened if you went back and forth from the game to the main screen a few times. On  my phone, an HTC Hero, it happened after doing this about 8-9 times, on a friend’s Motorola Milestone/Droid 2 I could do the same 50 times without it happening.

The OutOfMemory always occurred when loading the large background bitmap. The strange thing about it was that ddms only showed around 3 MB of heap memory being allocated, and as you may know, the limit for a process on Android is 16 MB of heap.

Digging deeper (aka. Googling) I found out that the memory for bitmaps is allocated natively and not as part of the heap, and that the 16 MB limit includes heap and non-heap memory. So that’s one elucidated mystery.

The next thing to do was a memory profiling session, to find out where I was leaking the bitmaps. Well, surprise surprise, it turned out I wasn’t! After more research, it turns out that deallocating non-heap memory is a rather difficult task for the Android GC, and that it actually takes two runs of the GC to clear-out things such as memory used by bitmaps (see the 2nd link at the end of the article).  The author recommended constructs such as:

try {
} catch (OutOfMemoryError oome) {

as well as giving the GC a helping hand now and then by explicitly calling System.gc().

This didn’t help much either, but on further reading I found out there’s a method called recycle() that you can call on a Bitmap, and which frees the memory used for storing the pixel data for it. So this finally solved my problem – I’m now calling recycle on my bitmaps when my activity gets destroyed – no more OOMs.

Relevant links: