Home Android & Kotlin Books Saving Data on Android

Room Architecture Written by Aldo Olivares

Heads up... You're reading this book for free, with parts of this chapter shown beyond this point as scrambled text.

You can unlock the rest of this book, and our entire catalogue of books and videos, with a raywenderlich.com Professional subscription.

In the previous section, you learned all the basics behind data storage on Android. You learned how to work with permissions, shared preferences, content providers and SQLite.

Shared preferences are very useful when you need to store and share simple data, such as user preferences as key-value pairs. The main drawback is that you can’t store large amounts of data since it’s not efficient and there’s no way to use queries to retrieve information.

SQLite is a fast, lightweight local database natively supported by Android that allows you to store large amounts of data in a structured way. The only downside of SQLite is that its syntax is not very intuitive since the way to interact with it can be very different from platform to platform.

Therefore, in this chapter, you are going to learn about one of the most popular libraries that helps you simplify your interaction with SQLite: Room.

Along the way, you will also learn:

  • How Object Relational Mappers work.
  • About Room’s integration with Google’s architecture components
  • The basics behind entities, DAOs and Room databases.
  • The advantages and disadvantages of Room.
  • The app you are going to build in the rest of this section.

Let’s dive in!

Object Relational Mappers

Before using Room properly in your projects, you first need to learn what Room is.

Room is a data persistence library commonly known as Object Relational Mapper or ORM. ORMs are tools that allow you to retrieve, delete, save and update the contents of a relational database using the programming language of your choice.

ORMs are implemented as libraries or frameworks that provide an additional layer of abstraction called the data layer which allows you to better interact with your database using a syntax similar to the object-oriented world.

To better understand how ORMs work, imagine that you have a Movie class with three properties: An id, a name and a release_date.

This is a class diagram that represents the Movie class. Just like most object-oriented languages, each of these properties has a certain data type such as Int, String or Date

With the help of an ORM, this Movie class can easily be used to create a new table in your database. In an ORM, classes represent a table inside your database and each property a column. For example, our previous Movie class would be translated into a table like this:

Each of the columns would also have the data type that best represents the original data type of the original property. For example, a String would be translated as a varchar and an Integer as an Int.

The way to create new records inside the tables differs from each implementation. For instance, some ORMs automatically create new entries each time a new instance of the class is created. Other ORMs such as Room use Data Access Objects or DAOs to query your tables.

This is a simple example of how you would use a DAO in Room to create new Movie records in the previously mentioned table:

movieDao.insert(Movie(1, "Harry Potter", "10-11-05"))
movieDao.insert(Movie(2, "The Simpsons", "03-10-02"))
movieDao.insert(Movie(3, "Avengers", "08-01-10"))

And your table now look like this:

Easy, right?

Note: Room can autogenerate the primary key, in this case, ID. You will learn how to do that in a later chapter.

Now, let’s take a look at how Room and Google’s architecture components work and interact with each other.

Room and Google’s architecture components

Android has been around for quite some time. In the beginning, Android apps were very simple and most performed trivial tasks, including calculators, calendars and to-do lists. But things have changed and mobile apps are more complex than ever. Now, there are media players, social networks, chat apps and even fast-paced 3D games.


On a device, the data is stored on a local SQLite database. Room provides an additional layer on top of the usual SQLite APIs that avoids having to create a lot of boilerplate code using the SQLiteOpenHelper class.

private const val SQL_CREATE_ENTRIES =
        "CREATE TABLE question (" +
                "question_id INTEGER PRIMARY KEY," +
                "text TEXT"

private const val SQL_DELETE_ENTRIES = "DROP TABLE IF EXISTS question"

class QuizDbHelper(context: Context) : SQLiteOpenHelper(context, DB_NAME, null, DATABASE_VERSION) {
    companion object {
        const val DATABASE_VERSION = 1
        const val DB_NAME = "question_database.db"
    override fun onCreate(db: SQLiteDatabase) {
    override fun onUpgrade(db: SQLiteDatabase, oldVersion: Int, newVersion: Int) {
    override fun onDowngrade(db: SQLiteDatabase, oldVersion: Int, newVersion: Int) {
        onUpgrade(db, oldVersion, newVersion)
@Database(entities = [(Question::class)], version = 1)
abstract class QuestionDatabase : RoomDatabase() {
  abstract fun questionsDao(): QuestionDao


Entities in Room represent tables in your database and are usually defined in Kotlin as data classes. Let’s take a look at the following Entity that is used to define a question table:

@Entity(tableName = "question") //1
data class Question(
    @PrimaryKey //2
    @ColumnInfo(name = "question_id") //3
    var questionId: Int,
    @ColumnInfo(name = "text")
    val text: String)


DAO stands for Data Access Object. DAOs are interfaces or abstract classes that Room uses to interact with your database using annotated functions. Your DAOs will typically implement one or more CRUD operations on a particular Entity.

@Dao //1
interface QuestionDao {
  @Insert(onConflict = OnConflictStrategy.REPLACE) //2
  fun insert(question: Question)

  @Query("DELETE FROM question") //3
  fun clearQuestions()

  @Query("SELECT * FROM question ORDER BY question_id") //4
  fun getAllQuestions(): LiveData<List<Question>>



This class acts as a bridge between your data sources and your app. The repository class handles the interaction with your Room database and other backend endpoints such as web services and Open APIs.


Just like the Repository acts as a bridge between your data sources and your app, the ViewModels act as a bridge between your repository and your user interface. The ViewModel communicates the data coming from your Repository to your Views and has the advantage of surviving configuration changes since it’s lifecycle-aware.


LiveData is a data holder class that implements the Observer pattern. This means it can hold information and be observed for changes. Your views such as Fragments or Activities observe LiveData objects returned from your ViewModels and update the relevant widgets as needed.

Room advantages and concerns

Room uses a local SQLite database to store your data. Therefore, most of the advantages and disadvantages of SQLite apply to Room as well.

Frequently asked Room questions

Are ORMs really necessary? Can’t I just use plain old SQLite?

Your app

This chapter has been full of theory and concepts and you are probably wondering when you are actually going to start writing some code.

Key points

Have a technical question? Want to report a bug? You can ask questions and report bugs to the book authors in our official book forum here.

Have feedback to share about the online reading experience? If you have feedback about the UI, UX, highlighting, or other features of our online readers, you can send them to the design team with the form below:

© 2021 Razeware LLC

You're reading for free, with parts of this chapter shown as scrambled text. Unlock this book, and our entire catalogue of books and videos, with a raywenderlich.com Professional subscription.

Unlock Now

To highlight or take notes, you’ll need to own this book in a subscription or purchased by itself.