Blibli x Android Room
Article Summary
Andrew Winata from Blibli shows how ditching raw SQLite queries for Room cut boilerplate code and made database operations type-safe at compile time. The migration took just a few strategic refactoring steps.
Blibli's Seller App needed to manage search history across multiple features (products, orders, returns) using SQLite. The team was manually writing SQL queries and mapping results to POJOs, creating maintenance headaches. They decided to adopt Android Room, Google's modern ORM framework introduced in 2017.
Key Takeaways
- Room auto-generates DAO implementations at compile time, eliminating manual query mapping
- Migration required converting POJOs to @Entity classes and creating interface DAOs
- Compile-time syntax checking catches SQL errors before runtime, improving reliability
- Integration with Dagger dependency injection made Room instances available app-wide
- Familiar DAO pattern made adoption easier for developers with Spring Java background
Room replaced low-level SQLite APIs with clean, type-safe database operations while maintaining the existing MVP architecture.
About This Article
Blibli's Seller App required developers to manually map SQLite cursor results to SearchHistory POJOs. This meant iterating through cursors, extracting column indices, and handling resource cleanup. The pattern repeated across multiple search features and was error-prone.
Andrew Winata's team converted SearchHistory to an @Entity class and created a SearchHistoryDAO interface. Room's compile-time code generation automatically produced the DAO_Impl implementation class, which handles all cursor mapping internally.
Manual SQL-to-POJO mapping code disappeared entirely. The team gained compile-time syntax checking, which reduced runtime database errors. They kept the existing MVP architecture without needing major rewrites.