কাজের অনুরোধের সংজ্ঞা দিন

শুরু করার নির্দেশিকা থেকে আপনি জানতে পেরেছেন কীভাবে WorkRequest তৈরি করতে হয় এবং সেটিকে সারিতে যোগ করতে হয়।

এই গাইডে আপনি শিখবেন কীভাবে সাধারণ ব্যবহারের ক্ষেত্রে WorkRequest অবজেক্টগুলি সংজ্ঞায়িত এবং কাস্টমাইজ করতে হয়, যেমন কীভাবে:

• একবার ও বারবার করা কাজের শিডিউল করুন
• ওয়াই-ফাই বা চার্জিংয়ের মতো কাজের সীমাবদ্ধতা সেট করুন
• কাজ এক্সিকিউট করার ক্ষেত্রে ন্যূনতম বিলম্বের গ্যারেন্টি দিন
• আবার চেষ্টা করা এবং ব্যাক-অফ স্ট্র্যাটেজি সেট করা
• কাজ করার জন্য ইনপুট ডেটা পাস করুন
• ট্যাগ ব্যবহার করে সম্পর্কিত কাজ একসাথে গ্রুপ করুন

এক নজরে

WorkManager-এ WorkRequest ব্যবহার করে কাজকে সংজ্ঞায়িত করা হয়। WorkManager-এর মাধ্যমে কোনও কাজ শিডিউল করতে হলে, আপনাকে প্রথমে একটি WorkRequest অবজেক্ট তৈরি করতে হবে এবং তারপর এটি এনকিউ করতে হবে।

val myWorkRequest = ...
WorkManager.getInstance(myContext).enqueue(myWorkRequest)

WorkRequest myWorkRequest = ...
WorkManager.getInstance(myContext).enqueue(myWorkRequest);

WorkRequest অবজেক্টে WorkManager-এর জন্য প্রয়োজনীয় সব তথ্য থাকে যা আপনার কাজ শিডিউল ও রান করতে সাহায্য করে। আপনার কাজ চালানোর জন্য যেসব বাধ্যবাধকতা পূরণ করতে হবে, শিডিউল সংক্রান্ত তথ্য যেমন দেরি বা পুনরাবৃত্তির ব্যবধান, আবার চেষ্টা করার কনফিগারেশন এবং আপনার কাজ যদি ইনপুট ডেটার উপর নির্ভর করে তাহলে সেটিও এর মধ্যে অন্তর্ভুক্ত থাকে।

WorkRequest নিজেই একটি অ্যাবস্ট্রাক্ট মূল ক্লাস। এই ক্লাসের দুটি ডেরাইভড ইমপ্লিমেন্টেশন আছে যা আপনি অনুরোধ তৈরি করতে ব্যবহার করতে পারেন, OneTimeWorkRequest এবং PeriodicWorkRequest। নাম থেকেই বোঝা যায়, OneTimeWorkRequest-এর মাধ্যমে রিপিট হয় না এমন কাজ শিডিউল করা যায়, অন্যদিকে PeriodicWorkRequest-এর মাধ্যমে নির্দিষ্ট সময় অন্তর রিপিট হয় এমন কাজ শিডিউল করা যায়।

এককালীন কাজ শিডিউল করুন

প্রাথমিক কাজের জন্য, যার জন্য কোনও অতিরিক্ত কনফিগারেশনের প্রয়োজন নেই, স্ট্যাটিক পদ্ধতি from ব্যবহার করুন:

val myWorkRequest = OneTimeWorkRequest.from(MyWork::class.java)

WorkRequest myWorkRequest = OneTimeWorkRequest.from(MyWork.class);

আরও জটিল কাজের জন্য, আপনি বিল্ডার ব্যবহার করতে পারেন:

val uploadWorkRequest: WorkRequest =
   OneTimeWorkRequestBuilder<MyWork>()
       // Additional configuration
       .build()

WorkRequest uploadWorkRequest =
   new OneTimeWorkRequest.Builder(MyWork.class)
       // Additional configuration
       .build();

জরুরি ভিত্তিক কাজ শিডিউল করা

