ORMDroid: Bugfixes + Sample App = Happiness!

So a few people have taken a look at ORMDroid since my previous blogs, and the feedback I’m getting most often is along the lines of “Sure, there’s some simple example snippets, but I want a complete, compilable, runnable example!” With this in mind, I’ve thrown together a very basic Android app that uses ORMDroid as it’s persistence framework. Like ORMDroid itself, it’s only in SVN for the moment, but you can browse the code online in the Google Code repository (Edit: Moved to Github), or check it out to build locally:

# git clone https://github.com/roscopeco/ormdroid-example.git

The sample app is a very simple address-book-type app that has a list of people and departments, with each person belonging to a department. It supports the basic CRUD operations, and gives a basic working example of ORMDroid in action.

A few things to note about the sample app:

• It’s not pretty – It’s targeted at API 8 (ORMDroid’s minimum API level) and doesn’t have any kind of fancy UI, in order to keep the code simple. In fact, the UI is singularly awful (especially on newer devices), but that’s not the point!
• It’s not clever – It just shows ORMDroid in use – it doesn’t necessarily exemplify best practices, and it has almost zero error handling. Over time it will be updated to at least check the best-practice box.
• But it’s a start! If nothing else, it gives a template project off which you can base your own.

The second point above probably requires a bit of expansion. We all know that to make robust apps we need to be making reasonable checks for unexpected conditions, so we’ll just gloss over the error-handling aspect. But in terms of best practices, the sample app does all kinds of evil things, like blithely loading arbitrary object graphs into ArrayAdapters. On the UI thread no less. This is obviously not the kind of behaviour we want to endorse.

In fact, the whole point here is clarity – to allow you to see exactly what’s going on in the code with the minimum of fuss and boilerplate framework code. We’re trying to make it easy for you to look at a method and see exactly where the ORMDroid calls are happening, without having to wade through any number of AsyncTasks, adapters, and all that other stuff.

In the future, there will be more sample code (maybe as extensions to the current sample, or maybe as additional samples) that will serve to show how things should be done. For now though, take this code more as an example simply that things can be done.

A few bugfixes

While putting together the sample app, I found a few bugs in ORMDroid that are now fixed in SVN. If you’ve tried ORMDroid and experienced any of the following issues, you should grab a fresh copy:

• Problems with models with only one field.
• Problems when using ORMDroidApplication as your main Application class.
• Problems with debugging SQL executed from EntityMapping.
• Problems with executeMulti not ensuring the schema existed.
• Problems with Query operators (lt, gt, and, or, etc).

Of course, if you’ve been experienced issues other than these, then you should get in touch and let us know!