চেইনিং কাজ

ওয়ার্কম্যানেজার আপনাকে এমন একটি কাজের শৃঙ্খল তৈরি এবং সারিবদ্ধ করার অনুমতি দেয় যা একাধিক নির্ভরশীল কাজ নির্দিষ্ট করে এবং সেগুলি কোন ক্রমে চালানো উচিত তা নির্ধারণ করে। এই কার্যকারিতাটি বিশেষভাবে কার্যকর যখন আপনাকে একটি নির্দিষ্ট ক্রমে বেশ কয়েকটি কাজ চালানোর প্রয়োজন হয়।

কাজের একটি শৃঙ্খল তৈরি করতে, আপনি WorkManager.beginWith(OneTimeWorkRequest) অথবা WorkManager.beginWith(List<OneTimeWorkRequest>) ব্যবহার করতে পারেন, যা প্রতিটি WorkContinuation এর একটি উদাহরণ প্রদান করে।

তারপর WorkContinuation ব্যবহার করে then(OneTimeWorkRequest) অথবা then(List<OneTimeWorkRequest>) ব্যবহার করে নির্ভরশীল OneTimeWorkRequest দৃষ্টান্ত যোগ করা যেতে পারে।

WorkContinuation.then(...) এর প্রতিটি আহ্বান WorkContinuation এর একটি নতুন উদাহরণ প্রদান করে। যদি আপনি OneTimeWorkRequest এর একটি List যোগ করেন, তাহলে এই অনুরোধগুলি সম্ভাব্যভাবে সমান্তরালভাবে চলতে পারে।

অবশেষে, আপনি WorkContinuation.enqueue() পদ্ধতি ব্যবহার করে আপনার WorkContinuation s এর শৃঙ্খল enqueue() করতে পারেন।

আসুন একটি উদাহরণ দেখি। এই উদাহরণে, 3টি ভিন্ন Worker কাজ চালানোর জন্য কনফিগার করা হয়েছে (সম্ভাব্যভাবে সমান্তরালভাবে)। এই Workers এর ফলাফলগুলি তারপর যুক্ত করা হয় এবং একটি ক্যাশিং Worker জবে প্রেরণ করা হয়। অবশেষে, সেই কাজের আউটপুট একটি আপলোড Worker-এ প্রেরণ করা হয়, যা ফলাফলগুলিকে একটি দূরবর্তী সার্ভারে আপলোড করে।

WorkManager.getInstance(myContext)
   // Candidates to run in parallel
   .beginWith(listOf(plantName1, plantName2, plantName3))
   // Dependent work (only runs after all previous work in chain)
   .then(cache)
   .then(upload)
   // Call enqueue to kick things off
   .enqueue()

WorkManager.getInstance(myContext)
   // Candidates to run in parallel
   .beginWith(Arrays.asList(plantName1, plantName2, plantName3))
   // Dependent work (only runs after all previous work in chain)
   .then(cache)
   .then(upload)
   // Call enqueue to kick things off
   .enqueue();

ইনপুট মার্জার

যখন আপনি OneTimeWorkRequest ইনস্ট্যান্সগুলিকে চেইন করেন, তখন প্যারেন্ট ওয়ার্ক রিকোয়েস্টের আউটপুট শিশুদের কাছে ইনপুট হিসেবে পাঠানো হয়। সুতরাং উপরের উদাহরণে, plantName1 , plantName2 , এবং plantName3 এর আউটপুটগুলি cache রিকোয়েস্টে ইনপুট হিসেবে পাঠানো হবে।

একাধিক প্যারেন্ট কাজের অনুরোধ থেকে ইনপুট পরিচালনা করার জন্য, WorkManager InputMerger ব্যবহার করে।

WorkManager দ্বারা দুটি ভিন্ন ধরণের InputMerger প্রদান করা হয়:

• OverwritingInputMerger সকল ইনপুট থেকে সকল কী আউটপুটে যোগ করার চেষ্টা করে। দ্বন্দ্বের ক্ষেত্রে, এটি পূর্বে সেট করা কীগুলিকে ওভাররাইট করে।

• ArrayCreatingInputMerger ইনপুটগুলিকে একত্রিত করার চেষ্টা করে, প্রয়োজনে অ্যারে তৈরি করে।

যদি আপনার আরও নির্দিষ্ট ব্যবহারের ক্ষেত্রে থাকে, তাহলে আপনি InputMerger সাবক্লাস করে নিজেরটি লিখতে পারেন।

ওভাররাইটিংইনপুটমার্জার

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

উদাহরণস্বরূপ, যদি প্রতিটি প্ল্যান্ট ইনপুটগুলির জন্য একটি কী থাকে যা তাদের নিজ নিজ ভেরিয়েবলের নামের সাথে মিলে যায় ( "plantName1" , "plantName2" , এবং "plantName3" ), তাহলে cache কর্মীর কাছে পাঠানো ডেটাতে তিনটি কী-মান জোড়া থাকবে।