WorkManager 2.7.0-এ জরুরি ভিত্তিক কাজের ধারণা প্রথম নিয়ে আসা হয়। এটি WorkManager-কে গুরুত্বপূর্ণ কাজ করতে দেয় এবং সিস্টেমকে রিসোর্স অ্যাক্সেসের উপর আরও ভালো নিয়ন্ত্রণ প্রদান করে।

জরুরি ভিত্তিক কাজের নিম্নলিখিত বৈশিষ্ট্যগুলি উল্লেখযোগ্য:

• গুরুত্ব: জরুরি ভিত্তিক কাজ সেইসব টাস্কের জন্য উপযুক্ত যা ব্যবহারকারীর কাছে গুরুত্বপূর্ণ অথবা ব্যবহারকারী শুরু করেছেন।
• স্পিড: জরুরি ভিত্তিক কাজ ছোটখাটো টাস্কের জন্য সবচেয়ে উপযুক্ত যা অবিলম্বে শুরু হয় এবং কয়েক মিনিটের মধ্যে সম্পূর্ণ হয়।
• কোটা: সিস্টেম-লেভেল কোটা যা ফোরগ্রাউন্ড এক্সিকিউশন টাইম সীমিত করে জরুরি ভিত্তিক কাজ শুরু করা যাবে কিনা তা নির্ধারণ করে।
• পাওয়ার ম্যানেজমেন্ট: পাওয়ার ম্যানেজমেন্ট সংক্রান্ত বিধিনিষেধ, যেমন ব্যাটারি সেভার ও ডোজ, জরুরি ভিত্তিক কাজের উপর প্রভাব ফেলার সম্ভাবনা কম।
• লেটেন্সি: সিস্টেমের বর্তমান ওয়ার্কলোড অনুমতি দিলে, সিস্টেম অবিলম্বে জরুরি ভিত্তিক কাজ সম্পাদন করে। এর অর্থ হল, এগুলি লেটেন্সি সংবেদনশীল এবং পরে কার্যকর করার জন্য শিডিউল করা যায় না।

জরুরি ভিত্তিক কাজের একটি সম্ভাব্য ব্যবহারের উদাহরণ হতে পারে কোনও চ্যাট অ্যাপের মধ্যে যখন ব্যবহারকারী কোনও মেসেজ বা অ্যাটাচ করা ছবি পাঠাতে চান। একইভাবে, পেমেন্ট বা সাবস্ক্রিপশন ফ্লো ম্যানেজ করে এমন অ্যাপও জরুরি ভিত্তিক কাজ ব্যবহার করতে চাইতে পারে। কারণ, এইসব টাস্ক ব্যবহারকারীর জন্য গুরুত্বপূর্ণ, ব্যাকগ্রাউন্ডে দ্রুত এক্সিকিউট হয়, অবিলম্বে শুরু করতে হয় এবং ব্যবহারকারী অ্যাপ বন্ধ করে দিলেও এক্সিকিউট হওয়া চালিয়ে যেতে হয়

কোটা

জরুরি ভিত্তিক কাজ চালানোর আগে সিস্টেমকে অবশ্যই তার জন্য এক্সিকিউশন টাইম বরাদ্দ করতে হবে। এক্সিকিউশনের সময় আনলিমিটেড নয়। বরং, প্রতিটি অ্যাপ এক্সিকিউশন টাইমের কোটা পায়। আপনার অ্যাপ এক্সিকিউশন টাইম ব্যবহার করে এবং বরাদ্দ করা কোটায় পৌঁছে গেলে, কোটা রিফ্রেশ না হওয়া পর্যন্ত আপনি আর জরুরি ভিত্তিক কাজ এক্সিকিউট করতে পারবেন না। এটি Android-কে আরও কার্যকরভাবে অ্যাপ্লিকেশনগুলির মধ্যে রিসোর্স ব্যালেন্স করতে অনুমতি দেয়।

কোনও অ্যাপের জন্য উপলভ্য এক্সিকিউশন টাইম, স্ট্যান্ডবাই বাকেট এবং প্রসেসের গুরুত্বের উপর নির্ভর করে।

