Real Android apps leveraging db4o persistence engine (Part 1)

This the first delivery in a series of articles targeted at showing developers how db4o (an open source database that leverages today's object-oriented languages, systems, and mindset) is being used in several Android projects to avoid all the pitfalls and hassles of object-relational mapping while benefiting from an elegant and straight forward way to evolve a domain model which, in the end, translates into faster, easier upgrades for users.

There are many benefits to using an object database like db4o, including easier code maintenance, and the ability to create applications based on more complex data models. Unlike in rigid, predefined SQL tables, you can store dynamic, free-form data, which can be changed or amended any time. In addition, db4o allows for data replication, another missing element in Android's software stack.

Let's take a look at the code in these projects to learn how developers leverage object database technology on their apps and also use the opportunity to introduce key concepts about db4o. Let's start with project DyCaPo.

DyCaPo stands for “Dynamic Car Pooling”, a system that facilitates the ability of drivers and passengers to make one-time ride matches close to their departure time, with sufficient convenience and flexibility to be used on a daily basis. The project is the result of research activities on the adoption of a FREE/OPEN Dynamic Carpooling system in the province of Trento, Italy.

Riccardo Buttarelli, chose db4o as the persistence engine in the client application for the DyCaPo Service running on Android OS (aka dycadroid). If you check dycadroid's db4o configuration:

private static Configuration configure(){

	dbConfiguration = Db4o.newConfiguration();

	dbConfiguration.objectClass(Trip.class).objectField(Trip.ID).indexed(true);
	dbConfiguration.objectClass(Trip.class).cascadeOnUpdate(true);
	dbConfiguration.objectClass(Trip.class).cascadeOnDelete(true);
	dbConfiguration.objectClass(Location.class).objectField(Location.GEORSSPNT).indexed(true);
	dbConfiguration.objectClass(Location.class).cascadeOnDelete(true);
	dbConfiguration.objectClass(Location.class).cascadeOnUpdate(true);
	dbConfiguration.objectClass(Person.class).objectField(Person.USERNAME).indexed(true);
	dbConfiguration.objectClass(Person.class).cascadeOnUpdate(true);
	dbConfiguration.objectClass(Person.class).cascadeOnDelete(true);
	//[...]
	dbConfiguration.objectClass(ActiveTrip.class).objectField(ActiveTrip.ID).indexed(true);
	dbConfiguration.objectClass(ActiveTrip.class).cascadeOnUpdate(true);
	dbConfiguration.objectClass(ActiveTrip.class).cascadeOnDelete(true);
	dbConfiguration.objectClass(Route.class).cascadeOnUpdate(true);
	dbConfiguration.objectClass(Route.class).cascadeOnDelete(true);
	dbConfiguration.lockDatabaseFile(false);
	dbConfiguration.messageLevel(2);

	return dbConfiguration;
}

dbConfiguration.objectClass(ActiveTrip.class).cascadeOnDelete(true);

dbConfiguration.objectClass(ActiveTrip.class).cascadeOnUpdate(true);

dbConfiguration.objectClass(ActiveTrip.class).objectField(ActiveTrip.ID).indexed(true);

dbConfiguration.objectClass(ActiveTrip.class).cascadeOnActivate(true);

dbConfiguration.lockDatabaseFile(false);

public static void saveActiveTrip (ActiveTrip trip){
	Log.d(TAG, "saving ActiveTrip from trip");
        ObjectContainer db = DBProvider.getDatabase();
        //[...]
        db.store(trip);
        db.commit();
}

 Similarly when you want to delete an object from the database you also interact with a db4o object container but this time it's delete() that you must use. Same rules apply with regards to object identity: in order for delete to work you must have stored or fetched the object passed as parameter during the same transaction otherwise db4o won’t be able to tell that the object belongs to the database and the operation will be ineffective. The delete operation applies to the passed object only and does not delete the siblings except if you configured cascaded deletes (see above).

How about querying? Querying with db4o can be as easy as issuing one line of code. You have the choice of 3 different query mechanisms:

1. Native Queries: refactorable query interface that is very close to the language. The queries are optimized and converted to SODA queries behind the curtains. In db4o for .NET a LINQ provider is also provided and is the preferred method for querying. Since Dalvik (Android VM) uses it’s own binary format db4o’s native query optimizer won’t work during runtime. If you want to optimize NQs on Android you’ll have to use db4o’s build time native query enhancer.
2. SODA Queries: low level and powerful graph based query system where you basically build a query tree and pass it to db4o for execution.
3. Query by Example: useful for simple queries where you pass a prototype object that will serve as an example to find similar objects. Uses reflection to analyze the passed prototype object and build the query.

public static boolean deletePrefs(){
	try{
		ObjectContainer db = DBProvider.getDatabase();
		ObjectSet prefs = db.queryByExample(new Preferences());
		db.delete(prefs);
		db.commit();
		return true;
        }catch (Exception e){
		return false;
        }
}

db.queryByExample(new Preferences());

db.queryByExample(new Preferences("trip", null, null));