📝 👭 🎽 कार्य अनुसूचक विकास 🙆🏾 👨🏽‍🍳 🌾

IFunny जिस एप्लिकेशन पर हम काम कर रहे हैं, वह दुकानों में पांच साल से अधिक समय से उपलब्ध है। इस समय के दौरान, मोबाइल टीम को कई अलग-अलग तरीकों और उपकरणों के बीच पलायन से गुजरना पड़ा, और एक साल पहले एक स्व-लिखित समाधान से स्विच करने और कुछ और "फैशनेबल" और व्यापक रूप से देखने की दिशा में एक समय था। यह लेख एक छोटी सी निचोड़ है कि क्या अध्ययन किया गया है, क्या समाधान देखे गए हैं, और उन्होंने क्या समाप्त किया है।

हमें यह सब क्यों चाहिए?

आइए तुरंत यह तय करें कि यह लेख क्या है और यह विषय Android विकास टीम के लिए महत्वपूर्ण क्यों है:

ऐसे कई परिदृश्य हैं जब आपको सक्रिय उपयोगकर्ता इंटरफ़ेस के ढांचे के बाहर कार्यों को चलाने की आवश्यकता होती है;
प्रणाली ऐसे कार्यों के शुभारंभ पर बड़ी संख्या में प्रतिबंध लगाती है;
यह मौजूदा समाधानों के बीच चयन करने के लिए काफी मुश्किल हो गया, क्योंकि प्रत्येक उपकरण के पास अपने पेशेवरों और विपक्ष हैं।

घटनाओं के विकास का कालक्रम

Android 0

अलार्ममैन, हैंडलर, सेवा

प्रारंभ में, उनका समाधान सेवाओं के आधार पर पृष्ठभूमि आधारित कार्यों को शुरू करने के लिए लागू किया गया था। एक तंत्र भी था जो कार्यों को जीवन चक्र से जोड़ता था और उन्हें रद्द करने और पुनर्स्थापित करने में सक्षम था। इसने टीम को लंबे समय के लिए अनुकूल किया, क्योंकि मंच ने इस तरह के कार्यों पर कोई प्रतिबंध नहीं लगाया था।
Google ने निम्नलिखित चित्र के आधार पर ऐसा करने की सलाह दी:

2018 के अंत में, यह समझने का कोई मतलब नहीं है, यह आपदा के पैमाने का आकलन करने के लिए पर्याप्त है।
वास्तव में, किसी ने परवाह नहीं की कि पृष्ठभूमि में कितना काम हो रहा है। अनुप्रयोगों ने वही किया जो वे चाहते थे और जब वे चाहते थे।

पेशेवरों :
हर जगह उपलब्ध;
सभी के लिए सुलभ।

विपक्ष :
सिस्टम हर तरह से काम को प्रतिबंधित करता है;
स्थिति से कोई प्रक्षेपण नहीं;
एपीआई न्यूनतम है और आपको बहुत सारे कोड लिखने की आवश्यकता है।

Android 5. लॉलीपॉप

JobScheduler

5 (!) वर्षों के बाद, 2015 के करीब, Google ने देखा कि कार्यों को अक्षमता से लॉन्च किया जाता है। उपयोगकर्ताओं ने नियमित रूप से शिकायत करना शुरू कर दिया कि उनके फोन केवल एक मेज पर या उनकी जेब में झूठ बोलकर कम चल रहे थे।

एंड्रॉइड 5 की रिलीज़ के साथ, जॉबस्किड्यूलर जैसे उपकरण दिखाई दिए हैं। यह एक ऐसा तंत्र है जिसकी सहायता से पृष्ठभूमि में विभिन्न कार्यों को करना संभव है, जिसकी शुरुआत इन कार्यों को शुरू करने के लिए केंद्रीकृत प्रणाली और इस बहुत लॉन्च के लिए परिस्थितियों को निर्धारित करने की क्षमता के कारण अनुकूलित और सरलीकृत की गई थी।

कोड में, यह सब काफी सरल दिखता है: एक सेवा की घोषणा की जाती है जिसमें शुरुआत और अंत की घटनाएं आती हैं।
बारीकियों से: यदि आप अतुल्य रूप से काम करना चाहते हैं, तो onStartJob से आपको स्ट्रीम शुरू करने की आवश्यकता है; मुख्य बात यह है कि काम के अंत में जॉबफिनिश्ड विधि को कॉल करना न भूलें, अन्यथा सिस्टम वेकॉक को जाने नहीं देगा, आपका कार्य पूरा नहीं माना जाएगा और खो जाएगा।

public class JobSchedulerService extends JobService { @Override public boolean onStartJob(JobParameters params) { doWork(params); return false; } @Override public boolean onStopJob(JobParameters params) { return false; } }

आवेदन में कहीं से भी, आप इस काम को शुरू कर सकते हैं। हमारी प्रक्रिया में कार्य किए जाते हैं, लेकिन IPC स्तर पर शुरू किए जाते हैं। एक केंद्रीकृत तंत्र है जो उनके निष्पादन को नियंत्रित करता है और इसके लिए आवश्यक क्षणों में ही आवेदन को जगाता है। आप बंडल के माध्यम से विभिन्न ट्रिगर की स्थिति भी सेट कर सकते हैं और डेटा ट्रांसफर कर सकते हैं।

 JobInfo task = new JobInfo.Builder(JOB_ID, serviceName) .setRequiredNetworkType(JobInfo.NETWORK_TYPE_UNMETERED) .setRequiresDeviceIdle(true) .setRequiresCharging(true) .build(); JobScheduler scheduler = (JobScheduler) context.getSystemService(JOB_SCHEDULER_SERVICE); scheduler.schedule(task);

सामान्य तौर पर, कुछ भी नहीं की तुलना में, यह पहले से ही कुछ था। लेकिन यह तंत्र केवल एपीआई 21 के साथ उपलब्ध है, और एंड्रॉइड 5.0 की रिलीज के समय सभी पुराने उपकरणों का समर्थन बंद करना अजीब होगा (3 साल बीत चुके हैं, और हम अभी भी चार का समर्थन करते हैं)।

पेशेवरों :
एपीआई सरल है;
प्रक्षेपण के लिए शर्तें।

विपक्ष :
~~उपलब्ध एपीआई 21 के साथ शुरू~~
वास्तव में, केवल एपीआई 23 के साथ;
गलती करना आसान है।

Android 5. लॉलीपॉप

Gcm नेटवर्क मैनेजर

JobScheduler - GCM नेटवर्क प्रबंधक का एक एनालॉग भी प्रस्तुत किया गया था। यह एक पुस्तकालय है जो समान कार्यक्षमता प्रदान करता है, लेकिन पहले से ही एपीआई 9 के साथ काम किया। सच है, इसके बदले में Google Play सेवाओं की आवश्यकता थी। जाहिरा तौर पर, जॉबसक्यूलर के लिए काम करने के लिए आवश्यक कार्यक्षमता, न केवल एंड्रॉइड संस्करण के माध्यम से वितरित करना शुरू हुई, बल्कि जीपीएस स्तर पर भी। यह ध्यान दिया जाना चाहिए कि ढांचे के डेवलपर्स ने अपने दिमाग को बहुत तेज़ी से बदल दिया और अपने भविष्य को जीपीएस के साथ नहीं जोड़ने का फैसला किया। उसके लिए उन्हें धन्यवाद।

सब कुछ बिल्कुल समान दिखता है। समान सेवा:

 public class GcmNetworkManagerService extends GcmTaskService { @Override public int onRunTask(TaskParams taskParams) { doWork(taskParams); return 0; } }

