موبائل ڈویلپمنٹ میں کیشے اور ڈیٹا کی مطابقت پذیری: یہ کیا ہے، کیا حکمت عملی ہیں اور یہ کیسے کام کرتا ہے

موبائل ایپلیکیشنز میں ڈیٹا کے ساتھ کام کرنا: Repository پیٹرن اور Data Source

Repository پیٹرن ایک آرکیٹیکچرل طریقہ ہے جہاں ایک واحد ریپوزٹری کلاس تمام ڈیٹا آپریشنز کا انتظام کرتی ہے، دور دراز REST APIs اور مقامی ذخیرہ Room یا SwiftData کو تجریدی بناتی ہے۔ ڈیٹا کے ساتھ کام کرنے کا یہ طریقہ ایپلیکیشن کو پہلے Memory Cache یا Disk Cache سے معلومات حاصل کرنے کی اجازت دیتا ہے، پھر نیٹ ورک سے، ردعمل کے وقت کو کم کرتا ہے۔ موبائل ڈویلپمنٹ میں، Google اور Apple کی سفارشات کی بدولت Repository حقیقی معیار بن گیا ہے۔

Remote Data Source اور Local Data Source

Remote Data Source HTTP درخواستوں کے ذریعے سرور سے تازہ ترین معلومات فراہم کرتا ہے۔ Local Data Source ڈیوائس پر مقامی ذخیرہ ہے، جو Android پر Room یا iOS پر SwiftData کے ذریعے نافذ کیا جاتا ہے۔ ریپوزٹری دونوں ذرائع کو یکجا کرتی ہے: پہلے مقامی کیشے چیک کرتی ہے، اور ڈیٹا نہ ہونے پر دور دراز API سے درخواست کرتی ہے۔ ڈیٹا ہینڈلنگ کی یہ تنظیم ایپلیکیشن کو آف لائن موڈ میں کام کرنے کی اجازت دیتی ہے اور سرور کے بوجھ کو کم کرتی ہے۔

Kotlin میں Repository کی مثال

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
    }
}

Swift میں Repository کی مثال

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
    }
}

ڈیٹا کیشنگ: LRU Cache، Disk Cache اور Memory Cache

LRU Cache (Least Recently Used) ایک کیشنگ الگورتھم ہے جہاں، حد تک پہنچنے پر، وہ عنصر ہٹا دیا جاتا ہے جس تک سب سے زیادہ عرصے سے رسائی نہیں کی گئی۔ موبائل ایپلیکیشنز میں، LRU Cache تصاویر، API جوابات اور سیریلائزڈ آبجیکٹ کے لیے استعمال ہوتا ہے۔ مناسب ڈیٹا کیشنگ نیٹ ورک کی درخواستوں کی تعداد کم کرتا ہے اور مواد لوڈنگ کو تیز کرتا ہے۔ موبائل ایپلیکیشنز میں کیشے اعلیٰ کارکردگی کے لیے ایک لازمی جزو ہے۔

Memory Cache بمقابلہ Disk Cache

Memory Cache ڈیٹا کو RAM میں ذخیرہ کرتا ہے — رسائی انتہائی تیز ہے، لیکن گنجائش ایپلیکیشن کے ہیپ سائز سے محدود ہے۔ Disk Cache فائل سسٹم پر معلومات محفوظ کرتا ہے — سست ہے لیکن زیادہ رکھ سکتا ہے اور سیشنز کے درمیان برقرار رہتا ہے۔ موبائل ڈویلپمنٹ میں بہترین حکمت عملی دو سطحی کیشے ہے: گرم ڈیٹا کے لیے Memory Cache اور سرد ڈیٹا کے لیے Disk Cache۔ ڈیٹا کے ساتھ کام کرتے وقت، پہلے میموری میں پہلی سطح کا کیشے چیک کیا جاتا ہے، پھر ڈسک پر دوسری سطح کا کیشے۔

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
    }
}

کیشے باطل کرنے کی حکمت عملی

