WorkManager — یہ کیا ہے، API اور کاموں کی شیڈولنگ

WorkManager کیسے کام کرتا ہے؟

WorkManager کا آرکیٹیکچر تین بنیادی کلاسز کے گرد بنایا گیا ہے: Worker، WorkRequest اور WorkManager۔ Worker میں کام کی منطق ہوتی ہے، WorkRequest عملدرآمد کے پیرامیٹرز کو بیان کرتا ہے، اور WorkManager قطار اور شیڈولنگ کا انتظام کرتا ہے۔ لائبریری تمام کاموں کی حالت کو ذخیرہ کرنے کے لیے ایک اندرونی Room ڈیٹابیس استعمال کرتی ہے۔

Worker اور WorkRequest

Worker ایک تجریدی کلاس ہے جس میں ایک واحد طریقہ doWork ہے جو پس منظر کے تھریڈ پر کال کیا جاتا ہے۔ طریقہ ListenableWorker.Result — SUCCESS، FAILURE یا RETRY لوٹاتا ہے۔ WorkRequest Worker کو پیرامیٹرز: ٹائم آؤٹ، ٹیگ، ابتدائی تاخیر اور پابندیوں سے جوڑتا ہے۔

class SyncWorker(
    context: Context,
    params: WorkerParameters
) : Worker(context, params) {

    override fun doWork(): Result {
        return try {
            val api = RetrofitClient.api
            val response = api.syncData()
            Result.success()
        } catch (e: Exception) {
            Result.retry()
        }
    }
}

WorkManager کے ذریعے شیڈولنگ

WorkManager Android ورژن سے قطع نظر یکساں طور پر کاموں کو شیڈول کرتا ہے۔ enqueue کال کرنے پر، لائبریری کام کو Room میں محفوظ کرتی ہے، موجودہ حالات کا جائزہ لیتی ہے، اور عملدرآمد کا بہترین وقت منتخب کرتی ہے۔ پردے کے پیچھے، یہ JobScheduler، AlarmManager یا اپنا شیڈیولر استعمال کر سکتا ہے — ڈویلپر کو اس کے بارے میں فکر کرنے کی ضرورت نہیں ہے۔

val syncRequest = OneTimeWorkRequestBuilder<SyncWorker>()
    .setInitialDelay(15, TimeUnit.MINUTES)
    .addTag("sync")
    .build()

WorkManager.getInstance(context)
    .enqueue(syncRequest)

WorkRequest کی اقسام

WorkManager دو قسم کی عملدرآمد کی درخواستوں کو سپورٹ کرتا ہے: ایک بار اور متواتر۔ قسم کا انتخاب منظر نامے پر منحصر ہے: کام ایک بار چلنا چاہیے یا دیے گئے وقفے پر دہرایا جانا چاہیے۔

OneTimeWorkRequest

OneTimeWorkRequest ان کاموں کے لیے ڈیزائن کیا گیا ہے جو ایک بار انجام پانے چاہئیں۔ یہ لاگ جمع کروانا، تصدیق کے بعد ڈیٹا سنکرونائزیشن، پہلی لانچ پر کنفیگریشن ڈاؤن لوڈ ہو سکتا ہے۔ تاخیر setInitialDelay کے ذریعے اور پابندیاں setConstraints کے ذریعے سیٹ کی جاتی ہیں۔

PeriodicWorkRequest

PeriodicWorkRequest کم از کم 15 منٹ کے وقفے کے ساتھ دہرائے جانے والے کاموں کے لیے موزوں ہے۔ لائبریری ضمانت دیتی ہے کہ رنز کے درمیان وقفہ متعین سے کم نہیں ہوگا، لیکن آلے کی پابندیوں کی وجہ سے زیادہ ہو سکتا ہے۔ 15 منٹ سے کم فریکوئنسی والے کاموں کے لیے، Foreground Service میں Handler یا Timer استعمال کریں۔

پابندیاں ترتیب دینا اور کاموں کی زنجیریں

WorkManager میں پابندیاں آپ کو وہ شرائط طے کرنے کی اجازت دیتی ہیں جن کے تحت کوئی کام شروع کیا جا سکتا ہے: نیٹ ورک کنیکٹیویٹی (NetworkType)، بیٹری لیول (batteryNotLow)، اسٹوریج کی حالت (StorageNotLow) اور بیکار موڈ (DeviceIdle)。 جب تک تمام پابندیاں پوری نہیں ہو جاتیں، کام شروع نہیں ہوگا۔

val constraints = Constraints.Builder()
    .setRequiredNetworkType(NetworkType.CONNECTED)
    .setRequiresCharging(true)
    .setRequiresBatteryNotLow(true)
    .build()

val request = OneTimeWorkRequestBuilder<ImageUploadWorker>()
    .setConstraints(constraints)
    .build()

زنجیریں آپ کو کاموں کے ترتیب وار یا متوازی عملدرآمد کو منظم کرنے کی اجازت دیتی ہیں۔ beginWith ایک زنجیر شروع کرتا ہے، then اگلا Worker شامل کرتا ہے جو پچھلے کے کامیاب مکمل ہونے کے بعد عمل میں آئے گا۔ متوازی عملدرآمد کے لیے، workManager.enqueue(listOf(request1, request2)) استعمال کریں۔

WorkManager.getInstance(context)
    .beginWith(compressWorker)
    .then(uploadWorker)
    .then(cleanupWorker)
    .enqueue()
    // compress -> upload -> cleanup ترتیب وار