এক্সিকিউশন কোটা কোনও জরুরি ভিত্তিক কাজকে অবিলম্বে রান করার অনুমতি না দিলে কী ঘটবে তা আপনি নির্ধারণ করতে পারেন। বিস্তারিত জানতে নিম্নলিখিত স্নিপেট দেখুন।

জরুরি ভিত্তিক কাজ এক্সিকিউট করুন

WorkManager 2.7 থেকে শুরু করে, আপনার অ্যাপ setExpedited()-কে কল করে ঘোষণা করতে পারে যে জরুরি ভিত্তিক কাজ ব্যবহার করে যত তাড়াতাড়ি সম্ভব WorkRequest চালানো উচিত। নিচে দেওয়া কোড স্নিপেট থেকে setExpedited() কীভাবে ব্যবহার করতে হয় তার উদাহরণ দেওয়া হয়েছে:

val request = OneTimeWorkRequestBuilder<SyncWorker>()
    <b>.setExpedited(OutOfQuotaPolicy.RUN_AS_NON_EXPEDITED_WORK_REQUEST)</b>
    .build()

WorkManager.getInstance(context)
    .enqueue(request)

OneTimeWorkRequest request = new OneTimeWorkRequestBuilder<T>()
    .setInputData(inputData)
    <b>.setExpedited(OutOfQuotaPolicy.RUN_AS_NON_EXPEDITED_WORK_REQUEST)</b>
    .build();

এই উদাহরণে, আমরা OneTimeWorkRequest-এর একটি ইনস্ট্যান্স শুরু করি এবং এতে setExpedited() কল করি। এই অনুরোধ তখন জরুরি ভিত্তিক কাজ হয়ে যায়। কোটা অনুমতি দিলে, এটি অবিলম্বে ব্যাকগ্রাউন্ডে চলতে শুরু করবে। কোটা ব্যবহার করা হয়ে গেলে, OutOfQuotaPolicy প্যারামিটার ইঙ্গিত করে যে অনুরোধটি স্বাভাবিক, জরুরি ভিত্তিক নয় এমন কাজ হিসেবে চালানো উচিত।

ব্যাকওয়ার্ড কম্প্যাটিবিলিটি ও ফোরগ্রাউন্ড পরিষেবা

জরুরি ভিত্তিক কাজের জন্য ব্যাকওয়ার্ড কম্প্যাটিবিলিটি বজায় রাখতে, WorkManager, Android 12-এর থেকে পুরনো প্ল্যাটফর্ম ভার্সনে ফোরগ্রাউন্ড সার্ভিস চালাতে পারে। ফোরগ্রাউন্ড সার্ভিস ব্যবহারকারীকে বিজ্ঞপ্তি দেখাতে পারে।

আপনার Worker-এ getForegroundInfoAsync() এবং getForegroundInfo() পদ্ধতি Android 12-এর আগে setExpedited() কল করার সময় WorkManager-কে বিজ্ঞপ্তি দেখানোর অনুমতি দেয়।

আপনি যদি টাস্কটি জরুরি ভিত্তিক কাজ হিসেবে চালানোর অনুরোধ করতে চান, তাহলে যেকোনও ListenableWorker-কে অবশ্যই getForegroundInfo পদ্ধতি প্রয়োগ করতে হবে।

Android 12 বা তার পরবর্তী যেকোনও ভার্সন টার্গেট করার সময়, সংশ্লিষ্ট setForeground পদ্ধতির মাধ্যমে ফোরগ্রাউন্ড পরিষেবা আপনার জন্য উপলভ্য থাকে।

ওয়ার্কার

কর্মীরা জানেন না যে তারা যে কাজ করছেন তা দ্রুত করা হচ্ছে কিনা। তবে, WorkRequest দ্রুত করা হলে, Android-এর কিছু ভার্সনে কর্মীরা বিজ্ঞপ্তি দেখাতে পারেন।

