Monthly Archives: October 2009

Please note that this entry has been revisited. The update is available here.

I just had the pleasure to launch the debugging tool for Android called Dalvik Debug Monitor Service. It is a tool that allows you to connect to the different VM's running on an Android emulator or phone. On OS X Snow Leopard this was unfortunately a bit more involved then I would have liked.

Not using the Eclipse IDE I was going to start this from the terminal. The Android SDK 1.5 through back an exception that I could not be bother to decipher so I decided to switch to SDK 1.6 to see how that worked. This time I was first of all requested to export a new shell variable called ANDROID_SWT so that I could create the AVD to use. I pointed this to $ANDROID_HOME/tools/lib where I found a swt.jar file. This worked and my AVD was created and started.

When I then tried to launch the DDMS tool it complained that it could not run a 32 bit SWT implementation on a 64 bit VM. OK, so I search around on the internet to find a 64 bit version of SWT. I found the SWT home page and there I found the download of the latest stable release of SWT for OS X. Great! Downloaded and installed and exported as ANDROID_SWT I got the same error! SWT does not yet support 64 bit OS X platforms as stable!

But I was in luck. I happen to have an install of the latest Eclipse IDE. This happens to be the last of the three OS X options on their download page (as a note of warning Eclipse is quite big). In here you will find the SWT plugin. This is the file you will need to get DDMS to work, I.E where the ANDROID_SWT variable should point. So if you don't want to move files around you can just point the ANDROID_SWT variable to $ECLIPSE_ROOT/plugins. If you want to copy the file to another location I copied the two SWT jar files org.eclipse.swt_3.5.1.v3555a.jar and org.eclipse.swt.cocoa.macosx.x86_64_3.5.1.v3555a.jar.

I would assume that you can download the development source from the SWT teams SVN and build it your self but I found it easier to just link to the Eclipse provided one.

I have been woking with an Android application for a week and a bit. It's an interesting experience. The API's are easy to use and it feels like a platform that is highly productive. Especially if you work in Eclipse.

On the flip side of this comes the badly documented ANT tasks. I have not been able to find any documentation at all on how to use them! This have resulted in having to use the shell commands that ships with the Android SDK. This is all but ideal however since this level of detail could have been hidden away, and seems to be hidden away, in the ant tasks that also ships with the SDK.

I have been greatly help in my endeavor to automate the build and deploy to the emulator by reading the blog postings done by Gabor Paller at his blog http://mylifewithandroid.blogspot.com/. His early posts that details how to create ANT scripts and work with Android in a shell environment were a true life saver.

The result is in any case an ant script that will build and deploy all source files onto a running AVD. There are also targets for redeployment and uninstall of the application. You can download it from here.

If anyone have documentation on how to use the ANT tasks for android or if you know of other ANT tasks that will do the same kind of job please post a comment.

I don't seem capable to remember some of the most basic things in Java at times. I guess it's because I do them so rarely that I have time to forget until next time.The other day it was how to define the path for the getResourceAsStream() method. This time I'm going to blog it so I can find the instructions next time I end up not remembering.

I need to read the image named image.jpg located at the absolute build path /Users/tomasmalmsten/code/myproject/src/main/resources/image.jpg. I am using Maven2 so the final location before packaging is /Users/tomasmalmsten/code/myproject/target/classes/image.jpg. And when it's been packaged it will be in the classes/image.jpg location of the jar file. What I can't remember is how to create the path so that it can be found by the class loader when using getResourceAsStream().

The trick is to use a / in the beginning of the search path. This denotes that the class loader should start looking at the root, which in the case with image.jpg is where it is. So the path for image.jpg is /image.jpg.

During spring I had the pleasure to work with Brjörn Granvik from Jayway as a mentor in development process. This was a very enlightening experience. I had previously defined a process for the team to work with but it lacked in some areas although no-one was able to pinpoint were the process was failing.

We found it very difficult to control the project and the time line. This had as a nock on effect that we lost credibility with our customer. And every effort we made to improve our estimates failed.

We were creating new functionality that would run on, and integrate to, the worst software I have ever seen (and this is not just my opinion). It would be easy for me to blame all the slips on the difficulty to work with the underlying application code but this would be a cop-out and a lost opportunity to learn from my mistakes.

When Björn came onboard he introduced planning poker as a way to measure the effort required to complete user stories. This is a great aid since it creates a tangible and useful abstraction that is not bound to time. The principles are simple and can be found here

Binding estimates to points rather then time improves the process and controllability of the project. The most striking benefits to me are the following (I will dig into each below):

  • It improves the accuracy of time estimates over the lifetime of the project.
  • It helps manage expectations that the customer has of the project delivery.
  • It empowers the team members and helps create an upward spiral building on success upon success.

When a team start working on a project, or new members join the team, tasks takes longer to complete. When a team have been working steady with a project for a period of time the team will complete the same tasks faster. This is due to what could be regarded as the teams fitness (as in physical fitness). It is therefor waisted effort to estimate tasks in how much time each will take.

First of all, as the team starts the project they will not have any awareness of the level of hidden difficulty in a task. This is only discovered through working with the project.

Second, if the team would accurately estimate the time needed to complete the task for the first couple of months this estimate will no longer be accurate a few month into the project since the teams fitness will have increased by then. Also the technical environment for the project will most likely have changed radically.

Using an effort estimate that is not based on time enables the team to measure project velocity. This is then used to create a time estimate that will, given that the team is kept intact, improve over time. This has serves all three of the above benefits.

Since the projects is not estimated in time the first real estimate of time will happen after the first sprint/iteration of development. This estimate is based on real experience, not guesses. We know that it will change. The next iteration may show that it will take longer. But the next three to four iteration will show that it will be shorter.

The customer is given the initial estimate and knows that this is a worst case estimate. Looking at how SCRUM projects velocity tends to develop the speed will increase.

Since the team is presented with a long timeline where they work through story points in a stead but slow churn it is a wonderful feeling to se this passe increase as each iteration is completed. This empowers the team immensely since it is a feeling of control and and success.

This fall I will again define a process for my team. It's a new team this time and a new company. And there are other needs. But one thing is sure. I will learn from my previous mistakes and I will introduce planning poker as the means to estimate stories.