Quick tips from the dance floor from a Java specialist, enterprise developer, and mobile technology enthusiast.
Introducing Android migrations
Have you ever worked with Rails’ migrations? They make database changes a breeze, don’t they? While every software release doesn’t necessarily involve a migration, when one does happen to make use of one, I’m always pleased on how easily things work out. Whether it’s to add new data or alter existing data structures, Rails migrations make evolving a datastore (be it an RDMBS or NoSQL one like MongoDB) painless.
When I recently found myself altering the data structure of a SQLite database for one of my Android apps, I found myself wishing there was some similar migration mechanism for Android as there is in Rails. Alas, I could fine none, so I did what any other developer would do: I wrote one.
Droid Migrate is a simple command line framework that generates and runs database migrations for your Android apps that use SQLite. A migration is encapsulated by a DBVersion class that contains an up and down method. The up method is called for an upgrade and down for a rollback. What those methods do is entirely up to you.
In addition, Droid Migrate generates a DatabaseHelper class through which you obtain underlying connections to a SQLite instance – this is the canonical way to interact with SQLite in an Android app anyway, but with Droid Migrate, you get a specially enhanced DatabaseHelper that determines which version of a target database instance is the most current and runs the appropriate migrations to bring the database to that version.
Thus, with your newly minted DatabaseHelper class, you can still interact with your app’s database like you would normally, however, by using this class, all migrations are handled for you. Allow me to demonstrate.
I’ve created a simple app that doesn’t interact with any database at this point – it simply creates a ListView that is intended to hold a list of records for viewing. You can find this app on Github if you’d like to follow along. Nevertheless, the app’s main Activity is shown below.
What I’d like to do is add the ability to interact with a SQLite database; plus, I’d like to be able to evolve the data model on subsequent releases. This is where Droid Migrate shines.
After I’ve installed Droid Migrate (simply clone or download the code, build it, and put it into your PATH and create new environment variable dubbed DROID_MIGRATE_HOME), I can initialize my app to use Droid Migrate by opening up a terminal in the root of my app and typing:
The -d flag specifies the name of my desired database. I can optionally provide a package name via the -p flag if I’d like my newly generated classes in a separate package from my main app.
If you take a look at your app’s code, you should notice a number of new things. First, you’ll see two new classes and a new jar file. The classes are the aforementioned DatabaseHelper and a class dubbed DBVersion1. The newly added jar file in your app’s libs folder contains a few classes that correspond to Droid Migrate’s runtime dependencies – this jar is extremely compact at 4KB.
This class extends Droid Migrate’s MigrationsDatabaseHelper, which ultimately extends Android’s SQLiteOpenHelper so as I mentioned earlier, you’ve got everything you need to interact with SQLite at your fingertips via DatabaseHelper. If you look closely, you’ll see that this class makes use of a specialized XML file (that is ultimately generated into your R class).
Take a look in the res/values folder and open up the newly created migrations.xml file. It should look something like this:
