Pag-iimbak ng Datos sa Mobile Development — ano ito, mga paraan at paano gumagana

Ano ang permanenteng pag-iimbak ng datos

Data Persistence — ang kakayahan ng app na mag-imbak ng datos sa non-volatile memory ng device. Sa mobile development, ang permanenteng pag-iimbak ay sumasaklaw sa mga database, file system, setting, at cache. Ang bawat mekanismo ay may kanya-kanyang katangian ng performance, seguridad, at dami ng nakaimbak na impormasyon.

Pansamantala at permanenteng datos

Ang pansamantalang datos ay umiiral lamang sa RAM at nawawala kapag natapos ang proseso. Kasama rito ang estado ng screen, pansamantalang kalkulasyon, at cache ng mga larawan. Ang permanenteng datos ay isinusulat sa file system o database at nananatiling naa-access pagkatapos i-restart ang app. Kasama rito ang mga setting ng user, authorization token, kasaysayan ng operasyon, at na-download na nilalaman.

Mga pamantayan sa pagpili ng mekanismo ng pag-iimbak

Sa pagpili ng paraan ng pag-iimbak, sinusuri ng developer ang ilang salik. Ang uri ng datos ay tumutukoy sa istraktura ng pag-iimbak: mga simpleng setting — SharedPreferences o DataStore, mga naka-istrukturang talaan — SQLite o Room, mga file — File Storage. Ang dami ng datos ay nakakaapekto sa performance: ang mga database ay na-optimize para sa libu-libong talaan, at ang mga file para sa malalaking binary object. Ang seguridad ay nangangailangan ng pag-encrypt ng sensitibong impormasyon sa pamamagitan ng EncryptedSharedPreferences o SQLCipher.

data class StorageOption(
    name: String,
    dataType: StorageType,
    capacity: Long,
    secure: Boolean
)

enum class StorageType {
    KEY_VALUE,
    RELATIONAL,
    FILE
}

SharedPreferences at DataStore

SharedPreferences — ang klasikong paraan ng pag-iimbak ng mga pares ng key-value sa Android. Ang API na ito ay umiiral mula sa mga unang bersyon ng platform at sumusuporta sa mga primitive na uri: mga string, numero, boolean value. Ang datos ay naka-imbak sa XML file sa pribadong direktoryo ng app at naa-access lamang ng proseso nito.

DataStore bilang alternatibo

Ang Jetpack DataStore — modernong kapalit ng SharedPreferences, na binuo sa Kotlin Coroutines at Flow. Ang DataStore ay nag-aalok ng dalawang variant: Preferences DataStore para sa mga simpleng value at Proto DataStore para sa mga naka-type na object. Hindi tulad ng SharedPreferences, ginagarantiyahan ng DataStore ang consistency ng datos sa concurrent access at sumusuporta sa asynchronous na operasyon nang hindi hinaharangan ang main thread.

// SharedPreferences — tradisyonal na paraan
val prefs = context
    .getSharedPreferences("settings", Context.MODE_PRIVATE)
with (prefs.edit()) {
    putString("username", "john_doe")
    putInt("score", 1500)
    apply()
}

// DataStore — asynchronous na approach
val settingsDataStore = context
    .createDataStore("settings.pb")

val usernameFlow: Flow<String> = settingsDataStore
    .data
    .map { it[USERNAME_KEY] ?: "" }

Sa iOS, ang katumbas ng SharedPreferences ay UserDefaults — isang sistema ng pag-iimbak ng mga simpleng value sa Property List format. Ang UserDefaults ay gumagamit ng synchronous na access at angkop para sa maliliit na dami ng configuration data, ngunit hindi inirerekomenda para sa pag-iimbak ng sensitibong impormasyon.

SQLite sa mga mobile app

SQLite — naka-embed na relational database na gumagana sa loob ng proseso ng app nang walang hiwalay na server. Ito ang pinakakaraniwang DBMS sa mobile development: ito ay ginagamit bilang default sa parehong platform. Ang Android ay may kasamang SQLite sa SDK, at iOS sa libsqlite3 library. Sinusuportahan ng SQLite ang standard SQL, mga transaksyon, index, at trigger.

Paglikha ng table at CRUD operations

Ang pagtatrabaho sa SQLite ay nagsisimula sa paglikha ng schema ng database. Tinutukoy ng developer ang mga table, kanilang field at uri, pagkatapos ay nagsasagawa ng mga operasyon ng pagpasok, pagbasa, pag-update, at pagbura. Ang SQLiteOpenHelper sa Android ay namamahala sa paglikha at pag-migrate ng database, habang sa iOS ay ginagamit ang C interface o FMDB wrapper.

