Skip to main content

Room, the basics

Official Stavro Xhardhas page · Post Room, the basics Posting as Stavro Xhardha Room, the basics
It has been a while since Roompersistence library is out. It was about time, the SQLiteimplementation was awful, long work and sometimes…

It has been a while since Room persistence library is out. It was about time, the SQLite implementation was awful, long work and sometimes confusing.
Therefore, the Android team built Room:

The Room persistence library provides an abstraction layer over SQLite to allow for more robust database access while harnessing the full power of SQLite.

According to the above statement from the official documentation, Room is nothing more than a “refactored and improved” SQLite library.

The setup:

The third dependency is not necessary for room but I am using Room with Coroutines

The Entity:

After you have imported the dependencies, you may start constructing your database. What your database needs at first is a table (or on Room language the Entity):

This is a table in terms of Room and a model class in terms of Kotlin . It is a representation of your data. To tell Room that I have a table to define I need to provide the @Entity annotation with the required parameter. Every table in Room should have a Primary Key . You can use also the AutoIncrement but I don’t really need it for my case.With the @ColumnInfo I am telling room what name will this field have. Notice the @Ignore annotation. This is a special annotation that tells Room not to care about that field. Since I am using the same Name model for my network request and also for Room I need that field for the network but not for the Database.

The Dao:

The Dao is nothing more than a way to define your queries based on the Entity you declared. Basically, every Entity must have a Dao in order to deal with the table data. Leave the rest to the Room

Dao should be an interface or an abstract class . Just annotate it with the @Dao annotation. I believe there is no need to say what @Query or @Insert annotations do. One thing I must notice here is that, the table name must be the same as your tableName defined in your entity. However don’t worry, the IDE will provide it for you as soon as you start typing it. The other thing I have to mention here is passing method parameters in the query. It can be done as the example states by adding : before the query parameter:
SELECT * FROM names where id = :number .

Database Declaration:

This is where your database is declared, your entities are defined and also the version and the schema. If you want to keep your database version for testing purposes, or you need other things to check, set the exportSchema to true.


Remember, Room instance is a Singleton and needs to declared only one time for application. With the help of Dagger2 I instantiate it like this:

And after that I only require the Dao according to the module dependencies:

Notice the fallbackToDestructiveMigration() method. This one tells Room to delete my data when I migrate to a new database version. It is optional, you can remove it if you want.


I am pretty new at testing myself, but testing in room is not that difficult. First, go to the androidtest package and create a new class:

After that you need a Fake for RoomDatabase . This basically runs the queries in memory without caching data to a real database:

And finally:

Remember, I am using the runBlocking only because I am using Room with coroutines. Done!


After I learned how to use Room , I have to say that using a database in Android jumped from being my stress to my hobby.

What helped me:

If you like my post please check other stories on my profile:

Post settings Labels Published on 6/19/19, 1:46 AM Pacific Daylight Time Permalink Location Options

Popular posts from this blog

Modularizing your Android app, breaking the monolith (Part 1)

Inspired by a Martin Fowlers post about Micro Frontends, I decided to break my monolithic app into a modular app. I tried to read a little more about breaking monolithic apps in Android, and as far as I got, I felt confident to share my experience with you. This will be some series of blog posts where we actually try to break a simple app into a modularized Android app.

Note: You should know that I am no expert in this, so if there are false statements or mistakes please feel free to criticize, for the sake of a better development. 

What do you benefit from this approach:
Well, people are moving pretty fast nowadays and delivery is required faster and faster. So, in order to achieve this, modularising Android apps is really necessary.You can share features across different apps. Independent teams and less problems per each.Conditional features update.Quicker debugging and fixing.A feature delay doesn't delay the whole app. As per writing tests, there is not too much difference about…

From Gson to Moshi, what I learned

There is no doubt that people are getting away from GSON and I agree with those reasons too. The only advantage GSON has over other parsing libraries is that it takes a really short amount of time to set up. Furthermore, the most important thing is that Moshi is embracing Kotlin support.

First let's implement the dependency:
implementation("com.squareup.moshi:moshi:1.8.0") It's not a struggle to migrate to Moshi. It's really Gson look-a-like. The only thing to do is annotate the object with @field:Json instead of @SerializedName (which is Gsons way for JS representation):

data class User( //GSON way @SerializedName("name") val name: String, @SerializedName("user_name") val userName: String, @SerializedName("last_name") val lastName: String, @SerializedName("email") val email: String ) data class User( //Moshi way @field:Json(name = "name") val name: String, @field:Json(name = "user_name…

Modularizing your Android app, breaking the monolith (Part 2)

This is part 2 of a series of articles about modularizing Android app. If you haven't yet read the first article, you may find it here.

On our first article we just moved some classes outside the application and applied as an independent module. But what if we have dependencies pulled from the application level? This could be a small challenge. First of all, we want to clarify on how are we going to modularize the app. And depending on the previous article, I chose the by feature version of modularization. First of all, let's show some dependencies that are going to be needed in the whole app.

Note: I'm using Dagger for handling dependencies but manual DI or any dependency tool should be fine to understand this part.

So, this is my dependency schema:

Well, it's not that bad, but this isn't what we want to transform to when trying to modularize the app. If you think about it, modules that don't need a dependency, can get it quite easily. For example: A FeatureXVi…