This UI component shows how an Android app manages database migrations using Room. It helps update the database schema safely when the app changes, without losing user data.
The main screen is an AppCompatActivity hosting a FrameLayout. Inside, a TextView displays the current migration status message. Below it, a Button lets the user start the migration process.
Render Trace - 4 Steps
Step 1: AppCompatActivity
Step 2: TextView
Step 3: Button
Step 4: Migration process
State Change - Re-render
Trigger:User taps 'Migrate Database' button
Before
TextView shows 'Database version: 1'
→
After
TextView shows 'Migration successful: version 2'
Re-renders:TextView component re-renders to update the displayed text
UI Quiz - 3 Questions
Test your understanding
What does the TextView show before migration?
AMigration successful: version 2
BNo database found
CDatabase version: 1
DError during migration
Key Insight
Database migrations in Android apps require careful UI feedback to users. Showing the current version and updating it after migration helps users understand the app's data state. Using a Button to trigger migration keeps control clear and explicit.
Practice
(1/5)
1.
What is the main purpose of a database migration in Android apps?
easy
A. To update the database schema without losing existing data
B. To delete all data and recreate the database from scratch
C. To backup the database to external storage
D. To optimize database queries for faster performance
Solution
Step 1: Understand database migration purpose
Database migrations are used to change the structure of the database safely.
Step 2: Identify data preservation goal
Migrations update tables or columns without deleting existing user data.
Final Answer:
To update the database schema without losing existing data -> Option A
Quick Check:
Migration = Safe schema update [OK]
Hint: Migrations keep data safe while changing schema [OK]
Common Mistakes:
Thinking migrations delete all data
Confusing migrations with backups
Believing migrations only optimize queries
2.
Which of the following is the correct way to define a migration from version 1 to 2 in Room database?
val MIGRATION_1_2 = object : Migration(1, 2) {
override fun migrate(database: SupportSQLiteDatabase) {
// ?
}
}
easy
A. database.execSQL("ALTER TABLE users ADD COLUMN age INTEGER DEFAULT 0")
B. database.update("users", "age", 0)
C. database.insert("users", ContentValues())
D. database.delete("users")
Solution
Step 1: Understand Migration class usage
Migration requires SQL commands inside migrate() to change schema.
Step 2: Identify correct SQL command
ALTER TABLE adds a new column safely; execSQL runs raw SQL.
Final Answer:
database.execSQL("ALTER TABLE users ADD COLUMN age INTEGER DEFAULT 0") -> Option A
Quick Check:
Migration uses execSQL with ALTER TABLE [OK]
Hint: Use execSQL with ALTER TABLE to add columns [OK]
Common Mistakes:
Using update() instead of execSQL
Trying to insert or delete rows in migration
Not providing default value for new column
3.
Given this migration code, what will be the result after migrating from version 1 to 2?
val MIGRATION_1_2 = object : Migration(1, 2) {
override fun migrate(database: SupportSQLiteDatabase) {
database.execSQL("CREATE TABLE IF NOT EXISTS books (id INTEGER PRIMARY KEY, title TEXT)")
}
}
Assuming version 1 had no books table.
medium
A. No changes happen because CREATE TABLE is ignored
B. Migration fails because table 'books' already exists
C. A new table 'books' is created with columns 'id' and 'title'
D. Existing tables are deleted and only 'books' remains
Solution
Step 1: Analyze migration SQL command
CREATE TABLE IF NOT EXISTS creates the table only if it doesn't exist.
Step 2: Check initial database state
Version 1 has no 'books' table, so it will be created.
Final Answer:
A new table 'books' is created with columns 'id' and 'title' -> Option C
Quick Check:
CREATE TABLE IF NOT EXISTS creates missing table [OK]
Hint: IF NOT EXISTS avoids errors if table exists [OK]
Common Mistakes:
Assuming migration fails if table exists
Thinking CREATE TABLE is ignored
Believing existing tables get deleted
4.
What is wrong with this migration code from version 2 to 3?
Hint: Avoid adding same column twice in one migration [OK]
Common Mistakes:
Ignoring duplicate column errors
Thinking migration version is updated automatically
Believing ALTER TABLE syntax is wrong here
5.
You want to rename a column username to user_name in your Room database from version 3 to 4. SQLite does not support renaming columns directly. Which migration strategy is correct?
hard
A. Add a new column and leave the old column as is
B. Use ALTER TABLE to rename the column directly
C. Delete the old table and create a new one with the new column name
D. Create a new table with the new column name, copy data, drop old table, rename new table