Some thoughts about the new Room library for Android By Google.
In the last Google I/O, Google announced a new architecture components. One of them is Room. Room is an (another) ORM solution for the Android developers. Combining with some other elements Google released (like LiveData, ViewModel, and Lifecycle Listeners)- basic app’s flows should be much simpler.
Indeed- Google did some nice work here. Straightforward tasks like displaying items from DB and update them was a pain, and you had to write a lot of code over and over. Now you can just use those out-of-the-box components. This will save time for developers: you will write less code, and you will have fewer bugs.
When examine those components, I feel most of them bringing new things to the table. But about Room- is there a need for another ORM library?
ORM?
Let’s start from the beginning: For the ones that not familiar with, ORM stands for “Object Relational Mapping”. That’s a prettier way to let the developers works with persistent objects instead or tables rows.
This means that if I want to save all my users data in a database- I need to work with the User object and the ORM layer will handle all the persistency stuff for me. Fun.
Current solutions
This concept is not new, developers used that technique for a long time, and it was natural that Android developers will need this kind of thing too.
Soon enough we got a couple of 3rd libraries to handle it, just look on AndroidArsenal page and understand we’re getting into crowded space here. The most popular ones are probably ORMLite, GreenDAO and DbFlow.
Creating a Model
There are two main ways to define the mapping between your objects and the tables in Java: some DSL + code generator (like what GreenDAO is using), or using annotation (like ORMLite, DBFlow and most of the libraries). Although I’m not a big fan of annotations, I must say the later is an easier solution.
These why it’s no surprise that the Android team chose to go with this approach, so simple data model looks like this:
@Entitypublic class User { @PrimaryKey private int uid; @ColumnInfo(name = "first_name") private String firstName; @ColumnInfo(name = "last_name") private String lastName; // Getters and setters are ignored for brevity, // but they're required for Room to work. // // (Author note: please go and switch to Kotlin) // (Author note #2: ok maybe you should wait a bit)}
As in any other library- you can set a custom name for the table or the columns, you can choose to index some stuff and specify relationships between models.
The API
To interact with the data models, we use DAO- Data Access Object. So nothing new from Google here also. For each model, we need to declare a DAO with CRUD operations. Every library covers the main functionality and offers kind of the same sets of features.
BUT while most of the ORM libraries using some in-code query builder, Room doing something nice and let you declare your queries in slick SQL formatting.
For example, here is how you’ll do a simple query for specific users in each one of the platforms:
//Room:@Query("SELECT * FROM user WHERE age > :minAge")public User[] loadAllUsersOlderThan(int minAge);//DbFlow:List<User> users = SQLite.select() .from(User.class) .where(User_Table.age.greaterThan(minAge) .queryList();//ORMLite:List<User> users = userDao.queryBuilder() .where() .gt("age", minAge) .query();//GreenDAO:List<User> users = userDao.queryBuilder() .where(Properties.Age.gt(minAge)) .list();
On the one hand- it’s cleaner and most of us familiar with SQL syntax, but on the contrary, you’re losing some of the power of your object mapping (no autocomplete, and you need to remember the object’s table).
Live Data
The Room library is playing nicely with the other architecture components Google announced, specifically with Live Data. So you can easily be notified (with live queries or RxJava) about changes in your data, and you do not need to worry about updating your data in real time.
This is great, and I feel this is one of the strengths of Room. However, I believe that this kind of behavior can also be achieved with existing libraries by adding another layer on top to handle all changes.
(I edited the article and added the Live Data section, thanks to Zhuinden comment)
Performance
Reading and writing to the database is an expensive IO operation. If you’re working with lots of entities in your app, it might be a bottleneck. That’s why GreenDAO and DbFlow are heavily investing in performance (it might even get ugly some times).
I decided to check how Room performs in relation to the others, so I take the GreenDAO benchmark (I looked on Raizlabs benchmark too, but I felt it’s too biased), and added Room. You can see the source code here.
I compared the results to the libraries discussed in the post. I ran all tests on an emulator and took the average of each library results (I’ll attach the full results of each library, so you’ll able to take a closer look).
It is a simple, fast setup benchmark, and I didn’t analyze the results too much. From first looking at the results- you can see that Room has no advantage in any aspect of performance over the other libs. While making small operations one by one- ORMLite has it’s own advantages, when moving the bigger scales- DBFlow and GreenDAO obviously win (because the caching they use).
Summary
Google did a fantastic job by taking a step forward to help developers architect their apps better. The last components that Google introduced are right in place and should help each one of us write better code in less time.
BUT, choosing to deliver another ORM solution, instead of adapting one, is something that I do not understand. I would expect that the team will take an existing solution that works, or even just recommend one (like what they are doing with Retrofit).
If you liked this post click the ♡ bellow. As a writer it means the world.
If you want Medium to tell you about new posts click the Follow button.
Full reports:PerfTestDbFlow-1by1.tsvPerfTestDbFlow-batch.tsvPerfTestNotNull-1by1.tsv (GreenDAO)PerfTestNotNull-batch.tsv (GreenDAO)PerfTestOrmLite-1by1.tsvPerfTestOrmLite-batch.tsvPerfTestRoom-1by1.tsvPerfTestRoom-batch.tsv
Originally published at shem8.github.io on Jun 2, 2017.