एक ही कार्य लॉन्च:

 OneoffTask task = new OneoffTask.Builder() .setService(GcmNetworkManagerService.class) .setTag(TAG) .setRequiredNetworkType(JobInfo.NETWORK_TYPE_UNMETERED) .setRequiresCharging(true) .build(); GcmNetworkManager mGcmNetworkManager = GcmNetworkManager.getInstance(this); mGcmNetworkManager.schedule(task);

वास्तुकला की यह समानता विरासत में मिली कार्यक्षमता और औजारों के बीच एक सरल प्रवासन प्राप्त करने की इच्छा से तय की गई थी।

पेशेवरों :
JobScheduler के समान एपीआई;
उपलब्ध एपीआई 9 के साथ शुरू।

विपक्ष :
आपके पास Google Play Services होना चाहिए
गलती करना आसान है।

Android 5. लॉलीपॉप

WakefulBroadcastReceiver

आगे, मैं कुछ बुनियादी तंत्रों में से एक के बारे में कुछ शब्द लिखूंगा जिसका उपयोग जॉबस्क्राइडर में किया गया है और यह सीधे डेवलपर्स के लिए उपलब्ध है। यह WakeLock और इसके आधारित WakefulBroadcastReceiver है।

WakeLock का उपयोग करके, आप सिस्टम को सस्पेंड में छोड़ने से रोक सकते हैं, अर्थात, डिवाइस को सक्रिय स्थिति में रखें। यदि हम कुछ महत्वपूर्ण कार्य करना चाहते हैं तो यह आवश्यक है।
WakeLock बनाते समय, आप इसकी सेटिंग निर्दिष्ट कर सकते हैं: CPU, स्क्रीन या कीबोर्ड को पकड़ें।

 PowerManager pm = (PowerManager) context.getSystemService(Context.POWER_SERVICE) PowerManager.WakeLock wl = pm.newWakeLock(PARTIAL_WAKE_LOCK, "name") wl.acquire(timeout);

इस तंत्र के आधार पर, WakefulBroadcastReceiver काम करता है। हम सेवा शुरू करते हैं और वेकॉक को पकड़ते हैं।

 public class SimpleWakefulReceiver extends WakefulBroadcastReceiver { @Override public void onReceive(Context context, Intent intent) { Intent service = new Intent(context, SimpleWakefulService.class); startWakefulService(context, service); } }

सेवा के आवश्यक कार्य पूरा होने के बाद, हम इसे इसी तरह के तरीकों से जारी करते हैं।

4 संस्करणों के माध्यम से, इस ब्रॉडकास्टसीवर को पदावनत किया जाएगा, और निम्नलिखित विकल्पों का वर्णन developer.android.com पर किया जाएगा:

JobScheduler;
SyncAdapter;
DownloadManager;
विंडो के लिए FLAG_KEEP_SCREEN_ON।

Android 6. मार्शमैलो

DozeMode: चलते-चलते सो जाओ

तब Google ने डिवाइस पर चलने वाले एप्लिकेशन के लिए कई अनुकूलन शुरू किए। लेकिन उपयोगकर्ता के लिए जो अनुकूलन है वह डेवलपर के लिए एक सीमा है।

पहला कदम DozeMode था, जो एक निश्चित समय के लिए बेकार होने पर डिवाइस को स्लीप मोड में डाल देता है। पहले संस्करणों में, यह एक घंटे तक चलता था, बाद के संस्करणों में नींद की अवधि 30 मिनट तक कम हो गई थी। समय-समय पर, फोन उठता है, सभी लंबित कार्यों को करता है और फिर से सो जाता है। DozeMode विंडो तेजी से फैलती है। मोड के बीच सभी संक्रमणों को अदब के माध्यम से ट्रैक किया जा सकता है।

जब DozeMode होता है, तो आवेदन पर निम्नलिखित प्रतिबंध लगाए जाते हैं:

सिस्टम सभी WakeLock को अनदेखा करता है;
अलार्म मैनजर में देरी हो रही है;
जॉबस्क्रूडर काम नहीं करता है;
सिंक एडेप्टर काम नहीं करता है;
नेटवर्क की पहुंच सीमित है।

