Room database setup in Android Kotlin - Practice Problems & Coding Challenges

Challenge - 5 Problems

📝 Syntax

intermediate

Correct Room Entity Declaration

Which option correctly declares a Room entity with a primary key named id of type Int?

A

@Entity
 data class User(
  @PrimaryKey val id: Int,
  val name: String
 )

B

@Entity
 data class User(
  val id: Int,
  @PrimaryKey val name: String
 )

C

data class User(
  @PrimaryKey val id: Int,
  val name: String
 )

D

@Entity
 data class User(
  @PrimaryKey(autoGenerate = true) val name: String,
  val id: Int
 )

💡 Hint

Remember the @Entity annotation is required on the data class and @PrimaryKey must be on the primary key property.

Option A correctly uses @Entity on the data class and marks id as the primary key. Option A wrongly marks name as primary key. Option A misses the @Entity annotation. Option A wrongly uses name as primary key and swaps property order.

❓ ui_behavior

intermediate

Room Database Builder Behavior

What happens if you call Room.databaseBuilder(context, AppDatabase::class.java, "db_name").build() multiple times in your app?

A Each call creates a new database instance, which can cause unexpected behavior and resource waste.

B Room automatically returns the same singleton instance for all calls.

C The database file is deleted and recreated each time.

D The app crashes with an IllegalStateException.

💡 Hint

Think about how Room manages database instances and best practices for usage.

Calling databaseBuilder().build() multiple times creates separate instances. This can cause conflicts and waste resources. The recommended approach is to create a singleton instance and reuse it.

❓ lifecycle

advanced

Room Database Migration Handling

If you change your Room database schema by adding a new column without providing a migration strategy, what will happen when the app runs?

A Room automatically updates the database without any issues.

B The app crashes with an IllegalStateException about missing migration.

C The app ignores the new column and continues using the old schema.

D The database is deleted and recreated silently.

💡 Hint

Room requires explicit migration strategies to handle schema changes safely.

Room enforces schema consistency. Without a migration, it throws an IllegalStateException to prevent data loss. You must provide a migration or fallback strategy.

❓ navigation

advanced

Accessing DAO from ViewModel

What is the best way to access a Room DAO inside a ViewModel in an Android app?

A Create a new database instance inside the ViewModel and get the DAO.

B Use a global variable to hold the DAO and access it inside the ViewModel.

C Pass the DAO instance to the ViewModel constructor using a ViewModelFactory.

D Access the DAO directly from the Activity and pass data to ViewModel methods.

💡 Hint

Think about separation of concerns and lifecycle safety.

Passing the DAO via ViewModelFactory keeps the ViewModel testable and lifecycle-aware. Creating new database instances or using globals can cause resource issues or tight coupling.

🧠 Conceptual

expert

Room Database Threading Behavior

Which statement best describes Room's default behavior regarding database operations and threading?

A Room queues database operations and runs them sequentially on the main thread.

B Room allows database operations on the main thread by default.

C Room automatically runs all queries on a background thread.

D Room throws an exception if you perform database operations on the main thread.

💡 Hint

Consider Android's UI thread and responsiveness rules.

Room enforces that database operations do not run on the main thread to avoid UI freezes. It throws a runtime exception if you try to do so unless you explicitly allow main thread queries (not recommended).

Practice

1. What is the main purpose of the @Entity annotation in Room database setup?

easy

A. To define a table in the database

B. To create a database instance

C. To write SQL queries

D. To start a database transaction

Solution

1. Step 1: Understand the role of @Entity

   The @Entity annotation marks a Kotlin data class as a table in the Room database.

2. Step 2: Differentiate from other annotations

   Other annotations like @Dao define data access objects, not tables.

3. Final Answer:

   To define a table in the database -> Option A

4. Quick Check:

   @Entity = Table definition [OK]

Hint: Remember: @Entity means table in Room [OK]

Common Mistakes:

• Confusing @Entity with @Dao
• Thinking @Entity creates the database
• Mixing @Entity with SQL query annotations

2. Which of the following is the correct way to declare a Room database class in Kotlin?

easy