TTL کیشے (Time To Live) مخصوص وقت کے وقفے کے بعد خود بخود اندراج ہٹا دیتا ہے — API ڈیٹا کے لیے موزوں۔ واقعہ پر مبنی باطل کاری تبدیلیوں کے بارے میں push اطلاع موصول ہونے پر کیشے صاف کرتا ہے۔ موبائل ایپلیکیشنز میں، کیشنگ حکمت عملی کا انتخاب ڈیٹا کی قسم پر منحصر ہے: تصاویر لمبے عرصے تک کیشے ہوتی ہیں، جبکہ خبروں کی فیڈ کو بار بار باطل کرنے کی ضرورت ہوتی ہے۔ Android پر Coil اور iOS پر Kingfisher نے پہلے ہی تصاویر کے ساتھ کام کرنے کے لیے LRU Cache شامل کر لیا ہے۔

آف لائن قطار: Offline Queue اور Sync Manager

Offline Queue ایک ڈیٹا ساخت ہے جو صارف کے آپریشنز (بنانا، اپ ڈیٹ کرنا، حذف کرنا) کو مقامی ڈیٹا بیس میں محفوظ کرتی ہے جب ڈیوائس آف لائن ہو۔ جب کنکشن بحال ہوتا ہے، Sync Manager ان آپریشنز کو ترتیب وار سرور پر لاگو کرتا ہے۔ اس قسم کی ڈیٹا مطابقت پذیری اس بات کو یقینی بناتی ہے کہ عارضی نیٹ ورک نقصان کے دوران کوئی تبدیلی ضائع نہ ہو۔ موبائل ڈویلپمنٹ میں، Offline Queue غیر مستحکم کنکشن والی ایپلیکیشنز کے لیے ایک اہم جزو ہے۔

Offline Queue کا آرکیٹیکچر

قطار Room یا SwiftData میں ایک ٹیبل پر بنائی جاتی ہے جس میں فیلڈز ہوتے ہیں: آپریشن کی قسم، JSON درخواست باڈی، ٹائم اسٹیمپ اور حیثیت۔ Sync Manager ایک پس منظر کی سروس ہے جو زیر التواء آپریشنز پر کارروائی کرتی ہے، انہیں سرور پر بھیجتی ہے، حیثیت کو اپ ڈیٹ کرتی ہے اور کامیاب اندراجات کو حذف کرتی ہے۔ Android پر WorkManager یا iOS پر BGTaskScheduler کے ذریعے ڈیٹا مطابقت پذیری ڈیوائس ریبوٹ کے بعد بھی جاری رہتی ہے۔ مناسب ڈیٹا ہینڈلنگ کے ساتھ Offline Queue کا استعمال ایک ہموار صارف تجربہ کو یقینی بناتا ہے۔

Kotlin میں Offline Queue کی مثال

@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
            }
        }
    }
}

دوبارہ کوشش کی پالیسی اور ٹائم آؤٹ

دوبارہ کوششوں کے درمیان تضاعفی پیچھے ہٹنا (1s، 2s، 4s، 8s) سرور کو بھیڑ سے بچاتا ہے اور لامتناہی کوششوں کو روکتا ہے۔ 5 کوششوں کی حد قطار کے بہاؤ کو روکتی ہے۔ سرور سائیڈ idempotency حمایت کے ساتھ موبائل ایپلیکیشنز میں ڈیٹا مطابقت پذیری، ڈپلیکیٹ سے بچتے ہوئے محفوظ دوبارہ کوشش کی اجازت دیتی ہے۔ یہ خاص طور پر مالی لین دین اور آرڈرز کے لیے اہم ہے۔

ڈیٹا مطابقت پذیری: Conflict Resolution اور Schema Migration

Conflict Resolution ان حالات کے لیے حکمت عملیوں کا ایک مجموعہ ہے جہاں ایک ہی ڈیٹا مختلف آلات پر بیک وقت تبدیل کیا جاتا ہے۔ بنیادی ڈیٹا مطابقت پذیری کے لیے ایک طریقہ منتخب کرنے کی ضرورت ہوتی ہے: Last-Write-Wins (آخری تحریر جیتتی ہے)، ورژننگ (اونچا ورژن جیتتا ہے) یا دستی حل۔ پیچیدہ منظرناموں میں، CRDT (Conflict-Free Replicated Data Types) استعمال کیے جاتے ہیں، جو ڈیٹا کے ریاضیاتی ہم آہنگی کی ضمانت دیتے ہیں۔

تنازعات حل کرنے کی حکمت عملی