आप अपने एप्लिकेशन को श्वेतसूची में भी जोड़ सकते हैं ताकि यह DozeMode की सीमाओं के अंतर्गत न आए, लेकिन कम से कम सैमसंग ने इस सूची को पूरी तरह से अनदेखा कर दिया।

Android 6. मार्शमैलो

AppStandby: निष्क्रिय अनुप्रयोग

सिस्टम उन अनुप्रयोगों की पहचान करता है जो निष्क्रिय हैं, और उन पर सभी प्रतिबंध लगाते हैं जैसे कि DozeMode में।
एक आवेदन अलगाव के लिए भेजा जाता है अगर:

अग्रभूमि में एक प्रक्रिया नहीं है;
एक सक्रिय अधिसूचना नहीं है;
अपवर्जन सूची में नहीं जोड़ा गया।

Android 7. नूगाट

पृष्ठभूमि अनुकूलन। दुर्बल

Svelte एक परियोजना है जिसमें Google अनुप्रयोगों और सिस्टम द्वारा रैम की खपत को अनुकूलित करने की कोशिश कर रहा है।
एंड्रॉइड 7 में, इस परियोजना के ढांचे के भीतर, यह निर्णय लिया गया था कि निहित प्रसारण बहुत प्रभावी नहीं हैं, क्योंकि उन्हें बड़ी संख्या में अनुप्रयोगों द्वारा सुना जाता है और जब ये घटनाएं होती हैं तो सिस्टम बड़ी मात्रा में संसाधन खर्च करता है। इसलिए, निम्नलिखित प्रकार की घटनाओं को प्रकट में घोषित करने के लिए निषिद्ध किया गया था:

CONNECTIVITY_ACTION;
ACTION_NEW_PICTURE;
ACTION_NEW_VIDEO।

Android 7. नूगाट

FirebaseJobDispatcher

उसी समय, टास्क लॉन्च फ्रेमवर्क का एक नया संस्करण प्रकाशित किया गया था - फायरबेसेज़बॉस्पाइचर। वास्तव में, यह पूरा GCM NetworkManager था, जिसे थोड़ा सा तंग किया गया और थोड़ा और लचीला बनाया गया।

नेत्रहीन, सब कुछ ठीक वैसा ही दिखता था। समान सेवा:

 public class JobSchedulerService extends JobService { @Override public boolean onStartJob(JobParameters params) { doWork(params); return false; } @Override public boolean onStopJob(JobParameters params) { return false; } }

उनके बीच एकमात्र अंतर उनके ड्राइवर को स्थापित करने की क्षमता थी। एक ड्राइवर वह वर्ग है जो कार्य लॉन्च रणनीति के लिए जिम्मेदार था।

कार्यों का लॉन्च समय के साथ नहीं बदला है।

 FirebaseJobDispatcher dispatcher = new FirebaseJobDispatcher(new GooglePlayDriver(context)); Job task = dispatcher.newJobBuilder() .setService(FirebaseJobDispatcherService.class) .setTag(TAG) .setConstraints(Constraint.ON_UNMETERED_NETWORK, Constraint.DEVICE_IDLE) .build(); dispatcher.mustSchedule(task);

पेशेवरों :
JobScheduler के समान एपीआई;
उपलब्ध एपीआई 9 के साथ शुरू।

विपक्ष :
आपके पास Google Play Services होना चाहिए
गलती करना आसान है।

जीपीएस से छुटकारा पाने के लिए मेरे ड्राइवर को स्थापित करना उत्साहजनक था। हमने भी खोज की, लेकिन अंततः निम्नलिखित पाया:

Google यह जानता है, लेकिन ये कार्य कई वर्षों तक खुले रहते हैं।

Android 7. नूगाट

Android नौकरी एवरनोट द्वारा

