Tag Archives: android

About a year ago I wrote this entry about how to get the Android DDMS tool to run in Snow Leopard with a 64bit JVM.

Recently Android released a new platform so I downloaded it, as well as the latest cut of development tools. In this new release there is now native support for running DDMS and other tools in a 64bit JVM. If you followed the instructions in the above entry you will now notice that you get an error with a stack trace similar to this:

This is because the tools don't know which of the SWT classes to use, now that it has two in the class path. To sort this out you need to remove the environment variable ANDROID_SWT. Then the tools will automatically use the default 64bit libraries shipped with Android.

My last entry walked through the Android application for the C2DM PoC. This one will look closer at the server side.

The web server is written in Python and sits on top of the tornado framework. To get started you will first need to check it out from github.

Then there are two things that needs changing for the serve to run. First of, tornado is included as a git sub module. In order to get the tornado server you need to run the below commands, when in the project folder, in the terminal:

This will pull down tornado from their github repository.

Secondly you will need to change the following two lines (lines 36 and 37) of code in c2dm/c2dm_service_facade.py:

Replace the Google account with the account you have registered to use with C2DM and the password with the password for said account.

You should now be ready to go. To launch the server on port 8888 execute the following terminal command:

There isn't much more to it. As I have said before not all requirements for C2DM is met by this application but it will work as a prof of concept.


To continue from my previous post, Google Cloud to device messaging for Android, I will walk through how to build and install the Android application.

First of all you will have to sign up for access to the service. You can do this from Googles sign-up page.

You will then have to enter the Google account id into the Constants class where you will find a constant called named C2DM_APPLICATION_SERVER_ID.

The application is using the Maven build system, utilising the maven-android plugin. This makes it very easy to build and install as long as you have Maven installed. You will need to connect your Android 2.2 device or start the emulator, then issue the following command in your shell:

For the device side this is pretty much it. When you have set up your server you can go ahead and start the application. You will be presented with a button which you click to register for receiving messages. When you then use the server to send a message you will see this being printed to the log.

1 Comment

I have been trying out Cloud to Device Messaging (C2DM). It is a technology from Google that makes it possible to send small messages to an Android Devices running Froyo, the latest Android 2.2 release with the Google API's enabled. The application is a very simple prof of concept that illustrates how the technology can be used. It is however not a full implementation and it is missing some required functions.

The PoC is composed by two different sub-systems, an Android application and a web application server. The servers is written in Python and is leveraging Tornado.

The system supports the message sequences depicted in the diagrams below:

Register a device for C2DM:
Register a device for C2DM

Sending a message to device:
Sending a message to device

In the two coming posts I will walk through how each of the sub-systems (device application and web server) works. If you are aching to get your hands on the code you will find it on github: Android application, Web server.

You will find the device side introduction here and the server side introduction here.


Yesterday I went to a breakfast seminar at Jayway's office here in Malmö. Hugo Josefson and Renas Reda showed us a new way to write tests for Android called Robotium.

The framework aims to remove the pain of writing traditional Android instrumentation tests. When demonstrated it is striking how easy it is to create UI tests using Robotium.

Hugo showed us an example test case written using normal Android instrumentation. He then proceeded to show a similar test written using Robotium. The Robotium test was about a tenth of the amount of code required to create a traditional Android test. It also removes the need to have any awareness of the underlying application being tested. This makes the framework useful both as a very powerful QA tool and for creating up front acceptance tests.

Robotium is also fully integrated with Maven using Maven for Android. This makes it easy to get up and running and to automate. It also makes it easy to work in other IDEs then Eclipse.

The one thing I missed was influence of BDD. I almost exclusively use the given-when-then format when I write tests. I find that it helps increase readability. It also helps me staying focused on the domain I work with. This is because it is closer to how the customer expresses them self when discussing features.

I have started to sketch on how the main class, Solo, would look given some given-when-then syntactical sugar. The Robotium source code is on GitHub so I forked it. Feel free to check out my progress. The changes are added in the same manner Mockito have added BDD, by extending the main framework class. In Robotiums case this means there is now a BDDSolo class that inherits from Solo. I will add methods to it as and when I have time.

Please come with feedback and ideas. What is currently there have been done from a very limited grasp of how Robotium works. I hope that I will get a chance to use it soon so I can add some more substance to it. In the mean time I would like to get others feedback. Both on Robotium specific things and on general phrasing.

Me and Hugo talked about how to design some lower level APIs for Robotium, and there will be a discussion on the Robotium Google group at some point. But in the mean time, I like to discuss APIs by actually designing them and GitHub makes it easy to maintain such a discussion in code. So feel free to join in.