JobScheduler سے WorkManager میں منتقلی

JobScheduler Android 5 (API 21) میں پس منظر کے کاموں کو شیڈول کرنے کے لیے ایک سسٹم سروس کے طور پر متعارف کرایا گیا تھا۔ WorkManager اسے بدلنے کے لیے آیا، خودکار منتقلی اور اضافی صلاحیتوں کے ساتھ ایک کراس پلیٹ فارم API پیش کرتا ہے: زنجیریں، عملدرآمد کی ضمانت، ٹیگز، LiveData کے ذریعے حالت کی نگرانی۔

JobScheduler سے WorkManager میں منتقلی کرتے وقت، آپ کو JobService کو Worker میں تبدیل کرنا ہوگا، JobInfo کو WorkRequest سے اور Context.getSystemService کو WorkManager API سے بدلنا ہوگا۔ WorkManager خود بخود مطابقت کے مسائل کو حل کرتا ہے اور دستی JobScheduler نفاذ کے مقابلے Doze Mode کو زیادہ درست طریقے سے ہینڈل کرتا ہے۔ منتقلی کے مراحل: 1) Worker کلاس بنائیں، 2) انہی شرائط کے ساتھ WorkRequest بنائیں، 3) کوڈ اور مینی فیسٹ سے JobService اور JobInfo ہٹا دیں۔

منفرد کاموں کے لیے UniqueWork

WorkManager ExistingWorkPolicy کے ذریعے منفرد کاموں کے تصور کو سپورٹ کرتا ہے۔ اگر متعین نام کا کوئی کام پہلے سے موجود ہے، تو پالیسی رویے کا تعین کرتی ہے: KEEP (نیا نہ بنائیں)، REPLACE (موجودہ کو بدلیں)، APPEND (زنجیر کے آخر میں شامل کریں) اور APPEND_OR_REPLACE۔ UniqueWorkRequest ان کاموں کے لیے آسان ہے جو ڈپلیکیٹ نہیں ہونے چاہئیں: ڈیٹابیس سنکرونائزیشن، کنفیگریشن ڈاؤن لوڈ، تجزیات کا بیچ جمع کروانا۔

WorkManager.getInstance(context)
    .enqueueUniqueWork(
        "sync_data",
        ExistingWorkPolicy.KEEP,
        syncRequest
    )

پیشرفت اور درمیانی نتائج کا انتظام

CoroutineWorker setProgress میکانزم کو سپورٹ کرتا ہے، جو درمیانی عملدرآمد کے نتائج کو منتقل کرنے کی اجازت دیتا ہے۔ یہ طویل مدتی آپریشنز کے لیے مفید ہے: بڑی فائل ڈاؤن لوڈ، بیچ امیج پروسیسنگ، ڈیٹابیس مائیگریشن۔ UI getWorkInfosByTagLiveData کے ذریعے اپ ڈیٹس کو سبسکرائب کر سکتا ہے اور ریئل ٹائم پیشرفت ڈسپلے کر سکتا ہے۔ ForegroundInfo طریقہ ایک نوٹیفکیشن کے ساتھ Worker کو Foreground Service کے طور پر چلانے کے لیے بھی دستیاب ہے اگر کام صارف کو دکھائی دینا چاہیے۔

class ProgressWorker(
    context: Context,
    params: WorkerParameters
) : CoroutineWorker(context, params) {

    override suspend fun doWork(): Result {
        val total = 100
        for (i in 1..total) {
            setProgress(
                workDataOf("progress" to i)
            )
        }
        return Result.success()
    }
}

ڈیٹا کی منتقلی کے لیے InputData اور OutputData

WorkManager InputData اور OutputData کے ذریعے Workers کے درمیان ڈیٹا کی منتقلی کو سپورٹ کرتا ہے۔ InputData Data.Builder کے ذریعے WorkRequest کی تعمیر کے دوران بنایا جاتا ہے اور inputData کے ذریعے Worker کو پہنچایا جاتا ہے۔ عملدرآمد کے بعد، Worker workDataOf یا Data.Builder کے ذریعے OutputData بناتا ہے اور Result.success(outputData) کے ساتھ لوٹاتا ہے۔ زنجیر میں اگلا Worker پچھلے کا outputData اپنے inputData کے طور پر وصول کرتا ہے۔ ڈیٹا بنیادی اقسام: String, Int, Long, Boolean, Double کی سپورٹ کے ساتھ کلید-قدر کی شکل میں محفوظ کیا جاتا ہے۔ ڈیٹا کا زیادہ سے زیادہ سائز 10 KB ہے۔

عملی طور پر، بہت سے پروجیکٹ WorkManager کو واحد پس منظر کے کام شیڈیولر کے طور پر استعمال کرتے ہیں۔ Google تمام موجودہ JobService کو WorkManager میں منتقل کرنے کی تجویز کرتا ہے، خاص طور پر ان ایپس میں جو Android 4.4 (API 19) اور اس سے نیچے کو سپورٹ کرتی ہیں، جہاں JobScheduler دستیاب نہیں ہے اور WorkManager AlarmManager اور BroadcastReceiver کے ذریعے بیک اپ میکانزم استعمال کرتا ہے۔ جانچ کے لیے، WorkManager TestListenableWorkerBuilder اور TestWorkerBuilder فراہم کرتا ہے، جو حقیقی شیڈیولر کے بغیر JUnit ٹیسٹوں میں Workers کی جانچ کرنے کی اجازت دیتے ہیں۔