এটি চালু করতে, WorkManager getForegroundInfoAsync() পদ্ধতি প্রদান করে, যা আপনাকে অবশ্যই প্রয়োগ করতে হবে যাতে WorkManager আপনার জন্য প্রয়োজন হলে ForegroundService শুরু করার জন্য একটি বিজ্ঞপ্তি দেখাতে পারে।

CoroutineWorker

আপনি CoroutineWorker ব্যবহার করলে, আপনাকে অবশ্যই getForegroundInfo() প্রয়োগ করতে হবে। আপনি তারপরে doWork()-এর মধ্যে setForeground()-এ এটি পাস করুন। এটি করলে Android 12-এর আগের ভার্সনে বিজ্ঞপ্তি তৈরি হবে।

নিম্নলিখিত উদাহরণ বিবেচনা করে দেখুন:

  class ExpeditedWorker(appContext: Context, workerParams: WorkerParameters):
   CoroutineWorker(appContext, workerParams) {

   override suspend fun getForegroundInfo(): ForegroundInfo {
       return ForegroundInfo(
           NOTIFICATION_ID, createNotification()
       )
   }

   override suspend fun doWork(): Result {
       TODO()
   }

    private fun createNotification() : Notification {
       TODO()
    }

}

কোটা সংক্রান্ত নীতি

আপনার অ্যাপ এক্সিকিউশন কোটায় পৌঁছে গেলে, জরুরি ভিত্তিক কাজের ক্ষেত্রে কী হবে তা আপনি নিয়ন্ত্রণ করতে পারবেন। চালিয়ে যেতে, আপনি setExpedited() পাস করতে পারেন:

• OutOfQuotaPolicy.RUN_AS_NON_EXPEDITED_WORK_REQUEST, যার ফলে জবটি সাধারণ কাজের অনুরোধ হিসেবে রান করে। আগের স্নিপেট এটি দেখায়।
• OutOfQuotaPolicy.DROP_WORK_REQUEST, যার ফলে পর্যাপ্ত কোটা না থাকলে অনুরোধ বাতিল হয়ে যায়।

জরুরি ভিত্তিক কাজ স্থগিত করা হয়েছে

কোনও জরুরি ভিত্তিক কাজ শুরু করার পরে সিস্টেম যত তাড়াতাড়ি সম্ভব সেটি সম্পূর্ণ করার চেষ্টা করে। তবে, অন্যান্য ধরনের কাজের ক্ষেত্রে যেমন হয়, সিস্টেম নতুন জরুরি ভিত্তিক কাজ শুরু করতে দেরি করতে পারে, যেমন নিম্নলিখিত ক্ষেত্রে:

• লোড: সিস্টেম লোড খুব বেশি, যা অনেক বেশি কাজ ইতিমধ্যেই চলছে, বা সিস্টেমে পর্যাপ্ত মেমরি না থাকলে হতে পারে।
• কোটা: জরুরি ভিত্তিক কাজের কোটার সীমা পেরিয়ে গেছে। জরুরি ভিত্তিক কাজ একটি কোটা সিস্টেম ব্যবহার করে যা অ্যাপ স্ট্যান্ডবাই বাকেটের উপর ভিত্তি করে এবং একটি রোলিং টাইম উইন্ডোর মধ্যে সর্বাধিক এক্সিকিউশন সময়কে সীমিত করে। জরুরি ভিত্তিক কাজের জন্য ব্যবহৃত কোটা অন্যান্য ধরনের ব্যাকগ্রাউন্ড কাজের জন্য ব্যবহৃত কোটার চেয়ে বেশি বিধিনিষেধযুক্ত।

নির্দিষ্ট সময় অন্তর কাজ শিডিউল করুন

আপনার অ্যাপের ক্ষেত্রে মাঝে মাঝে নির্দিষ্ট কিছু কাজ নির্দিষ্ট সময় অন্তর করার প্রয়োজন হতে পারে। যেমন, আপনি হয়ত নির্দিষ্ট সময় অন্তর আপনার ডেটার ব্যাক-আপ নিতে, আপনার অ্যাপে নতুন কন্টেন্ট ডাউনলোড করতে বা সার্ভারে লগ আপলোড করতে চান।

