On Tuesday 21st of December 2010, I officially launched ReGalAndroid, the follow up of G2Android, aiming at providing G3 and Piwigo support.

This article explains why I decided to create a new project, and also what I did differently for this new Android app.

Why creating a new project ?

First of all, the name of the app (g2android) did not reflect what I wanted it to be: I wanted it not to be specific to a gallery type (G2) but also compatible with G3 and Piwigo.
In the android world, an app is defined by its package name; since I wanted to change from net.dahanne.android.g2android to the new name net.dahanne.android.regalandroid I had to create a new app.
Sure, I could have keep on using the old package name, but it did not make sense, and also I wanted to start refactoring the app modularizing it.

Modularizing an Android app, using maven-android-plugin

In G2Android, one of the things that frustrated me most was the way it was built : it had dependencies on libraries (jars) not part of the android runtime. So I had to include them in a lib directory; adding them to the classpath so that the Android Developer tools knew that G2Android needed them.
Another problem was the modularity of the application : the Gallery2 client API code was mixed with the Android UI code; it could become a nightmare for testing, as for plain Junit test cases, I had to remove the android.jar lib from my classpath (and Android integration testing was not an option as it takes really too long to launch; and does not make sense to test an HTTP client api…)
Starting ReGalAndroid, the first thing I did was modularizing the application :

• one standard jar maven project for the commons classes (Pictures, Albums, etc..) with its regular Junit tests

• one standard jar maven project for each gallery client java api (one for G2 extracted from g2android, and 2 new ones, one for G3 from scratch, and one for Piwigo extracted from Jiwigo, an existing Java Swing client for Piwigo) with their regular Junit tests

• one android maven project with only android related classes, this project heavily depends on the common module and the 3 gallery implementations; this has been possible thanks to the maven android plugin

To ease the process inside Eclipse, you can use Maven Integration for Android Development Tools , it will allow you to launch your Android application from the IDE, just the same as before.

This way, I am now able to test the remote API implementations independently of the main Android app; and also if someone wants to reuse those implementations for any other Java projects, he can just check out those plain java projects.

Logging an android app using slf4j-android

If your Android application depends on plain java projects; those projects certainly do not use Android logging framework.

So if you want to log all your modules in your android app, you can use slf4j : this is meta API where you can choose at compile time which logging API you will use.

For example, in all the logged classes of ReGalAndroid, I’m depending on org.slf4j.Logger and org.slf4j.LoggerFactory , even in the Android module.

But in my maven dependencies; I tell my android module to depend on slf4j-android :

That way, each call to LoggerFactory.getLogger(My.class)  in any of my modules will be wrapped to the android.util.log APIs

Cool thing is, if anyone wants to use any of the remote gallery implementations (G2, G3 or Piwigo client) in its Java app, he will be able to use Log4J or logback, or any other slf4j bridge he wants !

Moving from Google code to GitHub for code hosting

I’m quite satisfied with Google Code hosting; in fact I still use it as a wiki and a bug tracker; the truth, I wanted to become familiar with Git, to test its benefits.

As I was not starting from scratch, I wanted to be able to keep the history of my project

There is an easy way to do so in GitHub : create a new project, and then select ‘Importing a Subversion repo’; but unfortunately, it did not keep track of all my tags; so I chose to go with the manual way.

Export google code svn repo to a local git repo

I use this utility called svn2git, I had to check out from GitHub : svn2git

It is written in Ruby, so you have to make sure you have ruby and rubygems installed.

Then, according to your gems directory, you can run it :

/var/lib/gems/1.8/bin/svn2git https://g2android.googlecode.com/svn/  –verbose

All the svn tags are imported as git tags (git tag to check all the tags are there) but the authors are not imported (« (no author) author not found in authors.txt)

To manually change the authors name, I found the solution reading this post.

From now on, you have a local git repo with all your code  from your SVN (including the tags !) in a local git repo; let’s share this one !

First create a new repo on github (using the web interface), then set your local repo as the origin :

Finally, sync the local and remote , including the tags of the master branch :

And youŕe done migrating from Google code SVN to GitHub !

Migrating your users from a previous android app to a new one

The problem when you’re creating a new android application to replace a previous one, is that the users having the old app installed on their phone will not be notified of the availability of the new one, since the package name of your new application (referenced in your AndroidManifest.xml file) is different :

Then the market you’re using (let’s say Android Market) is not aware of your new application replacing the previous one.

For the particular case of the migration from G2Android to ReGalAndroid, I first, during a month, advertised the new app on Twitter, and on the dedicated G2, G3 and Piwigo forums and websites; so that I could have some early adopters.

Then, in a second step, to accelerate the migration, I updated G2Android, with a new activity, launched by default on startup to tell the user that the application is not maintained anymore and that he should tap on the button to download the new application.
Here is the source code to redirect users from the old android app to the new one

At the time of writing this blog post, here are the statistics reported by Android market about both apps :

It means that the migration is quite slow, since many users still have the old application installed on their phones; I may remove the old app from the market in the next few months to make sure they do not use it anymore (please note that ReGalAndroid is also available via other markets and also via direct download)

The final words

The application is open source and if I receive many issues and functional requirements via the ReGalAndroid bug tracker (and I thank the users for that, it clearly influences the path the application is taking) I would love to see new contributors and committers add some code (see the ReGalAndroid github repository); because this is before all what makes the app