Selecting an ORM for Android

When you develop an app for Android, sooner or later you will have to answer the question, how you will maintain your data.

Unless you want to mess with flat files, you will most certainly use the standard SQL database mechanism, SQLLite, Android offers. And when you use them, you’ll need a decent ORM.

Manual database access

In the former days of Android, the usual way of working with SQLLite was to write an own ContentProvider, fiddling around with ContentResolver, Uri, manual data mapping, managed SQL queries and so on.

Of course, you can still do that, but since programming for Android is generally pretty ugly, writing an own database layer is even more ugly, and I would not recommend it any more, unless, you really have a reason to.


On W-JAX13, there’s was a talk about recommendable Android libraries, and SugarORM was one of them.

SugarORM is a small and lightweight OR mapper, which allows really easy access to simple database structures. It even offers a mechanism for simple database schema modifications and allowes a very clean data access like the following way:

Book.findById(Book.class, 1);

Nice, isn’t it?

However, if you have a more complex database with more than just text and integer fields, or if you have to implement a database migration, which cannot be done by plain SQL instructions, you are lost, unfortunately.

Since the community around SugarORM is pretty small, it’s not expectable, that it will be production-ready for complex databases. Anything beyond simple database object access will result in writing manual code with limited SQL statements. Retrieving just one or two fields from a table is not possible, and writing more complex database migration scripts is not supported. I for example managed at least to find a hack to bypass the limitations of the database migration, basically by bypassing SugarORM, but finally failed on the fact, that the Timestamp field of one my tables was not correctly read in. The neccessiary work of forking and patching SugarORM wasn’t worth the effort for me, since I then found….


If you take a look, which ORMs in Android are really popular, you can’t bypass greenDAO, an SQLite ORM, which is not only popular since many years, but also designed with performance in mind. It’s no surprise, why some of the top apps on the market, like Pinterest, Airdroid or ICQ uses it.

Although greenDAO is a little more complicated to use, compared with SugarORM, it still offers a very nice database abstraction layer, offers the standard (powerful!) SQLite database migration mechanism without proprietary interfering stuff and does not suffer from bugs like wrong implemented database fields. There’s no timestamp field, but using date is ok, as long, as you’re informed about that. The only minor drawback is, that you have to pass the Context around, which uglifies your code a little bit. But hey, Android is ugly 🙂

A speciality of greenDAO is, that you have a generator, which means, that you don’t have to work with SQL commands, even on creating your database schema. But if you want to use SQL, of course, you still can.

On, there’s a great starters’ tutorial. If you follow it, you will have your database access within a few minutes.

Configuring Eclipse Kepler

By default, Eclipse Kepler comes with a way too large font for the package explorer and a pretty weird tab order.

Fixing both is pretty easy:

1. Setup a file called .gtkrc-eclipse in your home directory with the following contents:

style "eclipse" {
font_name = "Lucida Grande 8"

class "GtkWidget" style "eclipse"

style "gtkcompactextra" {
class "GtkButton" style "gtkcompactextra"
class "GtkToolbar" style "gtkcompactextra"
class "GtkPaned" style "gtkcompactextra"

2. Modify your eclipse start script to use this resource file by prepending it with

GTK2_RC_FILES=$GTK2_RC_FILES:/home/yourname/.gtkrc-eclipse ./eclipse

3. Install the Eclipse CSS editor and modify the appearence according to , especially the part

.MPartStack {
    swt-mru-visible: true;

and restart eclipse