আপনি কীভাবে PeriodicWorkRequest ব্যবহার করে একটি WorkRequest অবজেক্ট তৈরি করবেন যা নির্দিষ্ট সময় অন্তর কাজ করে:

val saveRequest =
       PeriodicWorkRequestBuilder<SaveImageToFileWorker>(1, TimeUnit.HOURS)
    // Additional configuration
           .build()

PeriodicWorkRequest saveRequest =
       new PeriodicWorkRequest.Builder(SaveImageToFileWorker.class, 1, TimeUnit.HOURS)
           // Constraints
           .build();

এই উদাহরণে, এক ঘণ্টা অন্তর কাজ শিডিউল করা হয়েছে।

বিরতির সময়কালকে পুনরাবৃত্তির মধ্যে ন্যূনতম সময় হিসাবে সংজ্ঞায়িত করা হয়। The exact time that the worker is going to be executed depends on the constraints that you are using in your WorkRequest object and on the optimizations performed by the system.

পরিবর্তন করা যায় এমন রান ইন্টারভাল

আপনার কাজের ধরন যদি এমন হয় যে, সেটি রান করার সময় সংবেদনশীল, তাহলে আপনি প্রতিটি ইন্টারভ্যাল পিরিয়ডের মধ্যে ফ্লেক্স পিরিয়ডে রান করার জন্য আপনার PeriodicWorkRequest কনফিগার করতে পারেন, যেমনটি ১ নম্বর চিত্রে দেখানো হয়েছে।

ছবি ১. ডায়াগ্রামে ফ্লেক্সিবল সময়সীমা সহ রিপিট করা ইন্টারভ্যাল দেখানো হয়েছে, যার মধ্যে কাজ চালানো যেতে পারে।

ফ্লেক্স পিরিয়ড সহ পর্যায়ক্রমিক কাজ নির্ধারণ করতে, PeriodicWorkRequest তৈরি করার সময় আপনি repeatInterval-এর সাথে flexInterval পাস করেন। ফ্লেক্স পিরিয়ড repeatInterval - flexInterval-এ শুরু হয় এবং ইন্টারভ্যালের শেষ পর্যন্ত চলে।

নিম্নলিখিতটি হল পর্যায়ক্রমিক কাজের একটি উদাহরণ যা প্রতি এক ঘণ্টার শেষ ১৫ মিনিটে রান করতে পারে।

val myUploadWork = PeriodicWorkRequestBuilder<SaveImageToFileWorker>(
       1, TimeUnit.HOURS, // repeatInterval (the period cycle)
       15, TimeUnit.MINUTES) // flexInterval
    .build()

WorkRequest saveRequest =
       new PeriodicWorkRequest.Builder(SaveImageToFileWorker.class,
               1, TimeUnit.HOURS,
               15, TimeUnit.MINUTES)
           .build();

