Huy's blag

During the first four weeks of March 2011, 6 students in two groups each (totaling 12 students) had to implement an application for Android devices. The application was supposed to be able to record information relevant to the OpenStreetMap project, similar to what OSMtracker is capable of, technically. This project was particularly interesting, because the lecturer decided to give agile software development a chance. He never tried it himself, though. That's how interesting projects start!

Scrum!

I will not delve too much into Scrum here, because said four weeks were the first four weeks of Scrum of my life. It however was a really good decision of the lecturer to go the agile way, for if we had gone the "traditional" way, we probably would have been lost after no more than two weeks. None of us had knowledge on how to develop applications on the Android platform, which also meant that there were quite a few pitfalls out there waiting for us.

There also were a few changes to the requirements halfway through the project, which we could easily adapt to, thanks to agile processes. Such changes would most likely not have been viable if we had been "traditional". Getting feedback on progress for both the developers and the product manager also helped a lot when the eventual goal was not really that clear. After all, "The application is supposed to be able to record information relevant to the OpenStreetMap project" actually is not even remotely concise.

Implementation

Our group did make some very decent progress during the four weeks we had. In fact, it were not even four weeks, but just 16 days, because work times were from Monday to Thursday only, so people could work for their living on the other days. We have run into some of the aforementioned pitfalls, but software development on Android in general seems to be not too bad, as long as your Java is on a semi-decent level. It also helps a lot that most questions you might have have been posted on sites like StackOverflow already, so you usually will not have to spend days trying to solve a single problem.

One of the requirements of the product manager was that the application should be available for as many devices as possible, which essentially means that it should run on Android 1.5 (API level 3) and higher. We settled on Android 1.6 (API level 4) and higher, because it made life a lot easier when it was about the GUI.

The most difficult issue we had to solve probably was recording media files. Taking pictures was as easy as calling an intent for MediaStore.ACTION_IMAGE_CAPTURE, but the intent for video recording (MediaStore.ACTION_VIDEO_CAPTURE) did not work properly on some devices and did not work at all for some other ones. We had to resort to implementing our own video recording activity using the Android MediaRecorder class, but we could not really make it work for all devices either. At first, everything worked on all HTC devices running stock HTC Sense ROMs, but it would not work on a Samsung Galaxy S, a Motorola Milestone 2 or my HTC Desire Z running GingerVillain 1.5. Then, it did work on all HTC devices (including mine), but

Camera.Parameters p = camera.getParameters();
p.setPreviewSize(320, 240);
p.setPreviewFormat(PixelFormat.JPEG);
camera.setParameters(p);

would throw exceptions on the Samsung Galaxy S and the Motorola Milestone 2 still. We ended up not using the Camera class at all, which worked for all devices. Mine does not show anything in the preview surface, until recording actually has been started. ;-(

But apart from that, no really big implementation problems occurred. MapsForge, the map display library we used, would throw exceptions every now and then, but thanks to their maintainer and his patches, many of them have been fixed by now.

About non-implementation things

"Real" documentation (wiki pages etc.) was neglected for most of the time. We had Javadoc comments all over the place, but many of them did not adhere to common Javadoc standards. In fact, during the first week, coding style did not adhere to those, either. But thanks to Checkstyle, bane of all slackers and the auto-formatting functionality Eclipse offers, we got to a common basis on both code style and comment style pretty fast. We did use a Checkstyle configuration that was not as strict as the default one, though.

Another useful tool most definitely was FindBugs. It scans your code for common traps (as well as errors) and shows them with a short description about why something is bad. One trivial error it would unveil is:

public boolean isTracking() {
    // Should return private variable isTracking instead
    return isTracking();
}

Such tools, when used frequently and consequently, do improve code quality by a lot. It also makes it much easier to enforce the same code conventions, as well as comment conventions. When available for the programming language of your choice, you should make use of them!

My role in the project

Apart from being the Checkstyle sheriff, spelling/grammar police officer and translation idiot, I was mostly responsible for data acquisition, both within the application (media files) and outside (e. g. parsing miscellaneous information about OpenStreetMap tags), and other smaller tasks.

Recording media files had to be done in Java, which I haven't ever really learnt before, to be honest, but for parsing the OpenStreetMap wiki, using Java did not really seem intuitive to me. So I used Ruby instead, which, to my surprise, the lecturer did not object to. At least not explicitly. Seeing how he was condoning Ruby (better: non-Java), I wrote a little Ruby script using the geokit gem to send fake GPS data to the Android emulator.

Taking the lead

We slowly, but steadily took the lead in the race against the other group of six during the four weeks. I do not know of the problems they might have encountered -- there might have been some different ones, because they started to use the internal SQLite database very early on --, but being able to virtually walk around on the emulator freely (and very exactly, thanks to geokit, gave us a huge edge. Testing and debugging GPS-related things could be done much easier and much more efficiently that way, because you did not have to walk around outside.

As a nice side effect, it also allowed us to easily show such things on an emulator during mid-sprint presentation sessions. You can use the Android mock location feature to come up with an application to do the same thing on a real device, but writing the Ruby script for the emulator took me half an hour. With my Java skills (or rather the lack thereof), it most likely would have taken me half a day or more, even. I might implement such an application at some time, though...

Lessons learnt

The relevant things I have learnt during the four weeks are not explicitly related to what I have coded, but more about things like code style. Different people do have different opinions about such seemingly trivial things, and when everyone ends up doing it the way they want to, the result will be horribad. As such, I have appreciated Checkstyle, even though it was annoying and tedious at times. I will most certainly have a look at roodi, which is a similar tool for Ruby.

Eclipse also was an interesting thing, at least. I have used RubyMine, an IntelliJ derivate for Ruby, before, but I decided to try and get along with Eclipse, because everyone else in the team was using it and the benefits of having the same environment and IDE by far outweighed my personal preferences for IntelliJ. I'm glad to be back to RubyMine, though. ;-D

It was a fun project while it lasted, but I think none of us wants to see our application again anytime soon. If you however want to take a look at it, you can find it on Google Code.

Thanks a lot to my team. You made those four weeks fly really fast!