Cache at data synchronization sa mobile development: ano ito, anong mga estratehiya at kung paano ito gumagana

Pangangasiwa ng Datos sa mga Mobile Application: Repository Pattern at Data Source

Ang Repository pattern ay isang arkitektural na diskarte kung saan ang isang solong repository class ay namamahala sa lahat ng operasyon ng datos, na nag-aabstrak ng malalayong REST API at lokal na imbakan na Room o SwiftData. Ang paraang ito ng pangangasiwa ng datos ay nagpapahintulot sa application na kunin muna ang impormasyon mula sa Memory Cache o Disk Cache, at pagkatapos ay mula sa network, na binabawasan ang oras ng pagtugon. Sa mobile development, ang Repository ay naging de facto standard salamat sa mga rekomendasyon ng Google at Apple.

Remote Data Source at Local Data Source

Ang Remote Data Source ay nagbibigay ng napapanahong impormasyon mula sa server sa pamamagitan ng mga HTTP request. Local Data Source ay lokal na imbakan sa device, na ipinatupad sa pamamagitan ng Room sa Android o SwiftData sa iOS. Pinagsasama ng repository ang parehong pinagmumulan: una nitong sinusuri ang lokal na cache, at kapag walang datos, humihiling mula sa malayong API. Ang organisasyong ito ng pangangasiwa ng datos ay nagpapahintulot sa application na gumana sa offline mode at binabawasan ang load ng server.

Halimbawa ng Repository sa Kotlin

class UserRepository(
    private val remoteDataSource: UserRemoteDataSource,
    private val localDataSource: UserLocalDataSource
) {
    suspend fun getUsers(): List<User> {
        localDataSource.getCachedUsers()?.let { return it }
        val users = remoteDataSource.fetchUsers()
        localDataSource.cacheUsers(users)
        return users
    }
}

Halimbawa ng Repository sa Swift

class UserRepository {
    private let remote: UserRemoteDataSource
    private let local: UserLocalDataSource
    
    func getUsers() async throws -> [User] {
        if let cached = await local.getCached() { return cached }
        let users = try await remote.fetch()
        await local.save(users)
        return users
    }
}

Data Caching: LRU Cache, Disk Cache at Memory Cache

LRU Cache (Least Recently Used) ay isang caching algorithm kung saan, kapag naabot ang limitasyon, ang elementong hindi na-access nang pinakamatagal ay tinatanggal. Sa mga mobile application, ang LRU Cache ay ginagamit para sa mga imahe, tugon ng API at serialized na mga object. Ang tamang data caching ay nagbabawas ng bilang ng mga network request at nagpapabilis ng pag-load ng nilalaman. Ang cache sa mga mobile application ay isang mahalagang bahagi para sa mataas na pagganap.

Memory Cache vs Disk Cache

Ang Memory Cache ay nag-iimbak ng datos sa RAM — ang pag-access ay napakabilis, ngunit ang kapasidad ay limitado sa laki ng heap ng application. Disk Cache ay nag-iipon ng impormasyon sa file system — mas mabagal ngunit maaaring maglaman ng higit pa at nagpapatuloy sa pagitan ng mga session. Ang pinakamainam na estratehiya sa mobile development ay isang two-level cache: Memory Cache para sa mainit na datos at Disk Cache para sa malamig na datos. Sa pangangasiwa ng datos, ang unang antas ng cache sa memorya ay sinusuri muna, sinusundan ng pangalawang antas ng cache sa disk.

Halimbawa ng Implementasyon ng LRU Cache

class MemoryCache<K, V>(
    private val maxSize: Int = 100
) {
    private val cache = LinkedHashMap<K, V>(0, 0.75f, true)

    fun get(key: K): V? = cache[key]

    fun put(key: K, value: V) {
        if (cache.size >= maxSize) {
            cache.remove(cache.keys.first())
        }
        cache[key] = value
    }
}

Mga Estratehiya sa Pagpapawalang-bisa ng Cache

