Over a million developers have joined DZone.

A Survey of Object-Relational Mapping (ORM) Libraries for Android and iOS

An article from DZone's brand-new 2016 Guide to Data Persistence.

Build fast, scale big with MongoDB Atlas, a hosted service for the leading NoSQL database. Try it now! Brought to you in partnership with MongoDB.

This article is featured in the new DZone Guide to Data Persistence. Get your free copy for more insightful articles, industry statistics, and more. 

How do you persist data in a mobile application? Mobile platforms offer a variety of storage options: shared preferences, files, relational databases, network servers, and others. The choice of an appropriate storage option is not straightforward. Even if you decide to use a relational database, you still have to decide which API to use. In this article, we'll do a survey of available relational database libraries for Android and iOS.

SQLite On Android and iOS

SQLite is available and natively supported by all Android devices. It is also deployed on every iOS device. However, the choice of SQLite as a persistence layer for iOS is certainly a non-standard decision; the suggested choice is CoreData. In a typical configuration, CoreData is backed up by an SQLite database, but there is no direct access to SQLite instance. Though when you develop the same application for Android and iOS in parallel, using the same persistence layer allows you to have similar software architecture on both platforms.

The Benefits of Using an ORM

An Object-Relational Mapping (ORM) is a software library which – generally speaking – knows how to translate table rows into objects and vice versa. The discussion whether you can write a really good ORM is as old as ORMs themselves. In spite of the controversies, ORMs are widely used in virtually all object-oriented languages.

What are the benefits of ORMs? First, they offer an object-oriented model of the database. The developers of an object-oriented language do not have shift paradigms each time they access the database, making their job easier. While a query builder is not necessarily part of an ORM library, most mature ORMs come with an SQL query builder. ORMs often help manage the database creation process and database schema changes.

ORM Patterns

Two of the most common patterns in ORM implementations are Active Record and Data Access Object. In the Active Record pattern, each table is represented as a class, while table rows are translated to the object of the corresponding class. The objects know how to persist themselves in a database.

In the Data Access Object pattern, database access is delegated to dedicated Data Access Objects (or DAOs). DAOs know how to persist each object and how to construct objects from the database.

ORM Libraries in Android

Only four years ago, there were hardly any ORM libraries for Android. Nowadays, the number of ORM libraries for Android is constantly growing.

Since Java is the language you use to program an Android application, it seems natural to consider porting an existing Java ORM library to Android. The main problem with such a port is that there is still no official JDBC driver for Android and SQLite. (Some third-party JDBC drivers are available.) Moreover, mobile devices’ limited memory and processor capabilities makes porting the all-powerful Hibernate infeasible.

GreenDAO is an open-source ORM library for Android developed by the German company greenrobot. First released in 2012 and still actively maintained, it is one of the most popular ORMs for Android. As its name suggests, GreenDAO uses the Data Access Object pattern. The entity classes are generated with a code generator in a separate Java project. With this approach,

GreenDAO avoids the runtime processing of annotations (extremely time-consuming on mobile devices). This library has the reputation of being the fastest Android ORM. It has a fluent interface query builder; it’s also thread-safe and supports transactions. In GreenDAO, database tables are created automatically but migrations between database schema versions have to be handled manually. An interesting feature of this ORM is its asynchronous API (still in the beta phase).

ORMLite is an open-source Java ORM which supports relational database engines like MySQL, PostgreSQL, SQL Server, SQLite (via JDBC), and others. It has been ported to Android with the help of low-level SQLite API calls. It was first released in 2011, making it one of the first popular Android ORMs. The latest activity in its Github repository was mid-2015.

Like GreenDAO, ORMLite follows the Data Access Object pattern, though the entity classes have to be coded manually. Their database representation comes with annotations; these are processed at runtime, which makes the library quite slow. The database tables have to be created manually, but there is a utility class to help things along. Schema migrations must be handled manually with ALTER statements. ORMLite has a fluent interface query builder.