A. @Dao(entities = [User::class], version = 1)\ninterface AppDatabase {\n fun userDao(): UserDao\n}

B. @Database(entities = [User::class], version = 1)\nabstract class AppDatabase : RoomDatabase() {\n abstract fun userDao(): UserDao\n}

C. @Entity(entities = [User::class], version = 1)\nclass AppDatabase : RoomDatabase() {\n fun userDao(): UserDao\n}

D. @Database(entities = User, version = 1)\nclass AppDatabase() {\n fun userDao(): UserDao\n}

Solution

1. Step 1: Identify correct annotation and class type

   The Room database class must be annotated with @Database and extend RoomDatabase.

2. Step 2: Check syntax for entities and abstract DAO method

   The entities list must be an array of classes, and DAO methods must be abstract.

3. Final Answer:

   @Database(entities = [User::class], version = 1)\nabstract class AppDatabase : RoomDatabase() {\n abstract fun userDao(): UserDao\n} -> Option B

4. Quick Check:

   @Database + abstract class + extends RoomDatabase = correct [OK]

Hint: Database class is abstract and annotated @Database [OK]

Common Mistakes:

• Using @Entity instead of @Database
• Not making the class abstract
• Forgetting to extend RoomDatabase

3. Given the following code snippet, what will be the result of calling db.userDao().getAllUsers()?

@Dao
interface UserDao {
  @Query("SELECT * FROM user")
  fun getAllUsers(): List<User>
}

@Entity
data class User(
  @PrimaryKey val id: Int,
  val name: String
)

// Assume database is properly created and contains 3 users

medium

A. A runtime error because of missing suspend keyword

B. An empty list

C. A list of 3 User objects from the database

D. A compilation error due to missing @Insert method

Solution

1. Step 1: Understand the DAO query

   The @Query("SELECT * FROM user") fetches all rows from the user table.

2. Step 2: Check the database state

   The question states the database contains 3 users, so the query returns 3 User objects.

3. Final Answer:

   A list of 3 User objects from the database -> Option C

4. Quick Check:

   Query returns all users = 3 users [OK]

Hint: Query returns all rows; count matches stored data [OK]

Common Mistakes:

• Assuming empty list without data check
• Confusing suspend functions with normal DAO methods
• Expecting errors without code context

4. Identify the error in this Room database builder code snippet:

val db = Room.databaseBuilder(
  context,
  AppDatabase::class.java,
  "app_db"
).build()

medium

A. Missing fallbackToDestructiveMigration() causing crash on schema change

B. Incorrect database name format, should be a URI

C. AppDatabase must be an interface, not a class

D. databaseBuilder requires a coroutine scope parameter

Solution

1. Step 1: Review databaseBuilder usage

   The code correctly builds the database but lacks migration strategy.

2. Step 2: Understand migration impact

   Without fallbackToDestructiveMigration(), schema changes cause runtime crashes.

3. Final Answer:

   Missing fallbackToDestructiveMigration() causing crash on schema change -> Option A

4. Quick Check:

   Missing migration fallback = crash risk [OK]

Hint: Add fallbackToDestructiveMigration() to avoid crashes [OK]

Common Mistakes:

• Thinking database name must be URI
• Confusing class vs interface for database
• Expecting coroutine scope in builder

5. You want to add a new column age to your existing User entity without losing existing data. Which approach correctly updates the Room database?

hard

A. Change the database name to force a new database creation

B. Just add the new field in the User class and keep the same database version

C. Delete the app data and reinstall to reset the database

D. Increase database version and provide a migration object with SQL to add the new column

Solution

1. Step 1: Understand schema changes in Room

   Adding a new column changes the database schema, so version must increase.

2. Step 2: Provide migration to preserve data

   Migration object with SQL ALTER TABLE adds the column without losing data.

3. Final Answer:

   Increase database version and provide a migration object with SQL to add the new column -> Option D

4. Quick Check:

   Schema change needs version bump + migration [OK]

Hint: Always migrate with version bump to keep data safe [OK]

Common Mistakes:

• Changing entity without version update
• Deleting app data instead of migrating
• Changing database name to avoid migration