Ang TTL cache (Time To Live) ay awtomatikong nag-aalis ng entry pagkatapos ng tinukoy na agwat ng oras — angkop para sa data ng API. Pagpapawalang-bisa batay sa kaganapan ay nililinis ang cache kapag nakatanggap ng push notification tungkol sa mga pagbabago. Sa mga mobile application, ang pagpili ng caching strategy ay depende sa uri ng datos: ang mga imahe ay naka-cache nang mahabang panahon, habang ang news feed ay nangangailangan ng madalas na pagpapawalang-bisa. Ang Coil sa Android at Kingfisher sa iOS ay naka-integrate na ng LRU Cache para sa pagtatrabaho sa mga imahe.

Offline Queue: Offline Queue at Sync Manager

Offline Queue ay isang istraktura ng datos na nag-iimbak ng mga operasyon ng gumagamit (paglikha, pag-update, pagtanggal) sa isang lokal na database kapag offline ang device. Kapag naibalik ang koneksyon, ang Sync Manager ay sunud-sunod na naglalapat ng mga operasyong ito sa server. Ang ganitong uri ng data synchronization ay nagsisiguro na walang pagbabago ang mawawala sa panahon ng pansamantalang pagkawala ng network. Sa mobile development, ang Offline Queue ay isang kritikal na bahagi para sa mga application na may hindi matatag na koneksyon.

Arkitektura ng Offline Queue

Ang queue ay binuo sa isang table sa Room o SwiftData na may mga field: uri ng operasyon, katawan ng JSON request, timestamp at katayuan. Sync Manager ay isang background service na nagpoproseso ng mga nakabinbing operasyon, ipinapadala ang mga ito sa server, ina-update ang katayuan at nag-aalis ng mga matagumpay na entry. Ang data synchronization sa pamamagitan ng WorkManager sa Android o BGTaskScheduler sa iOS ay nagpapatuloy kahit pagkatapos ng pag-reboot ng device. Ang paggamit ng Offline Queue kasama ang tamang pangangasiwa ng datos ay nagsisiguro ng walang patid na karanasan ng gumagamit.

Halimbawa ng Offline Queue sa Kotlin

@Entity
data class SyncOperation(
    @PrimaryKey val id: Long,
    val endpoint: String,
    val method: String,
    val body: String,
    val createdAt: Long
)

class SyncManager(
    private val dao: SyncOperationDao,
    private val api: ApiService
) {
    suspend fun syncPending() {
        dao.getPendingOperations().forEach { op ->
            try {
                api.execute(op.endpoint, op.method, op.body)
                dao.delete(op.id)
            } catch (e: Exception) {
                // retry on next cycle
            }
        }
    }
}

Patakaran sa Pagsubok Muli at Timeout

Exponential backoff sa pagitan ng mga pagsubok muli (1s, 2s, 4s, 8s) ay pinoprotektahan ang server mula sa biglaang pagtaas ng load at pinipigilan ang walang katapusang pagsubok muli. Ang limitasyon ng 5 pagsubok ay pumipigil sa pag-apaw ng queue. Ang data synchronization sa mga mobile application na may suporta sa idempotency sa panig ng server ay nagpapahintulot ng ligtas na pagsubok muli, na umiiwas sa mga duplicate. Ito ay lalong mahalaga para sa mga financial transaction at order.

Data Synchronization: Conflict Resolution at Schema Migration

Conflict Resolution ay isang set ng mga estratehiya para sa mga sitwasyon kung saan ang parehong datos ay binago sa iba't ibang device nang sabay. Ang pangunahing data synchronization ay nangangailangan ng pagpili ng diskarte: Last-Write-Wins (panalo ang huling pagsulat), pag-version (panalo ang mas mataas na bersyon) o manu-manong paglutas. Sa mga kumplikadong senaryo, ginagamit ang CRDT (Conflict-Free Replicated Data Types), na naggarantiya ng matematikal na convergence ng datos.

Mga Estratehiya sa Paglutas ng Conflict