परिणामस्वरूप, समुदाय इसे बर्दाश्त नहीं कर सका, और एवरनोट से पुस्तकालय के रूप में एक स्व-निर्मित समाधान दिखाई दिया। यह केवल एक ही नहीं था, लेकिन यह एवरनोट से समाधान था जो खुद को स्थापित करने में सक्षम था और "लोगों में मिला"।

वास्तुकला की दृष्टि से, यह पुस्तकालय अपने पूर्ववर्तियों की तुलना में अधिक सुविधाजनक था।
कार्य बनाने के लिए जिम्मेदार संस्था प्रकट हुई है। जोबसेक्यूलर के मामले में, वे प्रतिबिंब के माध्यम से बनाए गए थे।

 class SendLogsJobCreator : JobCreator { override fun create(tag: String): Job? { when (tag) { SendLogsJob.TAG -> return SendLogsJob() } return null } }

एक अलग वर्ग है, जो स्वयं कार्य है। JobScheduler में, यह सब onStartJob के अंदर एक स्विच में डंप किया गया था।

 class SendLogsJob : Job() { override fun onRunJob(params: Params): Result { return doWork(params) } }

कार्यों का प्रक्षेपण समान है, लेकिन विरासत में मिली घटनाओं के अलावा, एवरनोट ने भी अपना स्वयं का जोड़ा, जैसे कि दैनिक कार्यों को शुरू करना, अद्वितीय कार्य, और खिड़की के भीतर लॉन्च करना।

 new JobRequest.Builder(JOB_ID) .setRequiresDeviceIdle(true) .setRequiresCharging(true) .setRequiredNetworkType(JobRequest.NetworkType.UNMETERED) .build() .scheduleAsync();

पेशेवरों :
सुविधाजनक एपीआई;
सभी संस्करणों पर समर्थित;
Google Play Services की आवश्यकता नहीं है।

विपक्ष :
तृतीय-पक्ष समाधान।

लोगों ने सक्रिय रूप से अपने पुस्तकालय का समर्थन किया। हालाँकि कुछ महत्वपूर्ण मुद्दे थे, यह सभी संस्करणों और सभी उपकरणों पर काम करता था। नतीजतन, पिछले साल हमारी एंड्रॉइड टीम ने एवरनोट से एक समाधान चुना, क्योंकि Google के पुस्तकालयों ने उपकरणों की एक बड़ी परत को काट दिया जो वे समर्थन नहीं कर सकते।
अंदर, उसने Google से समाधान पर, चरम मामलों में - अलार्ममैन के साथ काम किया।

Android 8. ओरियो

पृष्ठभूमि निष्पादन सीमाएँ

आइए अपनी सीमाओं पर वापस जाएं। नए एंड्रॉइड के आगमन के साथ, नए अनुकूलन आए हैं। Google के लोगों ने एक और समस्या पाई। इस बार पूरी चीज़ सेवाओं और प्रसारणों में बदल गई (हाँ, कुछ भी नया नहीं है)।

~~startService यदि पृष्ठभूमि में अनुप्रयोग~~
~~प्रकट में निहित प्रसारण~~

सबसे पहले, पृष्ठभूमि से सेवाएं शुरू करने से मना किया गया था। "कानून के ढांचे" में केवल अग्रभूमि सेवाएं ही रहीं। सेवाओं को अब पदावनत कहा जा सकता है।
दूसरी सीमा एक ही प्रसारण है। इस बार प्रकट में सभी निहित प्रसारणों को पंजीकृत करना निषिद्ध हो गया। इम्प्लांटेड ब्रॉडकास्ट एक ब्रॉडकास्ट है, जो न केवल हमारे आवेदन के लिए है। उदाहरण के लिए, क्रिया ACTION_PACKAGE_REPLACED है, और ACTION_MY_PACKAGE_REPLACED है। तो, पहला वाला निहित है।

लेकिन किसी भी प्रसारण को अभी भी Context.registerBroadcast के माध्यम से पंजीकृत किया जा सकता है।

