Room Persistence Library in MVVM Architecture| Kotlin

Timur Pehlivan
4 min readApr 13, 2020
The rights of this image are for RayWenderLich
The rights of this image are for RayWenderLich

What is Room Persistence Library?

Room Persistence Library is an easy manage database layer over SQLite, provides to store the data on the local machine and to use these stored data without an internet connection. Also, the Room is built to work with LiveData and RxJava for data observation.

Implementation of the Room

To use room database into our projects, it will be enough to implement following dependencies below to app/build.grade

Now we are ready to create our own local database tables.

How to create tables on Room DB?

First of all, we should understand the logic of the Room persistence library. Room DB consists of three components. Which are:

  1. Entity
  2. DAO
  3. Database

Let’s start with entity class

Entity

Entity is the class, in which we can create our table, columns and configure the properties of these columns. Also, we can give relations(mapping) between these columns.

In the example below, @Entity(tableName = “shopping_list_table”) annotation allows us to create a table with the given name. Following, to create our columns and data types of the columns. In the last part of the class, we initiate primaryKey columns and automatically increase the entity in the column with “(autoGenerate = true)” — a part of the annotation.

DAO

In the Dao interface, we can set queries up like in the example. First what we should do is to write down @Dao annotation to the top of the interface name.
For insert, delete, update operations, Dao brings us to predefine annotations that we can easily implement to use. But, if we need much more complex queries, we should write our query inside of the @Query annotation.

If you look carefully at our query method, you will notice the LiveData data type. As mentioned in the first paragraph of the Room description, LiveData lets us observe the data, which returns from that query. One of its advantages is no Memory Leak. We shouldn’t confuse it with Observable.

LiveData is an observable data holder class. Unlike a regular observable, LiveData is lifecycle-aware, meaning it respects the lifecycle of other app components, such as activities, fragments, or services. This awareness ensures LiveData only updates app component observers that are in an active lifecycle state.

As we remember, we implement 2 more different dependencies to the app/build.gradle file, which are lifecycle dependencies. The reason of it to use LiveData in our project.

Database

Here we are on the last step of the creation of our database. In this Database class, we will define: our entity class or classes, the version number of database and TypeConverter class to convert data type to another one (if we have one).
We will talk about the TypeConverter class a bit later below.

Finally we have done with building our local database. As you see, if we understand the logic, the Room is quite a simple library to implement.
Let’s push it and see, how we can write/read on the runtime or create mock data to test our project.

TypeConverter

Room provides functionality for converting between primitive and boxed types but doesn’t allow for object references between entities.

Because of this issue, sometimes we need to convert our data types between each other.

MVVM Architecture

We will build our project according to MVVM Architecture, which means,
we will have:

  1. Model(Data)
  2. View(UI)
  3. ModelView(Helper class to access the Model trigger via UI)

Model

We’ve already create entities and build our local database. Base on MVVM Architecture we need to create a Repository class to access the database.

First thing first, if we create a folder whose name is “data” and put all the classes we have created, it will be much easier to see the architecture.

View

In the View part, we will control our fragments(.xml), draw the data and update the UI according to the data. But the important part, there shouldn’t be a direct relation between Model and View.
This part is all up to you: how you want to design your fragment, where you will show the data, which components you will use, etc.

As an example:

ViewModel

ViewModel is a class that is responsible for preparing and managing the data for an Activity or a Fragment. It also handles the communication of the Activity / Fragment with the rest of the application (e.g. calling the business logic classes).

After all these, it’s all on you to use these methods and design your own app, how you want.

I hope you enjoyed it.

--

--