চেনিং ওয়ার্ক

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

কাজের একটি চেইন তৈরি করতে, আপনি WorkManager.beginWith(OneTimeWorkRequest) বা WorkManager.beginWith(List<OneTimeWorkRequest>) ব্যবহার করতে পারেন, যার প্রতিটি WorkContinuation-এর একটি ইনস্ট্যান্স রিটার্ন করে।

তারপর, WorkContinuation ব্যবহার করে then(OneTimeWorkRequest) বা then(List<OneTimeWorkRequest>) ব্যবহার করে নির্ভরশীল OneTimeWorkRequest ইনস্ট্যান্স যোগ করা যেতে পারে।

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

অবশেষে, আপনি WorkContinuation.enqueue() পদ্ধতি ব্যবহার করে WorkContinuation-এর চেন enqueue() করতে পারবেন।

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

Kotlin

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

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

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

ডায়াগ্রামে তিনটি জব দেখানো হয়েছে যেগুলি চেনের পরবর্তী জবে বিভিন্ন আউটপুট পাস করছে। তিনটি আউটপুটের আলাদা আলাদা কী থাকার কারণে, পরবর্তী জব তিনটি কী/ভ্যালু পেয়ার পায়।

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

ডায়াগ্রামে দেখানো হয়েছে যে তিনটি জব চেনের পরবর্তী জবে আউটপুট পাস করছে। এই ক্ষেত্রে, সেইসব কাজের মধ্যে দুটি কাজ একই 'কী' সহ আউটপুট তৈরি করে। এর ফলে, পরবর্তী জব দুটি কী/ভ্যালু পেয়ার পায়, যার মধ্যে একটি পরস্পরবিরোধী আউটপুট বাদ দেওয়া হয়।

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

ArrayCreatingInputMerger

উপরের উদাহরণের ক্ষেত্রে, যেহেতু আমরা সব plant name Worker-এর আউটপুট সংরক্ষণ করতে চাই, তাই আমাদের ArrayCreatingInputMerger ব্যবহার করা উচিত।

Kotlin

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 দেখুন।

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

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