Real Android apps leveraging db4o persistence engine (Part 2) | Architects Zone
Real Android apps leveraging db4o persistence engine (Part 2)
11.30.2010
| 4329 views |
Tweet
inShare0
Tweet
0
inShare
submit to reddit
This the second 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 concise 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.
We'll 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.
On the first article in the series we reviewed some aspects of project DyCaPo, a system that facilitates the ability of drivers and passengers to make one-time ride matches close to their departure time. This time we'll take a look at QuiteSleep, an Android project by César Valiente which is powered by db4o and is both open source and available in the Android market.
QuiteSleep's main task is to silence calls from contacts that have been previously blocked for a given time frame. Once the rejected call is finished QuiteSleep will restore the phone to it's normal operation state (restoring previous volume and vibration settings). Additionally, the app allows you to send a notification to blocked callers via e-mail or SMS.
According to César adding db4o to the project was straight forward: you just add the db4o jar file as any other external library in Eclipse (even for an Android project). Once this is done the full functionality of the db4o database is available to the Android application. During development the db4o version used in the project was db4o-7.12.132.14217. When you download db4o for Java you'll see that there are quite a bunch of jar files. This is because (starting with version 7.7) db4o was splitted so you can add exactly what you need in your project and decrease the library's footprint. If you choose the jar file where the name ends iwith "-all.jar" you'll be addding a version that has everything in it (no other db4o related jar files will be necessary).
In QuiteSleep db4o runs in embedded client/server mode which is a sort of an hybrid between a pure embedded option and networked C/S. When db4o acts as embedded server all communications are internal and fast (no networking takes place) but, as opposed to the simple embedded mode, many local clients can't connect to the database at the same time (ie. different clients can start different transactions on the db). In this applications the server is exposed as a singleton and one or more clients connect to it.
Database Server
The database server is configured following these steps:
1. Server configuration includes activation depth, permissions to allow database version updates, database file name and path, etc.
view source
print?
01. /**
02. * This object is for get only one Singleton object and create ONLY in of
03. * this class mode.
04. */
05.private static ServerDDBB SINGLETON = null;
06.
07./**
08. * * This object is the server DDBB file properly said
09. */
10.private static ObjectServer server = null;
11.
12. private ServerDDBB() {
13. try {
14. if (QSLog.DEBUG_I)
15. QSLog.i(CLASS_NAME, "Before to open the DDBB");
16. ServerConfiguration configuration = Db4oClientServer
17. .newServerConfiguration();
18. configuration.common().allowVersionUpdates(true);
19. configuration.common().activationDepth(DEEP);
20. server = Db4oClientServer.openServer(configuration,
21. getDDBBFile(DDBB_FILE), 0);
22. if (server == null)
23. if (QSLog.DEBUG_W)
24. QSLog.w(CLASS_NAME, "Server Null!!!!");
25. } catch (Exception e) {
26. if (QSLog.DEBUG_E)
27. QSLog.e(CLASS_NAME, ExceptionUtils.exceptionTraceToString(e
28. .toString(), e.getStackTrace()));
29. }
30. }
2. The sole instance of the database server is created here when receiving the first database client request. Once created the server instance is accessed as a singleton and will take care of new client requests according to the application's needs.