WorkManager আপনাকে কাজের একটি শৃঙ্খল তৈরি করতে এবং সারিবদ্ধ করতে দেয় যা একাধিক নির্ভরশীল কাজ নির্দিষ্ট করে এবং সেগুলিকে কোন ক্রমে চালানো উচিত তা সংজ্ঞায়িত করে৷ এই কার্যকারিতাটি বিশেষভাবে কার্যকর যখন আপনাকে একটি নির্দিষ্ট ক্রমে বেশ কয়েকটি কাজ চালানোর প্রয়োজন হয়৷
কাজের একটি শৃঙ্খল তৈরি করতে, আপনি WorkManager.beginWith(OneTimeWorkRequest) বা WorkManager.beginWith(List<OneTimeWorkRequest>) ব্যবহার করতে পারেন, যেটি প্রতিটি WorkContinuation এর একটি উদাহরণ প্রদান করে।
then(OneTimeWorkRequest) অথবা then(List<OneTimeWorkRequest>) ব্যবহার করে নির্ভরশীল OneTimeWorkRequest দৃষ্টান্ত যোগ করতে একটি WorkContinuation ব্যবহার করা যেতে পারে।
WorkContinuation.then(...) এর প্রতিটি আহ্বান WorkContinuation এর একটি নতুন উদাহরণ প্রদান করে। আপনি যদি OneTimeWorkRequest উদাহরণগুলির একটি List যোগ করেন, তাহলে এই অনুরোধগুলি সম্ভাব্যভাবে সমান্তরালভাবে চলতে পারে৷
অবশেষে, আপনি WorkContinuation.enqueue() পদ্ধতিটি ব্যবহার করতে পারেন আপনার WorkContinuation s-এর চেইনকে enqueue() করতে।
এর একটি উদাহরণ তাকান. এই উদাহরণে, 3টি ভিন্ন কর্মী কাজ চালানোর জন্য কনফিগার করা হয়েছে (সম্ভাব্যভাবে সমান্তরালভাবে)। এই শ্রমিকদের ফলাফল তারপর যোগদান করা হয় এবং একটি ক্যাশিং ওয়ার্কার চাকরিতে চলে যায়। অবশেষে, সেই কাজের আউটপুট একটি আপলোড ওয়ার্কারে পাস করা হয়, যা ফলাফলগুলি একটি দূরবর্তী সার্ভারে আপলোড করে।
কোটলিন
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 একটি ভাল বিকল্প হতে পারে।
ArrayCreatingInputMerger
উপরের উদাহরণের জন্য, প্রদত্ত যে আমরা সমস্ত প্ল্যান্ট নাম শ্রমিকদের থেকে আউটপুট সংরক্ষণ করতে চাই, আমাদের একটি 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 দেখুন।
কাজের অনুরোধের চেইন তৈরি করার সময়, নির্ভরশীল কাজের অনুরোধগুলিকে পুনরায় চেষ্টা করার নীতিগুলিকে সংজ্ঞায়িত করা উচিত যাতে কাজটি সর্বদা সময়মত সম্পন্ন হয় তা নিশ্চিত করতে। ব্যর্থ কাজের অনুরোধের ফলে অসম্পূর্ণ চেইন এবং/অথবা অপ্রত্যাশিত অবস্থা হতে পারে।
আরও তথ্যের জন্য, কাজ বাতিল করা এবং বন্ধ করা দেখুন।
,WorkManager আপনাকে কাজের একটি শৃঙ্খল তৈরি করতে এবং সারিবদ্ধ করতে দেয় যা একাধিক নির্ভরশীল কাজ নির্দিষ্ট করে এবং সেগুলিকে কোন ক্রমে চালানো উচিত তা সংজ্ঞায়িত করে৷ এই কার্যকারিতাটি বিশেষভাবে কার্যকর যখন আপনাকে একটি নির্দিষ্ট ক্রমে বেশ কয়েকটি কাজ চালানোর প্রয়োজন হয়৷
কাজের একটি শৃঙ্খল তৈরি করতে, আপনি WorkManager.beginWith(OneTimeWorkRequest) বা WorkManager.beginWith(List<OneTimeWorkRequest>) ব্যবহার করতে পারেন, যেটি প্রতিটি WorkContinuation এর একটি উদাহরণ প্রদান করে।
then(OneTimeWorkRequest) অথবা then(List<OneTimeWorkRequest>) ব্যবহার করে নির্ভরশীল OneTimeWorkRequest দৃষ্টান্ত যোগ করতে একটি WorkContinuation ব্যবহার করা যেতে পারে।
WorkContinuation.then(...) এর প্রতিটি আহ্বান WorkContinuation এর একটি নতুন উদাহরণ প্রদান করে। আপনি যদি OneTimeWorkRequest উদাহরণগুলির একটি List যোগ করেন, তাহলে এই অনুরোধগুলি সম্ভাব্যভাবে সমান্তরালভাবে চলতে পারে৷
অবশেষে, আপনি WorkContinuation.enqueue() পদ্ধতিটি ব্যবহার করতে পারেন আপনার WorkContinuation s-এর চেইনকে enqueue() করতে।
এর একটি উদাহরণ তাকান. এই উদাহরণে, 3টি ভিন্ন কর্মী কাজ চালানোর জন্য কনফিগার করা হয়েছে (সম্ভাব্যভাবে সমান্তরালভাবে)। এই শ্রমিকদের ফলাফল তারপর যোগদান করা হয় এবং একটি ক্যাশিং ওয়ার্কার চাকরিতে চলে যায়। অবশেষে, সেই কাজের আউটপুট একটি আপলোড ওয়ার্কারে পাস করা হয়, যা ফলাফলগুলি একটি দূরবর্তী সার্ভারে আপলোড করে।
কোটলিন
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 একটি ভাল বিকল্প হতে পারে।
ArrayCreatingInputMerger
উপরের উদাহরণের জন্য, প্রদত্ত যে আমরা সমস্ত প্ল্যান্ট নাম শ্রমিকদের থেকে আউটপুট সংরক্ষণ করতে চাই, আমাদের একটি 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 দেখুন।
কাজের অনুরোধের চেইন তৈরি করার সময়, নির্ভরশীল কাজের অনুরোধগুলিকে পুনরায় চেষ্টা করার নীতিগুলিকে সংজ্ঞায়িত করা উচিত যাতে কাজটি সর্বদা সময়মত সম্পন্ন হয় তা নিশ্চিত করতে। ব্যর্থ কাজের অনুরোধের ফলে অসম্পূর্ণ চেইন এবং/অথবা অপ্রত্যাশিত অবস্থা হতে পারে।
আরও তথ্যের জন্য, কাজ বাতিল করা এবং বন্ধ করা দেখুন।
,WorkManager আপনাকে কাজের একটি শৃঙ্খল তৈরি করতে এবং সারিবদ্ধ করতে দেয় যা একাধিক নির্ভরশীল কাজ নির্দিষ্ট করে এবং সেগুলিকে কোন ক্রমে চালানো উচিত তা সংজ্ঞায়িত করে৷ এই কার্যকারিতাটি বিশেষভাবে কার্যকর যখন আপনাকে একটি নির্দিষ্ট ক্রমে বেশ কয়েকটি কাজ চালানোর প্রয়োজন হয়৷
কাজের একটি শৃঙ্খল তৈরি করতে, আপনি WorkManager.beginWith(OneTimeWorkRequest) বা WorkManager.beginWith(List<OneTimeWorkRequest>) ব্যবহার করতে পারেন, যেটি প্রতিটি WorkContinuation এর একটি উদাহরণ প্রদান করে।
then(OneTimeWorkRequest) অথবা then(List<OneTimeWorkRequest>) ব্যবহার করে নির্ভরশীল OneTimeWorkRequest দৃষ্টান্ত যোগ করতে একটি WorkContinuation ব্যবহার করা যেতে পারে।
WorkContinuation.then(...) এর প্রতিটি আহ্বান WorkContinuation এর একটি নতুন উদাহরণ প্রদান করে। আপনি যদি OneTimeWorkRequest উদাহরণগুলির একটি List যোগ করেন, তাহলে এই অনুরোধগুলি সম্ভাব্যভাবে সমান্তরালভাবে চলতে পারে৷
অবশেষে, আপনি WorkContinuation.enqueue() পদ্ধতিটি ব্যবহার করতে পারেন আপনার WorkContinuation s-এর চেইনকে enqueue() করতে।
এর একটি উদাহরণ তাকান. এই উদাহরণে, 3টি ভিন্ন কর্মী কাজ চালানোর জন্য কনফিগার করা হয়েছে (সম্ভাব্যভাবে সমান্তরালভাবে)। এই শ্রমিকদের ফলাফল তারপর যোগদান করা হয় এবং একটি ক্যাশিং ওয়ার্কার চাকরিতে চলে যায়। অবশেষে, সেই কাজের আউটপুট একটি আপলোড ওয়ার্কারে পাস করা হয়, যা ফলাফলগুলি একটি দূরবর্তী সার্ভারে আপলোড করে।
কোটলিন
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 একটি ভাল বিকল্প হতে পারে।
ArrayCreatingInputMerger
উপরের উদাহরণের জন্য, প্রদত্ত যে আমরা সমস্ত প্ল্যান্ট নাম শ্রমিকদের থেকে আউটপুট সংরক্ষণ করতে চাই, আমাদের একটি 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 দেখুন।
কাজের অনুরোধের চেইন তৈরি করার সময়, নির্ভরশীল কাজের অনুরোধগুলিকে পুনরায় চেষ্টা করার নীতিগুলিকে সংজ্ঞায়িত করা উচিত যাতে কাজটি সর্বদা সময়মত সম্পন্ন হয় তা নিশ্চিত করতে। ব্যর্থ কাজের অনুরোধের ফলে অসম্পূর্ণ চেইন এবং/অথবা অপ্রত্যাশিত অবস্থা হতে পারে।
আরও তথ্যের জন্য, কাজ বাতিল করা এবং বন্ধ করা দেখুন।