ခဏလေး ဒီလိုပဲ စဉ်းစားကြည့်
Room က Android ရဲ့ built-in SQLite database ကို type-safe, Kotlin-friendly ဖြစ်အောင် wrap ပေးထားတဲ့ library ပါ — Entity (`@Entity`, table structure ကို data class နဲ့ define), DAO (`@Dao`, database operation - insert/query/delete ကို interface နဲ့ define), Database (`@Database`, Entity/DAO တွေကို ပေါင်းစပ်ပေးတဲ့ class) ဆိုပြီး core concept ၃ ခု ရှိပါတယ်။ Room ကို ViewModel (Advanced lesson 1) နဲ့ တွဲသုံးရင် — app ကို restart လုပ်ရင်တောင် data ကို device ပေါ်က ဆက်ရရှိနိုင်ပါတယ် (RAM-only ViewModel state နဲ့ မတူပါ).
လက်တွေ့ scenario နဲ့ ချိတ်ကြည့်မယ်
`@Entity data class TodoEntity(@PrimaryKey val id: String, val title: String, val isDone: Boolean)` ကို define လုပ်ပြီး, `@Dao interface TodoDao { @Query("SELECT * FROM TodoEntity") suspend fun getAll(): List<TodoEntity>; @Insert suspend fun insert(todo: TodoEntity) }` ကို ရေးပါ — ViewModel ထဲက `todoDao.insert(newTodo)` ခေါ်ရင် data ကို device disk ပေါ် permanent သိမ်းပေးပါတယ်, app ကို force-close ပြီး ပြန်ဖွင့်ရင်တောင် data ကျန်ရှိနေမှာပါ.
အတူတူ ကြည့်မယ်
@Entity
data class TodoEntity(
@PrimaryKey val id: String,
val title: String,
val isDone: Boolean
)
@Dao
interface TodoDao {
@Query("SELECT * FROM TodoEntity")
suspend fun getAll(): List<TodoEntity>
@Insert
suspend fun insert(todo: TodoEntity)
}
@Database(entities = [TodoEntity::class], version = 1)
abstract class AppDatabase : RoomDatabase() {
abstract fun todoDao(): TodoDao
}App ကို force-close ပြီး ပြန်ဖွင့်တောင် todo list data ဆက်ရှိနေတာ (Room ကနေ ပြန်ဆွဲထားလို့) တွေ့ရမည်။၅ မိနစ် စမ်းကြည့်
`TodoEntity`, `TodoDao`, `AppDatabase` ၃ ခုကို ကိုယ်တိုင်ရေးကြည့်ပြီး, `TodoViewModel` (Advanced lesson 1) ထဲက in-memory list အစား Room DAO ကို ခေါ်သုံးအောင် ပြောင်းရေးကြည့်ပါ။
သတိလေးတစ်ချက်
Database schema ပြောင်းလဲတဲ့အခါ `Migration` strategy မထားဘဲ `fallbackToDestructiveMigration()` ကို production app မှာ သုံးရင် — app update ပြီးတဲ့နောက် existing user ရဲ့ data အားလုံး ဖျက်ပစ်ခံရနိုင်ပါတယ်။