Migrating to Room in the real world — Part 1
Analysis and planning.
Prologue
In this series of articles, we will walk you through our process of migrating to Room at Blinkist. Even though we will refer specifically to our previous ORM, we strongly believe that the steps we took, and the processes we followed, are applicable regardless and should be beneficial to anyone considering to do the same thing.
This article was written by two hands, mine and David Lázaro’s. We worked on this project together, and together decided that we wanted to describe the approach we took.
Context
The Android team at Blinkist is currently growing at a rapid pace, in order to be able to support the company’s needs as it grows even further. Among our priorities, we need to make sure that we remove the foreseen roadblocks in advance, so that the team can grow in a lean fashion as much as possible. As such, one of the first things we did was taking a good look at our codebase to identify what was potentially preventing us from scaling even more.
The Blinkist codebase, despite its 5 years of existence, has aged pretty graciously. The original developer, and everyone who came after, made a bet on technologies and frameworks that later became almost industry standards: RxJava, Retrofit, Dagger, Otto… well, no, not that last one. When it comes to persisting data, yet again the technology was solid and still used today: SQLite.
We all know how cumbersome it is to work with ContentValues and Cursors, so another choice was made: using Cupboard, a simple wrapper on top of SQLite that makes dealing with database a little less prone to anger. It’s very simple and yet powerful, and it has proven to be exceptionally stable.
As we looked at the overall architecture, it became clear that we were not super happy with it. We were big fans of ViewModel, we thought we could benefit from Kotlin’s coroutines at many different levels, and a more modern pattern like MVVM or MVI would be a better choice than MVP. We then envisioned what our ideal architecture would feature, we identified the areas we needed to chance, and we decided that the best starting point would be the persistence layer.
Cupboard has served Blinkist well for many years, but as new technologies and approaches arise, it started to show some limitations:
- It is no longer maintained — the last commit dates back to 2016 😱
- It is not inherently reactive
- It doesn’t play nicely with some of the recent Architecture Components that Google released
While there wasn’t an immediate need to find an alternative, we felt like we could enable ourselves to using new technologies and to develop at a faster pace, if only we were to find a good alternative.
We evaluated our options, and by now you already know that we decided to go with Room. Its reactiveness fit perfectly with our ideal architecture, its flexibility allowed us to choose between RxJava and coroutines (and potentially LiveData), it comes with a fairly strong type safety, its adoption is now widespread, and chances are that our new hires will be comfortable with using it as well. We considered other alternatives, among which SqlDelight from Square — while potentially more mature and powerful, we didn’t need any of the exclusive features it comes (e.g., multi-platform support).
But first things first, we needed to analyze the current situation and understand what we were dealing with.
Analysis
By analyzing the codebase, we managed to get a sense of how the situation looked like. Our repositories followed roughly the same structure, as we can see in the following diagram for the Library feature:
In the process, and by looking at the diagram above, we noticed a few challenges:
- Tight coupling between the repository code and the database code (no interfaces)
- Some unit tests were tightly coupled with the database code (i.e., explicit Cupboard calls)
- Some repositories didn’t have tests at all
- We used a seed database to provide an initial set of data for the user and avoid the “empty screen” problem
- Our models were shared across different layers, database, API and presentation (a.k.a. “fat models”)
- Too simple of a database schema
The tight coupling was preventing us from easily switching to Room, and at the same time, the absence of tests was making it easier to introduce regressions or to write code that was simply wrong. However, we figured that trying to make the models more lightweight and revisiting the schema would add too much on the plate, so we decided to postpone those to another time.
We saw a potential opportunity. If we made sure that our schema didn’t change during the migration process, we could have simply replaced Cupboard with Room. This was possible, as long as we modelled the Room tables correctly.
Our desired state, if we refer to the previous diagram for the Library feature, would look something like this:
This looked both much simpler and much cleaner!
Process-wise, we called a meeting with QA in order to define a common strategy to tackle the migration. The outcome of that conversation can be summed up with the following three constraints:
- Do not block other feature teams
- Minimize the impact
- Minimize the regressions
In order to adhere to the aforementioned constraints, we decided to structure the migration process into four main phases with their own deliverables:
- Phase 1: review existing tests and add the missing ones
- Phase 2: extract interfaces and add a Room-based implementation for each repository
- Phase 3: make the existing migrations work with Room and handle the seed database
- Phase 4: flip the switch
Let’s begin!
This is part 1 of 3 of our migration to Room. Want to hear more? Stay tuned for the upcoming articles, and make sure you let us know what you think!
EDIT: part 2 and part 3 are out now!
You can reach Sebastiano and David on Twitter 🙌