Android 9. पाई

WorkManager

इस पर अनुकूलन अभी तक रुक गया है। शायद ऊर्जा की खपत के संदर्भ में उपकरणों ने जल्दी और सावधानी से काम करना शुरू किया; शायद उपयोगकर्ताओं ने इसके बारे में कम शिकायत की है।
एंड्रॉइड 9 में, फ्रेमवर्क के डेवलपर्स ने लॉन्चिंग कार्यों के लिए उपकरण से पूरी तरह से संपर्क किया। सभी दबाने वाली समस्याओं को हल करने के प्रयास में, Google I / O पर WorkManager के पृष्ठभूमि कार्यों को शुरू करने के लिए एक पुस्तकालय शुरू किया गया था।

Google हाल ही में एंड्रॉइड एप्लिकेशन की वास्तुकला की अपनी दृष्टि को आकार देने की कोशिश कर रहा है और डेवलपर्स को इसके लिए आवश्यक उपकरण देता है। इसलिए लाइवडैट, व्यूमॉडल और रूम के साथ वास्तुशिल्प घटक थे। WorkManager उनके दृष्टिकोण और प्रतिमान के लिए एक उचित पूरक की तरह दिखता है।

अगर हम इस बारे में बात करते हैं कि वर्कमैन को अंदर व्यवस्थित कैसे किया जाता है, तो इसमें कोई तकनीकी सफलता नहीं है। वास्तव में, यह मौजूदा समाधानों का एक आवरण है: जॉबसेक्यूलर, फायरबेसजोबडिसपैचर और अलार्ममैन।

createBestAvailableBackgroundScheduler

 static Scheduler createBestAvailableBackgroundScheduler(Context, WorkManager) { if (Build.VERSION.SDK_INT >= MIN_JOB_SCHEDULER_API_LEVEL) { return new SystemJobScheduler(context, workManager); } try { return tryCreateFirebaseJobScheduler(context); } catch (Exception e) { return new SystemAlarmScheduler(context); } }

चयन कोड बहुत सरल है। लेकिन यह ध्यान दिया जाना चाहिए कि JobScheduler API 21 के साथ उपलब्ध है, लेकिन वे इसका उपयोग केवल API 23 के साथ करते हैं, क्योंकि पहले संस्करण अस्थिर नहीं थे।

यदि संस्करण 23 से कम है, तो प्रतिबिंब के माध्यम से हम फायरबेसबेसबाइस्पैचर को खोजने की कोशिश करते हैं, अन्यथा हम अलार्म मैनजर का उपयोग करते हैं।

यह ध्यान देने योग्य है कि रैपर काफी लचीला निकला। इस बार, डेवलपर्स ने अलग-अलग संस्थाओं में सब कुछ तोड़ दिया, और वास्तुशिल्प रूप से यह सुविधाजनक लगता है:

कार्यकर्ता - कार्य तर्क;
WorkRequest - कार्य लॉन्च का तर्क;
WorkRequest.Builder - पैरामीटर;
बाधाएं - स्थितियां;
कार्य प्रबंधक - एक प्रबंधक जो कार्यों का प्रबंधन करता है;
वर्कस्टैटस - कार्य की स्थिति।

लॉन्च की शर्तों को जॉबसेक्यूलर से विरासत में मिला था।
यह ध्यान दिया जा सकता है कि यूआरआई को बदलने का ट्रिगर केवल एपीआई 23 के साथ दिखाई दिया। इसके अलावा, आप न केवल एक विशिष्ट यूआरआई के परिवर्तन की सदस्यता ले सकते हैं, बल्कि विधि में ध्वज का उपयोग करते हुए इसमें सभी नेस्टेड भी कर सकते हैं।