যদি কোনও দ্বন্দ্ব থাকে, তাহলে শেষ কর্মী যিনি "জয়ী" হন, এবং এর মান cache স্থানান্তরিত হয়।

যেহেতু আপনার কাজের অনুরোধগুলি সমান্তরালভাবে চালানো হয়, তাই এটি কোন ক্রমে চলবে তার কোনও গ্যারান্টি নেই। উপরের উদাহরণে, plantName1 "tulip" অথবা "elm" এর মান ধারণ করতে পারে, যা শেষ কোন মানটি লেখা হয়েছে তার উপর নির্ভর করে। যদি আপনার কোনও কী দ্বন্দ্বের সম্ভাবনা থাকে এবং আপনাকে একটি মার্জারে সমস্ত আউটপুট ডেটা সংরক্ষণ করতে হয়, তাহলে ArrayCreatingInputMerger একটি ভাল বিকল্প হতে পারে।

অ্যারে তৈরি করাইনপুটমার্জার

উপরের উদাহরণের জন্য, যেহেতু আমরা সমস্ত প্ল্যান্ট নামের Workers থেকে আউটপুট সংরক্ষণ করতে চাই, তাই আমাদের একটি ArrayCreatingInputMerger ব্যবহার করা উচিত।

val cache: OneTimeWorkRequest = OneTimeWorkRequestBuilder<PlantWorker>()
   .setInputMerger(ArrayCreatingInputMerger::class)
   .setConstraints(constraints)
   .build()

OneTimeWorkRequest cache = new OneTimeWorkRequest.Builder(PlantWorker.class)
       .setInputMerger(ArrayCreatingInputMerger.class)
       .setConstraints(constraints)
       .build();

ArrayCreatingInputMerger প্রতিটি কীকে একটি অ্যারের সাথে যুক্ত করে। যদি প্রতিটি কী অনন্য হয়, তাহলে আপনার ফলাফল হবে এক-উপাদান অ্যারের একটি সিরিজ।

যদি কোন কী সংঘর্ষ হয়, তাহলে সংশ্লিষ্ট মানগুলিকে একটি অ্যারেতে একত্রিত করা হয়।

চেইনিং এবং কাজের অবস্থা

OneTimeWorkRequest এর চেইনগুলি ক্রমানুসারে কার্যকর হয় যতক্ষণ না তাদের কাজ সফলভাবে সম্পন্ন হয় (অর্থাৎ, তারা একটি Result.success() প্রদান করে)। কাজের অনুরোধগুলি চলমান অবস্থায় ব্যর্থ হতে পারে বা বাতিল হতে পারে, যার ফলে নির্ভরশীল কাজের অনুরোধগুলির উপর ডাউনস্ট্রিম প্রভাব পড়ে।

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

একবার সারিবদ্ধ হয়ে গেলে এবং সমস্ত কাজের সীমাবদ্ধতা পূরণ হয়ে গেলে, প্রথম কাজের অনুরোধটি চলতে শুরু করে। যদি রুট OneTimeWorkRequest বা List<OneTimeWorkRequest> এ কাজ সফলভাবে সম্পন্ন হয় (অর্থাৎ, এটি একটি Result.success() প্রদান করে), তাহলে পরবর্তী নির্ভরশীল কাজের অনুরোধগুলি সারিবদ্ধ করা হবে।

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

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

কাস্টম পুনঃচেষ্টা কৌশল সংজ্ঞায়িত করার বিষয়ে আরও তথ্যের জন্য, পুনঃচেষ্টা এবং ব্যাকঅফ নীতি দেখুন।

যদি সেই পুনঃচেষ্টা নীতিটি অনির্ধারিত বা শেষ হয়ে যায়, অথবা আপনি অন্যথায় এমন কোনও অবস্থায় পৌঁছান যেখানে একটি OneTimeWorkRequest Result.failure() ফেরত দেয়, তাহলে সেই কাজের অনুরোধ এবং সমস্ত নির্ভরশীল কাজের অনুরোধগুলি FAILED.

একই যুক্তি প্রযোজ্য যখন একটি OneTimeWorkRequest বাতিল করা হয়। যেকোনো নির্ভরশীল কাজের অনুরোধ CANCELLED চিহ্নিত করা হয় এবং তাদের কাজ কার্যকর করা হবে না।

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

কাজের অনুরোধের শৃঙ্খল তৈরি করার সময়, নির্ভরশীল কাজের অনুরোধগুলিতে পুনরায় চেষ্টা করার নীতিগুলি সংজ্ঞায়িত করা উচিত যাতে কাজ সর্বদা সময়মতো সম্পন্ন হয়। ব্যর্থ কাজের অনুরোধের ফলে অসম্পূর্ণ শৃঙ্খল এবং/অথবা অপ্রত্যাশিত অবস্থা দেখা দিতে পারে।

আরও তথ্যের জন্য, কাজ বাতিল এবং বন্ধ করা দেখুন।