রিপিট ইন্টারভ্যাল অবশ্যই PeriodicWorkRequest.MIN_PERIODIC_INTERVAL_MILLIS-এর থেকে বেশি বা সমান হতে হবে এবং ফ্লেক্স ইন্টারভ্যাল অবশ্যই PeriodicWorkRequest.MIN_PERIODIC_FLEX_MILLIS`-এর থেকে বেশি বা সমান হতে হবে।

পর্যায়ক্রমিক কাজের উপর সীমাবদ্ধতার প্রভাব

আপনি নির্দিষ্ট সময় অন্তর করা কাজের ক্ষেত্রে সীমাবদ্ধতা প্রয়োগ করতে পারবেন। যেমন, আপনি কাজের অনুরোধে একটি সীমাবদ্ধতা যোগ করতে পারেন যাতে ব্যবহারকারীর ডিভাইস চার্জ করার সময়ই কাজটি চলে। এই ক্ষেত্রে, নির্দিষ্ট করা রিপিট ইন্টারভ্যাল পেরিয়ে গেলেও, এই শর্ত পূরণ না হওয়া পর্যন্ত PeriodicWorkRequest রান করবে না। এর ফলে আপনার কাজের কোনও নির্দিষ্ট রান দেরি হতে পারে, এমনকি রান ইন্টারভ্যালের মধ্যে শর্ত পূরণ না হলে সেটি বাদও যেতে পারে।

কাজের বাধ্যবাধকতা

Constraints নিশ্চিত করুন যে অনুকূল পরিস্থিতি না হওয়া পর্যন্ত কাজ স্থগিত রাখা হয়েছে। WorkManager-এ নিম্নলিখিত কনস্ট্রেন্ট উপলভ্য:

বাধ্যবাধকতার সেট তৈরি করতে এবং কিছু কাজের সাথে এটি যুক্ত করতে, Constraints.Builder() ব্যবহার করে Constraints ইনস্ট্যান্স তৈরি করুন এবং এটি আপনার WorkRequest.Builder()-এ অ্যাসাইন করুন।

যেমন, নিম্নলিখিত কোডটি একটি কাজের অনুরোধ তৈরি করে যা শুধুমাত্র তখনই চলে যখন ব্যবহারকারীর ডিভাইস চার্জ হচ্ছে এবং ওয়াই-ফাই চালু আছে:

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

val myWorkRequest: WorkRequest =
   OneTimeWorkRequestBuilder<MyWork>()
       .setConstraints(constraints)
       .build()

Constraints constraints = new Constraints.Builder()
       .setRequiredNetworkType(NetworkType.UNMETERED)
       .setRequiresCharging(true)
       .build();

WorkRequest myWorkRequest =
       new OneTimeWorkRequest.Builder(MyWork.class)
               .setConstraints(constraints)
               .build();

একাধিক সীমাবদ্ধতা নির্দিষ্ট করা থাকলে, সব সীমাবদ্ধতা পূরণ হলে তবেই আপনার কাজ রান করবে।

আপনার কাজ চলাকালীন কোনও সীমাবদ্ধতা পূরণ না হলে, WorkManager আপনার ওয়ার্কারকে থামিয়ে দেবে। সব সীমাবদ্ধতা পূরণ হলে, কাজটি আবার করার চেষ্টা করা হবে।

দেরিতে হওয়া কাজ

আপনার কাজের ক্ষেত্রে কোনও সীমাবদ্ধতা না থাকলে বা আপনার কাজ সারিবদ্ধ করার সময় সমস্ত সীমাবদ্ধতা পূরণ হলে, সিস্টেম অবিলম্বে কাজটি চালানোর জন্য বেছে নিতে পারে। আপনি যদি কাজটি অবিলম্বে চালাতে না চান, তাহলে আপনি নির্দিষ্ট করতে পারেন আপনার কাজ ন্যূনতম প্রাথমিক বিলম্বের পরে শুরু হবে।

আপনার কাজ এনকিউ করার পরে অন্তত ১০ মিনিট চালানোর জন্য কীভাবে সেট করবেন তার একটি উদাহরণ এখানে দেওয়া হল।

val myWorkRequest = OneTimeWorkRequestBuilder<MyWork>()
   .setInitialDelay(10, TimeUnit.MINUTES)
   .build()

WorkRequest myWorkRequest =
      new OneTimeWorkRequest.Builder(MyWork.class)
               .setInitialDelay(10, TimeUnit.MINUTES)
               .build();

উদাহরণে দেখানো হয়েছে যে কীভাবে OneTimeWorkRequest-এর জন্য প্রাথমিক বিলম্ব সেট করতে হয়, আপনি PeriodicWorkRequest-এর জন্যও প্রাথমিক বিলম্ব সেট করতে পারেন। সেক্ষেত্রে, আপনার পর্যায়ক্রমিক কাজের শুধুমাত্র প্রথম রান বিলম্বিত হবে।

আবার চেষ্টা করা ও ব্যাকঅফ নীতি

WorkManager-কে দিয়ে আপনার কাজ আবার চেষ্টা করতে চাইলে, আপনি নিজের কর্মী থেকে Result.retry() ফিরিয়ে আনতে পারবেন। তারপর ব্যাকঅফ বিলম্ব এবং ব্যাকঅফ নীতি অনুযায়ী আপনার কাজ আবার শিডিউল করা হয়।

• ব্যাকঅফ বিলম্ব প্রথমবার চেষ্টা করার পরে আপনার কাজ আবার চেষ্টা করার আগে অপেক্ষা করার ন্যূনতম সময় নির্দিষ্ট করে। এই ভ্যালু ১০ সেকেন্ডের কম হতে পারে না (বা MIN_BACKOFF_MILLIS)।

• ব্যাকঅফ নীতি নির্ধারণ করে যে পরবর্তীকালে আবার চেষ্টা করার জন্য ব্যাকঅফ বিলম্ব কীভাবে সময়ের সাথে সাথে বৃদ্ধি পাবে। WorkManager-এ ২টি ব্যাকঅফ নীতি কাজ করে, LINEAR এবং EXPONENTIAL।

প্রতিটি কাজের অনুরোধে ব্যাকঅফ নীতি এবং ব্যাকঅফ বিলম্ব থাকে। ডিফল্ট নীতি হল ৩০ সেকেন্ডের বিলম্ব সহ EXPONENTIAL, তবে আপনি নিজের কাজের অনুরোধের কনফিগারেশনে এটি ওভাররাইড করতে পারেন।

ব্যাকঅফ ডিলে ও নীতি কাস্টমাইজ করার একটি উদাহরণ এখানে দেওয়া হল।

val myWorkRequest = OneTimeWorkRequestBuilder<MyWork>()
   .setBackoffCriteria(
       BackoffPolicy.LINEAR,
       WorkRequest.MIN_BACKOFF_MILLIS,
       TimeUnit.MILLISECONDS)
   .build()

WorkRequest myWorkRequest =
       new OneTimeWorkRequest.Builder(MyWork.class)
               .setBackoffCriteria(
                       BackoffPolicy.LINEAR,
                       WorkRequest.MIN_BACKOFF_MILLIS,
                       TimeUnit.MILLISECONDS)
               .build();

এই উদাহরণে, ন্যূনতম ব্যাকঅফ ডিলে অনুমোদিত ন্যূনতম ভ্যালুতে সেট করা হয়েছে, ১০ সেকেন্ড। যেহেতু নীতিটি হল LINEAR, তাই প্রতিটি নতুন প্রচেষ্টার সাথে আবার চেষ্টা করার ব্যবধান প্রায় ১০ সেকেন্ড বৃদ্ধি পাবে। যেমন, প্রথমবার রান করার সময় Result.retry()-এ শেষ হলে, ১০ সেকেন্ড পরে আবার চেষ্টা করা হবে, তারপরে ২০, ৩০, ৪০ সেকেন্ড পরে চেষ্টা করা হবে এবং এইভাবে চলতে থাকবে, যদি কাজ করার সময় Result.retry()-এ শেষ হতে থাকে। ব্যাকঅফ নীতি EXPONENTIAL-এ সেট করা থাকলে, আবার চেষ্টা করার সময়সীমার ক্রম ২০, ৪০ ও ৮০-এর কাছাকাছি হবে।

ট্যাগ ওয়ার্ক

প্রতিটি কাজের অনুরোধের একটি অনন্য শনাক্তকারী থাকে, যা পরে সেই কাজটি শনাক্ত করতে ব্যবহার করা যেতে পারে যাতে কাজটি বাতিল করা যায় বা এর অগ্রগতি পর্যবেক্ষণ করা যায়।

আপনার কাছে লজিক্যালি সম্পর্কিত কাজের গ্রুপ থাকলে, আপনি সেইসব কাজের আইটেম ট্যাগ করার ক্ষেত্রেও এটি সহায়ক বলে মনে করতে পারেন। ট্যাগিং আপনাকে একসাথে কাজের অনুরোধের একটি গ্রুপের সাথে কাজ করতে দেয়।

যেমন, WorkManager.cancelAllWorkByTag(String) নির্দিষ্ট ট্যাগ সহ সব কাজের অনুরোধ বাতিল করে দেয় এবং WorkManager.getWorkInfosByTag(String) WorkInfo অবজেক্টের একটি তালিকা ফিরিয়ে দেয় যা বর্তমান কাজের অবস্থা নির্ধারণ করতে ব্যবহার করা যেতে পারে।

আপনার কাজে কীভাবে "ক্লিনআপ" ট্যাগ যোগ করবেন তা নিম্নলিখিত কোড থেকে জানতে পারবেন:

val myWorkRequest = OneTimeWorkRequestBuilder<MyWork>()
   .addTag("cleanup")
   .build()

WorkRequest myWorkRequest =
       new OneTimeWorkRequest.Builder(MyWork.class)
       .addTag("cleanup")
       .build();

সবশেষে, একটি কাজের অনুরোধে একাধিক ট্যাগ যোগ করা যেতে পারে। ইন্টার্নালি এইসব ট্যাগ স্ট্রিংয়ের সেট হিসেবে স্টোর করা হয়। WorkRequest-এর সাথে যুক্ত ট্যাগের সেট পেতে আপনি WorkInfo.getTags() ব্যবহার করতে পারেন।

আপনার Worker ক্লাস থেকে, আপনি ListenableWorker.getTags() ব্যবহার করে এর ট্যাগ সেট ফিরিয়ে আনতে পারবেন।

ইনপুট ডেটা অ্যাসাইন করুন

আপনার কাজ করার জন্য ইনপুট ডেটার প্রয়োজন হতে পারে। যেমন, ছবি আপলোড করার কাজ করার জন্য ইনপুট হিসেবে আপলোড করা ছবির URI প্রয়োজন হতে পারে।

ইনপুট ভ্যালু Data অবজেক্টে কী-ভ্যালু পেয়ার হিসেবে সেভ করা হয় এবং কাজের অনুরোধে সেট করা যেতে পারে। WorkManager আপনার কাজ এক্সিকিউট করার সময় ইনপুট Data ডেলিভার করবে। Worker ক্লাস Worker.getInputData() কল করে ইনপুট আর্গুমেন্ট অ্যাক্সেস করতে পারে। নিম্নলিখিত কোড থেকে আপনি জানতে পারবেন যে কীভাবে Worker ইনস্ট্যান্স তৈরি করতে হয়, যার জন্য ইনপুট ডেটা প্রয়োজন এবং কীভাবে আপনার কাজের অনুরোধে এটি পাঠাতে হয়।

// Define the Worker requiring input
class UploadWork(appContext: Context, workerParams: WorkerParameters)
   : Worker(appContext, workerParams) {

   override fun doWork(): Result {
       val imageUriInput =
           inputData.getString("IMAGE_URI") ?: return Result.failure()

       uploadFile(imageUriInput)
       return Result.success()
   }
   ...
}

// Create a WorkRequest for your Worker and sending it input
val myUploadWork = OneTimeWorkRequestBuilder<UploadWork>()
   .setInputData(workDataOf(
       "IMAGE_URI" to "http://..."
   ))
   .build()

// Define the Worker requiring input
public class UploadWork extends Worker {

   public UploadWork(Context appContext, WorkerParameters workerParams) {
       super(appContext, workerParams);
   }

   @NonNull
   @Override
   public Result doWork() {
       String imageUriInput = getInputData().getString("IMAGE_URI");
       if(imageUriInput == null) {
           return Result.failure();
       }

       uploadFile(imageUriInput);
       return Result.success();
   }
   ...
}

// Create a WorkRequest for your Worker and sending it input
WorkRequest myUploadWork =
      new OneTimeWorkRequest.Builder(UploadWork.class)
           .setInputData(
               new Data.Builder()
                   .putString("IMAGE_URI", "http://...")
                   .build()
           )
           .build();

একইভাবে, আপনি রিটার্ন ভ্যালু আউটপুট করতে Data ক্লাস ব্যবহার করতে পারেন।

পরবর্তী ধাপ

স্ট্যাটাস ও পর্যবেক্ষণ পৃষ্ঠা থেকে আপনি কাজের স্ট্যাটাস এবং কাজের অগ্রগতি কীভাবে মনিটর করবেন সেই সম্পর্কে আরও জানতে পারবেন।