I am currently involved with a private Android development project, together with Daniel Arenhage. During development I was yet again faced with implementing a database interface for an Android app. I find the work tedious and error prone. What’s worse is th at the same procedure must be repeated in some form on the server-side for many of the entities that are to be stored on both the client and the server. For the project I intended to minimize the amount of time spent on the database integration and instead spent time on the actual business logic of the app.
Therefore, I set out to find an ORM that could do most of the boring DB-interaction. I quickly found several ORMs capable of being used on Android. However, most of them introduce their own annotations, code generation etc. This was something I wanted to avoid since it effectively prevents me from sharing DB-entities between the client and the server if I intend to use a different ORM providers in the client and server. I didn’t want to be forced to choose the same database ORM for the server and client based on the framework we ended up using. The server and client are after all different in many ways and an ORM implementation designed for android may not be suitable for the server because of performance bottlenecks, etc. My thought therefore turned to JPA. JPA should be the ideal for this problem since it provides an implementation independent blueprint of how the database entities are to be specified. This should provide the app with the ability to use the same entities in the android client and in the server backend even though they may not share the database manager implementation or ORM.
Several ORM libraries exists which are capable of running on android, some of listed here: http://www.ninthavenue.com.au/android-orm-jpa. However most of them (it seems all except one) do not implement any part of the JPA specification. OrmLite (http://ormlite.com/) seems to be the best bet, even though it declares to only have partial JPA support. OrmLite primarily provides it’s own annotations, which supports a subset of the features the JPA standard provides. From what I understand, OrmLite maps the supported standard JPA features to a subset of the features that OrmLite supports through its own annotations. Beacuse of this, most JPA annotation features are missing. For example the support for JPA relations seems to be missing and I have not found any way to store arrays of primitives using only JPA annotations with OrmLite. The limited JPA support meant that we in the end was forced to use only primitives and strings in the database entities and avoid relationships managed by JPA. This may not be acceptable for everyone, but for the purpose of our App it was sufficient. The limited JPA support also meant that it made most sense to persist entities using a classical DAO layer instead of persisting entities through an entity manager.
The end result is an application with DAO and database entities shared between server and android client. The source code for the application parts which are shared are located in a separate maven artifact. The build configuration generates a jar for the server, and a another jar including all the transitive dependencies for the android application.
Both server and client thereby share the same database integration and are capable of exchanging entities without any POJO remapping or explicit serialization, such as JSON. Further using the same logging system(http://www.slf4j.org/android/) for both the server and client enables us to have a consistent logging style for the shared entities. When all this is in place the server and client can start to perform the same tasks in the same way. We let this influence how we designed the rest of the application, and in my next blog post talk about a message bus stretching across clients and servers, greatly enhanced by the use of common entity objects.