// SQLiteOpenHelper sa Android
class DBHelper(context: Context) :
    SQLiteOpenHelper(context, "app.db", null, 1) {

    override fun onCreate(db: SQLiteDatabase) {
        db.execSQL("""
            CREATE TABLE users (
                id INTEGER PRIMARY KEY,
                name TEXT NOT NULL,
                email TEXT UNIQUE
            )
        """)
    }

    fun insertUser(name: String, email: String) {
        val db = writableDatabase
        val values = ContentValues().apply {
            put("name", name)
            put("email", email)
        }
        db.insert("users", null, values)
    }
}

Room — ORM para sa Android

Room — library mula sa Jetpack suite na nagbibigay ng ORM layer sa ibabaw ng SQLite. Inaalis ng Room ang nakagawiang pagsulat ng SQL query at ContentValues, pinapalitan ang mga ito ng mga annotation at Kotlin function. Ang compiler ng Room ay bumubuo ng DAO (Data Access Object) implementation sa yugto ng build, na nag-aalis ng mga error sa SQL syntax.

Pag-configure ng Room sa proyekto

Upang ikonekta ang Room, kailangang magdagdag ng kapt dependency at i-annotate ang entity class, DAO interface, at database class. Ang RoomDatabase ay nagsisilbing entry point: sa pamamagitan nito ay nakukuha ang DAO at ginagawa ang mga operasyon sa database. Sinusuportahan ng Room ang Flow para sa reactive query, schema migration, at pag-validate ng query sa yugto ng compilation.

@Entity(tableName = "users")
data class User(
    @PrimaryKey val id: Int,
    @ColumnInfo(name = "full_name") val name: String,
    @ColumnInfo val email: String
)

@Dao
interface UserDao {
    @Query("SELECT * FROM users")
    fun getAll(): Flow<List<User>>

    @Insert
    suspend fun insert(user: User)

    @Delete
    suspend fun delete(user: User)
}

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

Core Data — iOS framework

Core Data — framework ng Apple para sa pamamahala ng object graph at pag-imbak nito sa disk. Hindi tulad ng Room, ang Core Data ay hindi gumagana sa mga table, kundi sa mga managed object (NSManagedObject) na bumubuo ng hierarchy ng mga relasyon. Sinusuportahan ng Core Data ang lazy loading, pag-undo ng mga pagbabago, at kumplikadong query sa pamamagitan ng NSFetchRequest.

Core Data Stack

Ang pundasyon ng Core Data ay isang stack ng tatlong bahagi: managed context (NSManagedObjectContext), persistent store (NSPersistentStoreCoordinator), at data model (NSManagedObjectModel). Ang NSPersistentContainer ay pinag-iisa ang lahat ng bahagi sa iisang entry point, pinapasimple ang configuration para sa modernong Swift app.

import CoreData

class PersistenceController {
    static let shared = PersistenceController()
    let container: NSPersistentContainer

    init() {
        container = NSPersistentContainer(name: "AppModel")
        container.loadPersistentStores { _, error in
            if let error = error {
                fatalError("Failed: \(error)")
            }
        }
    }

    func saveUser(name: String, email: String) {
        let context = container.viewContext
        let user = User(context: context)
        user.name = name
        user.email = email

        do {
            try context.save()
        } catch let error {
            print("Error sa pag-save: \(error)")
        }
    }
}

Ang pag-iimbak ng file (File Storage) ay ginagamit para sa pag-save ng mga larawan, video, at dokumento. Ang Android ay nagbibigay ng internal storage (context.filesDir) — pribado para sa app, at external storage (Environment.getExternalStorageDirectory) — naa-access ng ibang app. Sa iOS, ang mga file ay nai-save sa Documents at Library na direktoryo, kung saan ang Library/Caches ay para sa cache na hindi naba-back up sa iCloud. Para sa pagtatrabaho sa mga file, ang parehong platform ay nagbibigay ng File API at stream read/write operations. Ang mga modernong library tulad ng Coil at SDWebImage ay nagdaragdag ng caching layer na pinagsasama ang file storage sa RAM para sa optimal na performance.

Sa Android, ang alternatibo sa Core Data sa mga tuntunin ng pagiging kumplikado at functionality ay Realm — isang object-oriented database na direktang gumagana sa mga modelo nang walang SQL layer. Ang Realm ay mas mabilis kaysa SQLite sa read operations at sumusuporta sa live na object na awtomatikong nag-a-update ng UI kapag nagbago ang datos.