Last-Write-Wins لاگو کرنے میں سب سے آسان ہے لیکن صارف کی تبدیلیاں کھو سکتی ہے۔ Version Vector — ہر ریکارڈ ایک ورژن نمبر اور ڈیوائس شناخت کنندہ محفوظ کرتا ہے؛ ورژن مماثل نہ ہونے پر تنازع پیدا ہوتا ہے۔ CRDT سب سے زیادہ قابل اعتماد لیکن پیچیدہ حکمت عملی ہے: ڈیٹا مرکزی کوآرڈینیٹر کے بغیر ریاضیاتی طور پر ایک حالت میں اکٹھا ہو جاتا ہے۔ CRDT پر مبنی موبائل ایپلیکیشنز میں ڈیٹا مطابقت پذیری Google Docs میں باہمی تعاون سے ترمیم اور Notion نوٹ مطابقت پذیری میں استعمال ہوتی ہے۔

Schema Migration: محفوظ ڈیٹا بیس اپ ڈیٹ

جب کوئی ایپلیکیشن اپ ڈیٹ ہوتی ہے، مقامی ڈیٹا بیس کی ساخت تبدیل ہوتی ہے: کالم، ٹیبلز، انڈیکس شامل کیے جاتے ہیں۔ Schema Migration ڈیٹا کے نقصان کے بغیر موجودہ ڈیٹا بیس کو نئے اسکیما میں تبدیل کرنے کا عمل ہے۔ Room پرانے اور نئے ورژن کے ساتھ Migration کلاس کے ذریعے منتقلی کی حمایت کرتا ہے۔ SwiftData تبدیلیاں بیان کرنے کے لیے VersionedSchema استعمال کرتا ہے۔ ایپلیکیشن ورژنز کے درمیان مناسب ڈیٹا مطابقت پذیری کے لیے ضروری ہے کہ منتقلیوں کو idempotent طریقے سے ٹیسٹ کیا جائے۔

Room میں Schema Migration کی مثال

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
}

Swift میں Conflict Resolution کی مثال

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 اور SwiftData

Room Android پر مقامی ذخیرہ کرنے کے لیے Google کی لائبریری ہے، SQLite کے اوپر بنائی گئی ہے اور اعلانیہ استفسار کی وضاحت کے لیے تشریحات فراہم کرتی ہے۔ SwiftData iOS، macOS، watchOS اور visionOS کے لیے Apple کا فریم ورک ہے، Core Data کا جانشین جس میں مختصر Swift Macro نحو ہے۔ دونوں اوزار ڈیوائس پر ڈیٹا کے ساتھ کام کرنے کے کام کو حل کرتے ہیں، لیکن کوڈ تنظیم کے لیے مختلف طریقوں کے ساتھ۔ موبائل ایپلیکیشنز میں کیشے اکثر انہی ٹیکنالوجیز پر بنایا جاتا ہے۔

Room: DAO، Entities اور Type Converters

Room ٹیبلز کے لیے @Entity تشریحات اور استفسار کے لیے @Dao استعمال کرتا ہے۔ DAO کمپائل ٹائم جانچ کے ساتھ تمام SQL آپریشنز کو سمیٹتا ہے — SQL نحو کی غلطیاں رن ٹائم سے پہلے پکڑی جاتی ہیں۔ Type Converter پیچیدہ اقسام (Date, List) کو SQLite بنیادی اقسام میں تبدیل کرتا ہے۔ Android ایپلیکیشنز میں جدید ڈیٹا ہینڈلنگ Room + Flow کے ارد گرد بنائی گئی ہے، جو کیشے یا مقامی ڈیٹا بیس تبدیل ہونے پر رد عمل UI اپ ڈیٹ فراہم کرتی ہے۔

SwiftData: @Model اور @Query

SwiftData ہستیوں کی تعریف کے لیے میکرو @Model اور ڈیٹا کا مشاہدہ کرنے کے لیے @Query استعمال کرتا ہے۔ فریم ورک خود بخود انحصار کو ٹریک کرتا ہے اور تبدیلیوں پر انٹرفیس اپ ڈیٹ کرتا ہے۔ اسکیما منتقلی تمام ورژنز کو بیان کرنے والا VersionedSchema استعمال کرتی ہے۔ SwiftData اور سرور کے درمیان ڈیٹا مطابقت پذیری @Query کے ذریعے اپ ڈیٹس کو سبسکرائب کرنے والے کسٹم Sync Manager کے ذریعے نافذ کی جاتی ہے۔

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()
    }
}

Room بمقابلہ SwiftData موازنہ