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.

Instatiation:

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.

Testing:

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!

Conclusion:

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…

What I learned from Kotlin Flow API

I used to check the docs and just read a lot about flows but didn't implement anything until yesterday. However, the API tasted really cool (even though some operations are still in Experimental state).Prerequisites: If you don't know RxJava it's fine. But a RxJava recognizer would read this faster.Cold vs Hot streamsWell, I really struggled with this concept because it is a little bit tricky. The main difference between cold and hot happened to be pretty simple: Hot streams produce when you don't care while in cold streams, if you don't collect() (or RxJava-s equivalent subscribe()) the stream won't be activated at all. So, Flows are what we call cold streams. Removing the subscriber will not produce data at all, making the Flows one of the most sophisticated asynchronous stream API ever (in the JVM world). I tried to make a illustration of hot and cold streams: Since I mentioned the word asynchronous this implies that they do support coroutines also. Flows vs…

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…