As a promised, I would like to recap a presentation from KrakDroid about OR Mappers on Android platform, which has been shown by Tomek.
Maybe some of you, who read us, don’t know what actually OR Mapper is, so at the beginning, I should make a short description. OR Mapper is programming technique consisting of mapping relational data structures to objects. The mapping is usually carried out by prepared frameworks that allow developers to use a relational database as if it was object-oriented.
Even if this technique has some disadvantages like additional overhead or limited functionality, on the other hand, it has cache, which has a positive impact on a productivity and a developing application can focus on a business logic.
On the market, there you can find many different OR Mappers like androrm, ORM-droid, aBatic ect., but I would like to concentrated only on 3: OrmLite, greenDAO and Mobeelizer and compare them.
greenDAO is a open source project, which is created to help Android dvelopers to work with stored data in SQLite database. greenDAO is mapping Java’s objects to database table. Even though greenDAO is a open source project, greenRobot (the company, which created greenDAO) provides commercial support for special customer requirements. The most important aims of greenDAO are:
- maximum productivity;
- easy to use API;
- highly optimized for Android;
- minimum memory usage.
OrmLite provides some simple, lightweight functionality for persisting Java objects to SQL databases while avoiding the complexity and overhead of more standard ORM packages. It supports a number of SQL databases using JDBC and also supports SQLite with native calls to Android OS database APIs.
Mobeelizer is especially a platform for data synchronization between differ mobile platforms. Currently, it supports the most popular: Android, iOS and Windows Phone7. The main objective of Mobeelizer was to create relatively simple SDK to use in order to save not only data but also technical fields for synchronization. Sources are available on GitHub.
|Adding library to the project||- one greeDAO.jar library,
- size 66KB,
- current version 1.2.0.
|- two ormlite-core.jar (275KB) and ormlite-android (50KB) libraries,
- current version 4.42
|- one library in size 209KB,
- current version 1.6.0.
|Access to database||Access by means of the generated classes Data Access Object one for each entity.||Need to write own Helper’s implementation, access by generic DAO class.||Access by global object DAO, there is no need for further configuration.|
|Creating and updating new entities||- creating new entity: daoObject.insert(newEntity)
- updating entity: daoObject.update(entity).
|- creating new entity: daoObject.create(newEntity);
- updating entity: daoObject.update(entity).
|- creating and updating entity: mobeelizer.getDatabase(entity).|
|Susceptibility to the database structure||- responsibility of the developer;
- need to implement the method onUpgrade() in OpenHelper class.
|- responsibility of the developer;
- need to implement the method onUpgrade() in DatabaseHelper class.
|- the copy of the data are always in a cloud, where Mobeelizer take care of their safety.|
Below, I attached one task which has been shown during the presentation. The task is about finding all employes named Nowak and earning more than 5000zloty.
List<Employee> employees = employeeDao.queryBuilder()) .where(EmployeeDao.Properties.Surname.eq(surname), EmployeeDao.Properties.Salary.gt(minSalary)).list();
List<Employee> employees = database.getEmployeeDao().queryBuilder() .where().eq("surname", surname).and().gt("salary", minSalary).query();
List<Employee> employees = Mobeelizer.getDatabase() .find(Employee.class).add(MobeelizerRestrictions.and( MobeelizerRestrictions.eq("surname", surname), MobeelizerRestrictions.gt("salary", minSalary))).list();
To sum up, if the developing application is light and fast, the best OR Mapper to use is greenDAO, but unfortunately the problem appears when the database is complicated.
For the complicated questions OrmLite is the best in spite of the relatively large size of the library.
So the question arises, why did we create own OR Mapper?
As I wrote at the beginning that one of OR Mappers’ disadvantage is that their functionality is limited. That’s why we have to keep additional metadata related to entities, because it’s a differential synchronization. It means that you can sync only these data, which have been changed from the last synchronization. In order to have whole control over this, we decided to create own OR Mapper.