Ang Last-Write-Wins ay pinakasimpleng ipatupad ngunit maaaring mawala ang mga pagbabago ng gumagamit. Version Vector — bawat tala ay nag-iimbak ng numero ng bersyon at identifier ng device; isang conflict ang lumitaw kapag hindi tugma ang mga bersyon. Ang CRDT ay ang pinaka-maaasahan ngunit kumplikadong estratehiya: ang datos ay matematikal na nagtatagpo sa iisang estado nang walang sentralisadong tagapag-ugnay. Ang data synchronization sa mga mobile application na batay sa CRDT ay ginagamit sa collaborative editing sa Google Docs at synchronization ng nota sa Notion.

Schema Migration: Ligtas na Pag-update ng Database

Kapag na-update ang isang application, ang istraktura ng lokal na database ay nagbabago: idinaragdag ang mga column, table, index. Schema Migration ay ang proseso ng pagbabago ng umiiral na database sa isang bagong schema nang walang pagkawala ng datos. Sinusuportahan ng Room ang mga migration sa pamamagitan ng Migration class na may luma at bagong bersyon. Gumagamit ang SwiftData ng VersionedSchema upang ilarawan ang mga pagbabago. Ang tamang data synchronization sa pagitan ng mga bersyon ng application ay nangangailangan na ang mga migration ay masuri nang idempotent.

Halimbawa ng Schema Migration sa Room

val migration1to2 = object : Migration(1, 2) {
    override fun migrate(database: SupportSQLiteDatabase) {
        database.execSQL("ALTER TABLE users ADD COLUMN avatar_url TEXT")
    }
}

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

Halimbawa ng Conflict Resolution sa Swift

enum ConflictStrategy {
    case lastWriteWins
    case versionVector
    case crdt
}

struct VersionedDocument {
    let id: String
    let version: Int
    let data: Data
    let editedBy: String
    
    func resolve(with remote: VersionedDocument) -> VersionedDocument {
        return version >= remote.version ? self : remote
    }
}

Room at SwiftData para sa Lokal na Imbakan

Room ay isang Google library para sa lokal na imbakan sa Android, binuo sa SQLite at nagbibigay ng mga annotation para sa deklaratibong paglalarawan ng query. Ang SwiftData ay isang Apple framework para sa iOS, macOS, watchOS at visionOS, kahalili ng Core Data na may maikling Swift Macro syntax. Ang parehong tool ay lumulutas sa gawain ng pangangasiwa ng datos sa device, ngunit may iba't ibang diskarte sa organisasyon ng code. Ang cache sa mga mobile application ay madalas na binuo sa mga teknolohiyang ito.

Room: DAO, Entities at Type Converters

Gumagamit ang Room ng @Entity annotation para sa mga table at @Dao para sa mga query. DAO ay nag-e-encapsulate ng lahat ng SQL operation na may pagsusuri sa oras ng compilation — ang mga error sa SQL syntax ay natutukoy bago ang runtime. Ang Type Converter ay nagko-convert ng mga kumplikadong uri (Date, List) sa mga SQLite primitive. Ang makabagong pangangasiwa ng datos sa mga Android application ay binuo sa paligid ng Room + Flow, na nagbibigay ng reaktibong pag-update ng UI kapag nagbago ang cache o lokal na database.

SwiftData: @Model at @Query

SwiftData ay gumagamit ng macro @Model upang tukuyin ang mga entity at @Query upang obserbahan ang datos. Ang framework ay awtomatikong sumusubaybay sa mga dependency at ina-update ang interface sa mga pagbabago. Ang schema migration ay gumagamit ng VersionedSchema na naglalarawan ng lahat ng bersyon. Ang data synchronization sa pagitan ng SwiftData at server ay ipinatupad sa pamamagitan ng custom na Sync Manager na nag-subscribe sa mga update sa pamamagitan ng @Query.

Halimbawa ng Model sa SwiftData

@Model
final class UserModel {
    var id: String
    var name: String
    var email: String
    var updatedAt: Date
    
    init(id: String, name: String, email: String) {
        self.id = id
        self.name = name
        self.email = email
        self.updatedAt = Date()
    }
}

Paghahambing ng Room vs SwiftData