यदि हम हमारे बारे में बात करते हैं, तो अल्फा चरण में, वर्कमैनर पर स्विच करने का निर्णय लिया गया था।
इसके कई कारण हैं। एवरनोट में कुछ महत्वपूर्ण कीड़े हैं जो पुस्तकालय के डेवलपर्स को एकीकृत वर्कमैन के साथ एक संस्करण में संक्रमण के साथ ठीक करने का वादा करते हैं। और वे स्वयं इस बात से सहमत हैं कि Google का निर्णय एवरनोट के लाभों को नकारता है। इसके अलावा, यह समाधान हमारी वास्तुकला के साथ अच्छी तरह से फिट बैठता है, क्योंकि हम वास्तुकला घटकों का उपयोग करते हैं।

इसके अलावा, मैं एक सरल उदाहरण के साथ दिखाना चाहूंगा कि हम इस दृष्टिकोण का उपयोग कैसे कर रहे हैं। उसी समय, यह बहुत महत्वपूर्ण नहीं है कि आपके पास वर्कमैनर या जॉबस्क्राइडर है या नहीं।

आइए एक बहुत ही सरल मामले के साथ एक उदाहरण देखें: पुनर्प्रकाशित या पसंद पर क्लिक करना।

अब सभी एप्लिकेशन नेटवर्क को अवरुद्ध अनुरोधों से दूर होने की कोशिश कर रहे हैं, क्योंकि यह उपयोगकर्ता को परेशान करता है और उसे प्रतीक्षा करता है, हालांकि इस समय वह आवेदन के अंदर खरीदारी कर सकता है या विज्ञापन देख सकता है।

ऐसे मामलों में, स्थानीय डेटा पहले बदल जाता है - उपयोगकर्ता तुरंत अपनी कार्रवाई का परिणाम देखता है। फिर पृष्ठभूमि में सर्वर के लिए एक अनुरोध है, यदि विफल रहता है, तो डेटा अपनी प्रारंभिक स्थिति में रीसेट हो जाता है।

आगे, मैं एक उदाहरण दिखाऊंगा कि यह हमारे साथ कैसा दिखता है।

JobRunner में कार्यों को शुरू करने के लिए तर्क हैं। उनके तरीके कार्यों के विन्यास का वर्णन करते हैं और मापदंडों को पास करते हैं।

JobRunner.java

 fun likePost(content: IFunnyContent) { val constraints = Constraints.Builder() .setRequiredNetworkType(NetworkType.CONNECTED) .build() val input = Data.Builder() .putString(LikeContentJob.ID, content.id) .build() val request = OneTimeWorkRequest.Builder(LikeContentJob::class.java) .setInputData(input) .setConstraints(constraints) .build() WorkManager.getInstance().enqueue(request) }

कार्य प्रबंधक के भीतर कार्य स्वयं इस प्रकार है: हम मापदंडों से आईडी लेते हैं और इस सामग्री को पसंद करने के लिए सर्वर पर विधि कहते हैं।

हमारे पास एक आधार वर्ग है जिसमें निम्नलिखित तर्क हैं:

 abstract class BaseJob : Worker() { final override fun doWork(): Result { val workerInjector = WorkerInjectorProvider.injector() workerInjector.inject(this) return performJob(inputData) } abstract fun performJob(params: Data): Result }

सबसे पहले, यह आपको कार्यकर्ता के स्पष्ट ज्ञान से थोड़ा सा दूर होने की अनुमति देता है। इसमें WorkerInjector के माध्यम से निर्भरता इंजेक्शन तर्क भी शामिल है।

WorkerInjectorImpl.java

 @Singleton public class WorkerInjectorImpl implements WorkerInjector { @Inject public WorkerInjectorImpl() {} @Ovierride public void inject(Worker job) { if (worker instanceof AppCrashedEventSendJob) { Injector.getAppComponent().inject((AppCrashedEventSendJob) job); } else if (worker instanceof CheckNativeCrashesJob) { Injector.getAppComponent().inject((CheckNativeCrashesJob) job); } } }