DBFlow, first released in 2014, is one of the newest ORM libraries for Android, a And it’s gaining in popularity. DBFlow uses Active Record patterns and database tables are created automatically. The entity classes are coded manually and are set up with annotations. DBFlow supports migrations and usage of multiple databases; it also offers functions like lazy loading, caching, observable models, and more. Its fluent interface query builder is powerful and supports JOINs and other advanced features.

ActiveAndroid. As the name suggests, ActiveAndroid uses the Active Record pattern. In fact, ActiveAndroid was the first Android ORM to use that pattern; however, it is no longer maintained. Its author, Michael Pardo, recommends switching to his new Android ORM, Ollie. (Ollie is not very popular yet)

ActiveAndroid requires you to hand-code entity classes. They inherit from a Model class, and table and column properties are set using annotations. Database tables are created automatically. ActiveAndroid supports very simple migrations: new tables are added automatically, but changes in the existing tables have to be handled with a manually-created SQL script. ActiveAndroid has no real query builder.

SugarORM is another Android ORM that uses the Active Record pattern. Released in 2012, it is still regularly maintained. The entity classes have to be written manually; they inherit from the SugarRecord class or are set up with annotations. The database tables are created automatically by the ORM. SugarORM knows how to handle migrations, but actual SQL scripts have to be provided. This ORM has a fluent interface query builder.

Database Access Libraries in iOS

Since the standard persistence layer for the iOS platform is CoreData, there aren't many ORM (or even database) libraries for iOS. SQLite is written in C, so you can use its native API directly in an Objective-C application in iOS.

FMDB is the most popular still actively-maintained SQLite library for iOS. Unlike all other libraries mentioned in this article, this is not an ORM library. FMDB is a wrapper over an SQLite API. It provides some convenient functions. You can only execute raw queries — there is no query builder - but you can use binding syntax to prevent from SQL injection. There are many

other libraries built on top of FMDB. One example (no longer maintained) is EGODatabase, a thread-safe version of FMDB.

DBAccess is a free, albeit closed-source, ORM library for iOS. It was first released in 2014, and it is still actively maintained. DBAccess uses the Active Record pattern and it has a fluent interface query builder. It is thread-safe. Entity classes are coded manually by the developer, and database properties are set up using the appropriate @dynamic and @synthesize properties. DBAccess automatically creates the database tables.

DBAccess also offers more advanced features like JOINs or asynchronous queries. Its most interesting feature are events. These can register asynchronous blocks of code, which are executed after database events (i.e. inserts, updates or deletes).

Database Libraries for Both Android and iOS

Surprisingly, there aren't many ORM libraries which support both Android and iOS. One example of such a library is the newly-released Vertabelo Mobile ORM. This library uses the Data Access Object pattern. It has a unique approach to generating entity classes. You start with the database model in Vertabelo, a visual database modeling tool. The entity classes, DAO classes, and other runtime classes are generated from the diagram and downloaded as a zip file. The modeling tool lets you generate the SQL script file, which has to be run against the database. Vertabelo Mobile ORM has a fluent interface query builder.

The newest alternative to ORM libraries for Android and iOS rapidly gaining popularity, is Realm. Realm is a mobile database, meant as a replacement for SQLite and CoreData. It is based on Realm Core, its own non-relational storage engine. Realm provides database access libraries for Android, Objective-C and Swift. The libraries are free and open-source; the storage engine is currently closed-source, but the authors plan to open-source it.

Even though non-relational storage engines are an important part of the storage engines landscape for mobile platforms, there is a lot going on in the world of relational database access libraries. It is worth keeping an eye on both sides of this coin.

"For more insights on data tools and solutions, persisting data on mobile devices, and choosing a DBaaS, get your free copy of the new DZone Guide to Data Persistence!"

Now it's easier than ever to get started with MongoDB, the database that allows startups and enterprises alike to rapidly build planet-scale apps. Introducing MongoDB Atlas, the official hosted service for the database on AWS. Try it now! Brought to you in partnership with MongoDB.

data persistence,orm,android,ios

The best of DZone straight to your inbox.

Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}