यह केवल डैगर को कॉल करता है, लेकिन यह हमें परीक्षण में मदद करता है: हम इंजेक्टर कार्यान्वयन को प्रतिस्थापित करते हैं और कार्यों में आवश्यक वातावरण लागू करते हैं।

 fun void testRegisterPushProvider() { WorkManagerTestInitHelper.initializeTestWorkManager(context) val testDriver = WorkManagerTestInitHelper.getTestDriver() WorkerInjectorProvider.setInjector(TestInjector()) // mock dependencies val id = jobRunner.runPushRegisterJob() testDriver.setAllConstraintsMet(id) Assert.assertTrue(…) }

 class LikePostInteractor @Inject constructor( val iFunnyContentDao: IFunnyContentDao, val jobRunner: JobRunner) : Interactor { fun execute() { iFunnyContentDao.like(getContent().id) jobRunner.likePost(getContent()) } }

इंटरेक्टर वह इकाई है जिसे ViewController स्क्रिप्ट (इस मामले में, जैसे यह) के पारित होने की शुरुआत करने के लिए खींचती है। हम सामग्री को स्थानीय रूप से "अपलोड" के रूप में चिह्नित करते हैं और निष्पादन के लिए कार्य सबमिट करते हैं। यदि कार्य विफल हो जाता है, तो जैसे हटा दिया जाता है।

 class IFunnyContentViewModel(val iFunnyContentDao: IFunnyContentDao) : ViewModel() { val likeState = MediatorLiveData<Boolean>() var iFunnyContentId = MutableLiveData<String>() private var iFunnyContentState: LiveData<IFunnyContent> = attachLiveDataToContentId(); init { likeState.addSource(iFunnyContentState) { likeState.postValue(it!!.hasLike) } } }

हम Google के आर्किटेक्चर घटकों का उपयोग करते हैं: ViewModel और LiveData। यह हमारा ViewModel जैसा दिखता है। यहां हम DAO में ऑब्जेक्ट के अपडेट को जैसे की स्थिति से जोड़ते हैं।

IFunnyContentViewController.java

 class IFunnyContentViewController @Inject constructor( private val likePostInteractor: LikePostInteractor, val viewModel: IFunnyContentViewModel) : ViewController { override fun attach(view: View) { viewModel.likeState.observe(lifecycleOwner, { updateLikeView(it!!) }) } fun onLikePost() { likePostInteractor.setContent(getContent()) likePostInteractor.execute() } }

ViewController, एक तरफ, दूसरी ओर की तरह की स्थिति को बदलने के लिए सदस्यता लेता है, दूसरी ओर उस स्क्रिप्ट के पारित होने की शुरुआत करता है जिसकी हमें ज़रूरत है।

और यह व्यावहारिक रूप से हमारे लिए आवश्यक सभी कोड है। यह अपने डीएओ के समान और कार्यान्वयन के साथ दृश्य के व्यवहार को जोड़ने के लिए बनी हुई है; यदि आप कक्ष का उपयोग करते हैं, तो बस ऑब्जेक्ट में फ़ील्ड पंजीकृत करें। यह बहुत सरल और प्रभावी दिखता है।

संक्षेप में देना

जॉबसेक्यूलर, GCM नेटवर्क मैनेजर, FirebaseJobDispatcher:

उनका उपयोग न करें
अब उनके बारे में लेख न पढ़ें
रिपोर्ट न देखें
यह मत सोचो कि किसे चुनना है।

एवरनोट द्वारा Android नौकरी:

अंदर वे WorkManager का उपयोग करेंगे;
महत्वपूर्ण कीड़े समाधान के बीच धुंधले हैं।

WorkManager:

एपीआई स्तर 9+;
Google Play सेवाओं से स्वतंत्र;
जंजीर / InputMergers;
प्रतिक्रियाशील दृष्टिकोण;
Google से समर्थन (मैं यह मानना चाहता हूं)।

कार्य अनुसूचक विकास