भोजन में कोरटाइन का उपयोग कैसे करें और रात में शांति से सोएं

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

एप्सकॉन्फ़ पर व्लादिमीर इवानोव की रिपोर्ट इस तथ्य के बारे में है कि शैतान इतना भयानक नहीं है और आप अभी कोरटाइन का उपयोग कर सकते हैं:

• कोरटाइन क्यों, RxJava नहीं ;
• डेवलपर्स में क्या डर है ;
• कोरटाइन का उपयोग करके कैश कैसे बनाया जाए ;
• त्रुटियों को सही तरीके से कैसे संभालें ।

स्पीकर के बारे में : व्लादिमीर इवानोव ( dzigoro ) 7 साल के अनुभव के साथ EPAM में एक प्रमुख एंड्रॉइड डेवलपर है, सॉल्यूशन आर्किटेक्चर, रिएक्ट नेटिव और iOS डेवलपमेंट का शौकीन है, और इसके पास Google क्लाउड आर्किटेक्ट सर्टिफिकेट भी है।

आप जो भी पढ़ते हैं वह अनुभव और विभिन्न अध्ययनों के उत्पादन का एक उत्पाद है, इसलिए इसे बिना किसी वारंटी के लें।

कोराटाइन, कोटलिन और आरएक्सजाव

जानकारी के लिए: कोरटिन की वर्तमान स्थिति रिलीज़ में है, बाएँ बीटा। कोटलिन 1.3 जारी किया गया था, कोरटाइन को स्थिर घोषित किया गया है और दुनिया में शांति है।



मैंने हाल ही में ट्विटर पर एक सर्वेक्षण किया था जिसमें लोग कोरटाइन का उपयोग कर रहे थे:

• भोजन में 13% coroutines। सब ठीक है;
• 25% उन्हें पालतू परियोजना में कोशिश करते हैं;
• 24% - कोटलिन क्या है?
• 38% RxJava का थोक हर जगह है।

आंकड़े खुश नहीं हैं। मेरा मानना ​​है कि RxJava उन कार्यों के लिए बहुत जटिल है, जिनमें आमतौर पर डेवलपर्स द्वारा इसका उपयोग किया जाता है। अतुल्यकालिक ऑपरेशन को नियंत्रित करने के लिए कोरीटीन अधिक उपयुक्त हैं।

अपनी पिछली रिपोर्टों में, मैंने बात की कि कैसे RxJava से कोटलिन में कॉटन के लिए रिफ्लेक्टर किया जाए, इसलिए मैं इस पर विस्तार से ध्यान नहीं दूंगा, लेकिन केवल मुख्य बिंदुओं को याद करूंगा।

हम कोरटाइन का उपयोग क्यों करते हैं?

क्योंकि यदि हम RxJava का उपयोग करते हैं, तो सामान्य कार्यान्वयन उदाहरण इस तरह दिखाई देते हैं:

interface ApiClientRx { fun login(auth: Authorization) : Single<GithubUser> fun getRepositories (reposUrl: String, auth: Authorization) : Single<List<GithubRepository>> } //RxJava 2 implementation 

हमारे पास एक इंटरफ़ेस है, उदाहरण के लिए, हम एक GitHub क्लाइंट लिखते हैं और इसके लिए कुछ संचालन करना चाहते हैं:

1. उपयोगकर्ता लॉगिन करें।
   
2. GitHub रिपॉजिटरी की एक सूची प्राप्त करें।
   

दोनों मामलों में, फ़ंक्शन एकल व्यावसायिक ऑब्जेक्ट लौटाएगा: GitHubUser या GitHubRepository की सूची।

इस इंटरफ़ेस का कार्यान्वयन कोड इस प्रकार है:

 private fun attemptLoginRx () { showProgress(true) compositeDisposable.add(apiClient.login(auth) .flatMap { user -> apiClient.getRepositories(user.repos_url, auth) } .map { list -> list.map { it.full_name } } .subscribeOn(Schedulers.io()) .observeOn(AndroidSchedulers.mainThread()) .doFinally { showProgress(false) } .subscribe( { list -> showRepositories(this, list) }, { error -> Log.e("TAG", "Failed to show repos", error) } )) } 

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

RxJava कोड कठिनाइयाँ:

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

संस्करण ०.२६ तक के कोरआउट के साथ एक ही कोड क्या होगा?

0.26 पर, एपीआई बदल गया है, और हम उत्पादन के बारे में बात कर रहे हैं। कोई भी अभी तक ठेस में 0.26 लगाने में कामयाब नहीं हुआ है, लेकिन हम इस पर काम कर रहे हैं।

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

 interface ApiClient { suspend fun login(auth: Authorization) : GithubUser suspend fun getRepositories (reposUrl: String, auth: Authorization) : List<GithubRepository> } //Base interface 

यदि आप उस कोड को देखते हैं जो पहले से ही इस इंटरफ़ेस के कार्यान्वयन का उपयोग करता है, तो यह RxJava की तुलना में काफी बदल जाएगा:

 private fun attemptLogin () { launch(UI) { val auth = BasicAuthorization(login, pass) try { showProgress(true) val userlnfo = async { apiClient.login(auth) }.await() val repoUrl = userlnfo.repos_url val list = async { apiClient.getRepositories(repoUrl, auth) }.await() showRepositories( this, list.map { it -> it.full_name } ) } catch (e: RuntimeException) { showToast("Oops!") } finally { showProgress(false) } } } 

- मुख्य कार्रवाई होती है, जहां हम कॉरटीन बिल्डर को एसिंक्स कहते हैं, एक प्रतिक्रिया की प्रतीक्षा करें और यूज़रलॉन्फो प्राप्त करें ।
- हम इस ऑब्जेक्ट से डेटा का उपयोग करते हैं।
- एक और async कॉल और कॉल वेट करें।

सब कुछ ऐसा लगता है जैसे कोई अतुल्यकालिक काम नहीं हो रहा है, और हम सिर्फ कॉलम में कमांड लिखते हैं और उन्हें निष्पादित किया जाता है। अंत में, हम वह करते हैं जो यूआई पर किया जाना चाहिए।

कोरटाइन बेहतर क्यों हैं?

• इस कोड को पढ़ना आसान है। यह लिखा है जैसे कि यह सुसंगत है।
• सबसे अधिक संभावना है कि इस कोड का प्रदर्शन RxJava की तुलना में बेहतर है।
• परीक्षण लिखना बहुत सरल है, लेकिन हम थोड़ी देर बाद उनसे मिलेंगे।

पक्ष के लिए 2 कदम

आइए थोड़ा सा पीछे हटें, कुछ बातें हैं, जिन पर अभी भी चर्चा करने की आवश्यकता है।

चरण 1।Conttext बनाम लॉन्च / async के साथ

कोरटाइन बिल्डर एसिंक्स के अलावा , कोरटाइन बिल्डर के साथ कॉन्टेक्स्ट है ।

लॉन्च करें या async एक नया Coroutine संदर्भ बनाएं, जो हमेशा आवश्यक नहीं है। यदि आपके पास एक Coroutine संदर्भ है जिसे आप पूरे अनुप्रयोग में उपयोग करना चाहते हैं, तो आपको इसे फिर से बनाने की आवश्यकता नहीं है। आप बस किसी मौजूदा का पुनः उपयोग कर सकते हैं। ऐसा करने के लिए, आपको कॉन्टेक्स्ट के साथ कॉरटीन बिल्डर की आवश्यकता होगी। यह बस मौजूदा Coroutine संदर्भ का उपयोग करता है। यह 2-3 गुना तेज होगा, लेकिन अब यह एक अप्रत्याशित सवाल है। यदि सटीक संख्याएं दिलचस्प हैं, तो यहां बेंचमार्क और विवरण के साथ स्टैकओवरफ्लो पर सवाल है ।

सामान्य नियम: बिना किसी संदेह के, जहां यह शब्दार्थिक रूप से फिट बैठता है, के साथ कॉन्टेक्स्ट का उपयोग करें। लेकिन अगर आपको समानांतर लोडिंग की आवश्यकता है, उदाहरण के लिए कई चित्र या डेटा के टुकड़े, तो async / इंतजार आपकी पसंद है।

चरण 2. रिफलेक्टरिंग

यदि आप वास्तव में जटिल RxJava श्रृंखला को रिफैक्टर करते हैं तो क्या होगा? मैं इस निर्माण में आया था:

 observable1.getSubject().zipWith(observable2.getSubject(), (t1, t2) -> { // side effects return true; }).doOnError { // handle errors } .zipWith(observable3.getSubject(), (t3, t4) -> { // side effects return true; }).doOnComplete { // gather data } .subscribe() 

मेरे पास एक सार्वजनिक विषय के साथ एक जटिल श्रृंखला थी, प्रत्येक ज़िप में ज़िप और साइड इफेक्ट के साथ जिसने इवेंट बस में कुछ और भेजा था। कम से कम कार्य को इवेंट बस से छुटकारा पाना था। मैं एक दिन के लिए बैठा, लेकिन समस्या को हल करने के लिए कोड को फिर से पचा नहीं सका। सही निर्णय सब कुछ बाहर फेंकने और 4 घंटे में कोरटाइन पर कोड को फिर से लिखने के लिए निकला ।

नीचे दिया गया कोड मेरे द्वारा प्राप्त किए गए समान है:

 try { val firstChunkJob = async { call1 } val secondChunkJob = async { call2 } val thirdChunkJob = async { call3 } return Result( firstChunkJob.await(), secondChunkJob.await(), thirdChunkJob.await()) } catch (e: Exception) { // handle errors } 

- हम दूसरे और तीसरे के लिए, एक काम के लिए एसिंक्स करते हैं।
- हम परिणाम की प्रतीक्षा कर रहे हैं और इसे एक वस्तु में डाल दिया है।
- हो गया!

यदि आपके पास जटिल जंजीरें हैं और कोरटाइन हैं, तो बस रिफ्लेक्टर। यह वास्तव में तेज है।

क्या ठगों में डेवलपर्स को कोरटाइन का उपयोग करने से रोकता है?

मेरी राय में, हम, डेवलपर्स के रूप में, वर्तमान में केवल कुछ नए के डर से कोरटाइन का उपयोग करने से रोका जाता है:

• हम जीवन चक्र , गतिविधि और टुकड़े जीवन चक्र के साथ क्या करना है पता नहीं है। इन मामलों में कोरआउट के साथ कैसे काम करें?
• कोरुटिन का उपयोग करके उत्पादन में दैनिक जटिल कार्यों को हल करने का कोई अनुभव नहीं है।
• पर्याप्त उपकरण नहीं। पुस्तकालयों और कार्यों का एक समूह RxJava के लिए लिखा गया है। उदाहरण के लिए RxFCM । RxJava में बहुत सारे ऑपरेटर हैं, जो कि अच्छा है, लेकिन कोरटाइन के बारे में क्या?
• हम वास्तव में यह नहीं समझते हैं कि कोरटाइन का परीक्षण कैसे किया जाता है।

अगर हम इन चार आशंकाओं से छुटकारा पा लेते हैं, तो हम रात को शांति से सो सकते हैं और उत्पादन में कोरटाइन का उपयोग कर सकते हैं।

बिंदु से बात करते हैं।

1. जीवनचक्र प्रबंधन

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

बंद

क्या आप Thread.stop () से परिचित हैं? यदि आपने इसका उपयोग किया है, तो लंबे समय तक नहीं। JDK 1.1 में, विधि तुरंत अप्रचलित घोषित कर दी गई थी, क्योंकि कोड का एक निश्चित टुकड़ा लेना और रोकना असंभव है और इसकी कोई गारंटी नहीं है कि यह सही ढंग से पूरा हो जाएगा। सबसे अधिक संभावना है कि आपको केवल स्मृति भ्रष्टाचार मिलेगा।

इसलिए, थ्रेड.स्टॉप () काम नहीं करता है । आपको सहकारी होने के लिए रद्दीकरण की आवश्यकता है, अर्थात, दूसरी तरफ कोड यह जानने के लिए कि आप इसे रद्द कर रहे हैं।

हम RxJava के साथ स्टॉप कैसे लागू करते हैं:

 private val compositeDisposable = CompositeDisposable() fun requestSmth() { compositeDisposable.add( apiClientRx.requestSomething() .subscribeOn(Schedulers.io()) .observeOn(AndroidSchedulers.mainThread()) .subscribe(result -> {}) } override fun onDestroy() { compositeDisposable.dispose() } 

RxJava में हम कम्पोजिटडिसोप्रोजेक्ट का उपयोग करते हैं ।

- खंड में या प्रस्तुतकर्ता में गतिविधि के लिए चर कंपोजिटोप्लॉरी जोड़ें, जहां हम RxJava का उपयोग करते हैं।
- onDestro y में Dispose जोड़ें और सभी अपवाद खुद से दूर हो जाते हैं।

कोरटाइन के साथ लगभग एक ही सिद्धांत:

 private val job: Job? = null fun requestSmth() { job = launch(UI) { val user = apiClient.requestSomething() … } } override fun onDestroy() { job?.cancel() } 

एक साधारण कार्य के एक उदाहरण पर विचार करें।

आमतौर पर, coroutine बिल्डरों की नौकरी वापस आ जाती है, और कुछ मामलों में आस्थगित कर दिया जाता है ।

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

दृष्टिकोण की समस्या क्या है? प्रत्येक नौकरी के लिए एक क्षेत्र की आवश्यकता होती है। आपको उन सभी को एक साथ रद्द करने के लिए नौकरियों की सूची बनाए रखने की आवश्यकता है। दृष्टिकोण कोड के दोहराव की ओर जाता है, ऐसा न करें।

अच्छी खबर यह है कि हमारे पास विकल्प हैं : कम्पोजिटजॉब और लाइफसाइकल-अवेयर जॉब ।

कम्पोजिटजॉब कम्पोजिटोसॉपी का एक एनालॉग है। यह कुछ इस तरह दिखता है :

 private val job: CompositeJob = CompositeJob() fun requestSmth() { job.add(launch(UI) { val user = apiClient.requestSomething() ... }) } override fun onDestroy() { job.cancel() } 

- एक टुकड़े के लिए हम एक काम शुरू करते हैं।
- हम सभी नौकरी कम्पोजिटजोब में रखते हैं और कमांड देते हैं: "job.cancel () हर किसी के लिए!" ।

दृष्टिकोण को आसानी से 4 लाइनों में लागू किया जाता है, वर्ग घोषणा की गिनती नहीं:

 Class CompositeJob { private val map = hashMapOf<String, Job>() fun add(job: Job, key: String = job.hashCode().toString()) = map.put(key, job)?.cancel() fun cancel(key: String) = map[key]?.cancel() fun cancel() = map.forEach { _ ,u -> u.cancel() } } 

आपको आवश्यकता होगी:

- एक स्ट्रिंग कुंजी के साथ नक्शा ,
- जोड़ें विधि, जिसमें आप नौकरी जोड़ देंगे,
- वैकल्पिक कुंजी पैरामीटर।

यदि आप एक ही काम के लिए एक ही कुंजी का उपयोग करना चाहते हैं - तो कृपया। यदि नहीं, तो हैशकोड हमारी समस्या को हल करेगा। कार्य को मानचित्र में जोड़ें, जिसे हमने पास किया था, और पिछले एक को उसी कुंजी के साथ रद्द करें। यदि हम कार्य को पूरा करते हैं, तो पिछला परिणाम हमें रुचि नहीं देता है। हम इसे रद्द करते हैं और इसे फिर से चलाते हैं।

रद्द करना सरल है: हमें कुंजी द्वारा काम मिलता है और रद्द करना पड़ता है। दूसरा पूरा नक्शा रद्द कर देता है। सभी कोड आधे घंटे में चार लाइनों में लिखे जाते हैं और यह काम करता है। यदि आप लिखना नहीं चाहते हैं, तो ऊपर का उदाहरण लें।

जीवनचक्र से अवगत नौकरी

क्या आपने Android Lifecycle , Lifecycle के मालिक या पर्यवेक्षक का उपयोग किया है ?


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

यह काफी सरल लगता है:

 public class MyObserver implements LifecycleObserver { @OnLifecycleEvent(Lifecycle.Event.ON_RESUME) public void connectListener() { ... } @OnLifecycleEvent(Lifecycle.Event.ON_PAUSE) public void disconnectListener() { … } } 

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

 class AndroidJob(lifecycle: Lifecycle) : Job by Job(), LifecycleObserver { init { lifecycle.addObserver(this) } @OnLifecycleEvent(Lifecycle.Event.ON_DESTROY) fun destroy() { Log.d("AndroidJob", "Cancelling a coroutine") cancel() } } 

- आप आधार वर्ग AndroidJob लिख सकते हैं।
- हम जीवनचक्र को कक्षा में स्थानांतरित करेंगे।
- LifecycleObserver इंटरफ़ेस नौकरी को लागू करेगा।

हम सभी की जरूरत है:

- कंस्ट्रक्टर में ऑब्जर्वर के रूप में लाइफसाइकल को जोड़ें।
- ON_DESTROY या किसी और चीज़ की सदस्यता लें जो हमें रुचती है।
- ON_DESTROY में रद्द करें।
- अपने टुकड़े में एक parentJob जाओ ।
- कंस्ट्रक्टर जॉय जॉब या अपनी गतिविधि के जीवनचक्र को कॉल करें। कोई फर्क नहीं।
- इस पेरेंटजोब को पेरेंट के रूप में पास करें।

समाप्त कोड इस तरह दिखता है:

 private var parentJob = AndroidJob(lifecycle) fun do() { job = launch(UI, parent = parentJob) { // code } } 

जब आप माता-पिता को रद्द कर देते हैं, तो सभी बाल कोरआउट रद्द कर दिए जाते हैं और अब आपको टुकड़े में कुछ भी लिखने की आवश्यकता नहीं है। सब कुछ अपने आप होता है, कोई और नहीं ON_DESTROY। मुख्य बात यह है कि माता-पिता = parentJob पास करना न भूलें।

यदि आप उपयोग करते हैं, तो आप एक सरल लिंट नियम लिख सकते हैं जो आपको उजागर करेगा: "ओह, आप अपने माता-पिता को भूल गए!"

सी   जीवनचक्र प्रबंधन की छंटनी की। हमारे पास कुछ उपकरण हैं जो आपको यह सब आसानी से और आराम से करने की अनुमति देते हैं।

उत्पादन में जटिल परिदृश्य और गैर-तुच्छ कार्यों के बारे में क्या?

2. जटिल उपयोग-मामले

जटिल परिदृश्य और गैर-तुच्छ कार्य हैं:

- ऑपरेटर्स - RxJava में कॉम्प्लेक्स ऑपरेटर्स: फ्लैटपेज़, डेब्यू आदि।
- त्रुटि से निपटने - जटिल त्रुटि से निपटने। न केवल प्रयास करें..चेक करें , बल्कि उदाहरण के लिए नेस्ट करें।
- कैशिंग एक गैर तुच्छ कार्य है। उत्पादन में, हम एक कैश में भाग गए और कोरटाइन के साथ कैशिंग समस्या को आसानी से हल करने के लिए एक उपकरण प्राप्त करना चाहते थे।

दोहराना

जब हमने कोरआउट के लिए ऑपरेटरों के बारे में सोचा था, तो पहला विकल्प रिपीट किया गया था।

अगर कुछ गलत हुआ और कोरुटिन अंदर सर्वर तक पहुंचने में असमर्थ था, तो हम किसी तरह के एक्सपोनेंट कमबैक के साथ कई बार रिट्रीट करना चाहते हैं। शायद कारण खराब कनेक्शन है और हम कई बार ऑपरेशन दोहराकर वांछित परिणाम प्राप्त करेंगे।

कोरआउट के साथ, यह कार्य आसानी से लागू होता है:

 suspend fun <T> retryDeferredWithDelay( deferred: () -> Deferred<T>, tries: Int = 3, timeDelay: Long = 1000L ): T { for (i in 1..tries) { try { return deferred().await() } catch (e: Exception) { if (i < tries) delay(timeDelay) else throw e } } throw UnsupportedOperationException() } 

ऑपरेटर कार्यान्वयन:

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

फ़ंक्शन को आसानी से अनुकूलित किया जा सकता है: एक घातीय विलंब डालें या एक लंबो फ़ंक्शन पास करें जो परिस्थितियों के आधार पर विलंब की गणना करेगा।

यह प्रयोग करें, यह काम करता है!

ज़िप

हम भी अक्सर उनका सामना करते हैं। यहाँ फिर से, सब कुछ सरल है:

 suspend fun <T1, T2, R> zip( source1: Deferred<T1>, source2: Deferred<T2>, zipper: BiFunction<T1, T2, R>): R { return zipper.apply(sourcel.await(), source2.await()) } suspend fun <T1, T2, R> Deferred<T1>.zipWith( other: Deferred<T2>, zipper: BiFunction<T1, T2, R>): R { return zip(this, other, zipper) } 

- जिपर का प्रयोग करें और अपने Deferred पर प्रतीक्षा करें।
- आस्थगित के बजाय, आप सस्पेंड फ़ंक्शन और कोरटाइन बिल्डर का उपयोग कर सकते हैं। आप अपनी जरूरत के संदर्भ को बताएंगे।

यह फिर से काम करता है और मुझे उम्मीद है कि मैंने इस डर को दूर कर दिया।

कैश

क्या आपके पास RxJava के उत्पादन में कैश कार्यान्वयन है? हम RxCache का उपयोग करते हैं।


बाईं ओर आरेख में: दृश्य और दृश्यमॉडल । दाईं ओर डेटा स्रोत हैं: नेटवर्क कॉल और डेटाबेस।

अगर हम चाहते हैं कि कुछ कैश किया जाए, तो कैश डेटा का दूसरा स्रोत होगा।

कैश के प्रकार:

• नेटवर्क कॉल के लिए नेटवर्क स्रोत ।
• इन-मेमोरी कैश ।
• समाप्ति पर निरंतर कैश डिस्क पर संग्रहीत किया जाता है ताकि कैश एप्लिकेशन पुनरारंभ होने से बच जाए।

तीसरे मामले के लिए एक सरल और आदिम कैश लिखें। कॉरटीन बिल्डर कॉन्टेक्स्ट फिर से बचाव में आता है।

 launch(UI) { var data = withContext(dispatcher) { persistence.getData() } if (data == null) { data = withContext(dispatcher) { memory.getData() } if (data == null) { data = withContext(dispatcher) { network.getData() } memory.cache(url, data) persistence.cache(url, data) } } } 

- आप प्रत्येक ऑपरेशन को कॉनटेक्स्ट के साथ निष्पादित करते हैं और देखते हैं कि कोई डेटा आ रहा है या नहीं।
- यदि दृढ़ता से डेटा नहीं आता है, तो आप इसे मेमोरी.चैच से प्राप्त करने का प्रयास कर रहे हैं।
- यदि कोई मैमोरी.चेच नहीं है, तो नेटवर्क स्रोत से संपर्क करें और अपना डेटा प्राप्त करें। बेशक, सभी कैश में डालने के लिए मत भूलना।

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

Rx में RxCache है

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

उदाहरण के लिए, आप यह कहना चाहते हैं कि यह डेटा 15 मिनट के बाद समाप्त हो जाएगा: "कृपया, इस अवधि के बाद, कैश से डेटा न भेजें, लेकिन मुझे ताज़ा डेटा भेजें।"

पुस्तकालय अद्भुत है कि यह टीम को घोषित रूप से समर्थन करता है। घोषणा बहुत कुछ वैसा ही है जैसा आप रेट्रोफिट के साथ करते हैं:

 public interface FeatureConfigCacheProvider { @ProviderKey("features") @LifeCache(duration = 15, timeUnit = TimeUnit.MINUTES) fun getFeatures( result: Observable<Features>, cacheName: DynamicKey ): Observable<Reply<Features>> } 

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

उपयोग काफी सरल है:

 val restObservable = configServiceRestApi.getFeatures() val features = featureConfigCacheProvider.getFeatures( restObservable, DynamicKey(CACHE_KEY) ) 

- Rx कैश से, RestApi का उपयोग करें ।
- कैशेप्रॉइडर की ओर मुड़ें ।
- उसे एक ऑब्जर्वेबल खिलाएं।
- पुस्तकालय खुद पता लगाएगा कि क्या करना है: कैश पर जाएं या नहीं, अगर समय खत्म हो जाता है, तो ऑब्जर्वेबल की ओर मुड़ें और दूसरा ऑपरेशन करें।

पुस्तकालय का उपयोग करना बहुत सुविधाजनक है और मैं कोरटाइन के लिए एक समान प्राप्त करना चाहूंगा।

विकास में कोराटाइन कैश

EPAM के अंदर, हम Coroutine Cache लाइब्रेरी लिख रहे हैं, जो RxCache के सभी कार्यों का प्रदर्शन करेगी। हमने पहला संस्करण लिखा और इसे कंपनी के अंदर चलाया। जैसे ही पहली रिलीज होगी, मैं इसे अपने ट्विटर पर पोस्ट करके खुश रहूंगा। यह इस तरह दिखेगा:

 val restFunction = configServiceRestApi.getFeatures() val features = withCache(CACHE_KEY) { restFunction() } 

हम एक निलंबन समारोह getFeatures होगा । हम फ़ंक्शन को एक विशेष उच्च-क्रम फ़ंक्शन के लिए एक ब्लॉक के रूप में पास करेंगे जिसमें कैश होगा, जो यह पता लगाएगा कि क्या करने की आवश्यकता है।

शायद हम घोषणात्मक कार्यों का समर्थन करने के लिए एक ही इंटरफ़ेस बनाएंगे।

हैंडलिंग में त्रुटि

सरल त्रुटि से निपटने अक्सर डेवलपर्स द्वारा पाया जाता है और आमतौर पर काफी सरल रूप से हल किया जाता है। यदि आपके पास जटिल चीजें नहीं हैं, तो पकड़ने के लिए आप अपवाद को पकड़ते हैं और वहां जो हुआ है उसे देखें, लॉग को लिखें या उपयोगकर्ता को एक त्रुटि दिखाएं। यूआई पर, आप आसानी से ऐसा कर सकते हैं।

सरल मामलों में, सब कुछ अपेक्षित रूप से सरल है - कोरटाइन के साथ त्रुटि से निपटने की कोशिश-कैच- एंड के माध्यम से की जाती है।

उत्पादन में, साधारण मामलों के अलावा, निम्न हैं:

- नेस्टेड कैच ,
- कई अलग-अलग प्रकार के अपवाद ,
- नेटवर्क में या व्यावसायिक तर्क में त्रुटियां,
- उपयोगकर्ता जानकारी। उसने फिर कुछ गलत किया और उसे हर चीज के लिए दोषी ठहराया।

हमें इसके लिए तैयार रहना चाहिए।

2 समाधान हैं: CoroutineExceptionHandler और परिणाम वर्गों के साथ दृष्टिकोण।

Coroutine अपवाद हैंडलर

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

हम आम तौर पर जटिल त्रुटियों को कैसे संभालते हैं?

उपयोगकर्ता ने कुछ दबाया, बटन काम नहीं किया। उसे यह कहने की ज़रूरत है कि क्या गलत हुआ और इसे एक विशिष्ट कार्रवाई के लिए निर्देशित करें: इंटरनेट, वाई-फाई की जांच करें, बाद में प्रयास करें या एप्लिकेशन को हटा दें और इसे फिर से उपयोग न करें। उपयोगकर्ता को यह कहना काफी सरल हो सकता है:

 val handler = CoroutineExceptionHandler(handler = { , error -> hideProgressDialog() val defaultErrorMsg = "Something went wrong" val errorMsg = when (error) { is ConnectionException -> userFriendlyErrorMessage(error, defaultErrorMsg) is HttpResponseException -> userFriendlyErrorMessage(Endpoint.EndpointType.ENDPOINT_SYNCPLICITY, error) is EncodingException -> "Failed to decode data, please try again" else -> defaultErrorMsg } Toast.makeText(context, errorMsg, Toast.LENGTH_SHORT).show() }) 

- चलो डिफ़ॉल्ट संदेश प्राप्त करें: "कुछ गलत हो गया!" और अपवाद का विश्लेषण करें।
- यदि यह एक कनेक्शन है, तो हम संसाधनों से एक स्थानीय संदेश लेते हैं: “यार, वाई-फाई चालू करो और तुम्हारी समस्याएं दूर हो जाएंगी। मैं इसकी गारंटी देता हूं। ”
- अगर सर्वर ने कुछ गलत कहा है , तो आपको क्लाइंट को बताने की जरूरत है: "लॉग आउट करें और फिर से लॉग इन करें", या "मॉस्को में ऐसा न करें, दूसरे देश में ऐसा करें", या "सॉरी, कॉमरेड। मैं बस इतना ही कह सकता हूं कि कुछ गलत हुआ है।
- अगर यह एक पूरी तरह से अलग गलती है , उदाहरण के लिए, स्मृति से बाहर , हम कहते हैं: "कुछ गलत हुआ, मुझे क्षमा करें।"
- सभी संदेश प्रदर्शित होते हैं।

आप CoroutineExceptionHandler को जो लिखते हैं, उसे उसी डिस्पैचर पर निष्पादित किया जाएगा, जहाँ आप coroutine चलाते हैं। इसलिए, यदि आप "लॉन्च" यूआई कमांड देते हैं, तो सब कुछ यूआई पर होता है। आपको अलग-अलग प्रेषण की आवश्यकता नहीं है , जो बहुत सुविधाजनक है।

उपयोग सरल है:

 launch(uiDispatcher + handler) { ... } 

एक प्लस ऑपरेटर है। Coroutine के संदर्भ में, एक हैंडलर जोड़ें और सब कुछ काम करता है, जो बहुत सुविधाजनक है। हमने कुछ समय के लिए इसका इस्तेमाल किया।

परिणाम कक्षाएं

बाद में हमने महसूस किया कि CoroutineExceptionHandler गायब हो सकता है। परिणाम, जो कोरटाइन के काम से बनता है, इसमें कई डेटा शामिल हो सकते हैं, अलग-अलग हिस्सों से या कई स्थितियों की प्रक्रिया कर सकते हैं।

परिणाम कक्षाएं दृष्टिकोण इस समस्या से निपटने में मदद करता है:

 sealed class Result { data class Success(val payload: String) : Result() data class Error(val exception: Exception) : Result() } 

- आपके व्यावसायिक तर्क में, आप एक परिणाम वर्ग शुरू करते हैं।
- सील के रूप में चिह्नित करें।
- आपको कक्षा दो अन्य डेटा वर्गों से विरासत में मिलती है: सफलता और त्रुटि ।
— Success , .
— Error exception.

- :

 override suspend fun doTask(): Result = withContext(CommonPool) { if ( !isSessionValidForTask() ) { return@withContext Result.Error(Exception()) } … try { Result.Success(restApi.call()) } catch (e: Exception) { Result.Error(e) } } 

Coroutine context — Coroutine builder withContex .

, :

— , error. .
— RestApi -.
— , Result.Success .
— , Result.Error .

- , ExceptionHandler .

Result classes , . Result classes, ExceptionHandler try-catch.

3.

, . unit- , , . unit-.

, . , unit-, 2 :

1. Replacing context . , ;
2. Mocking coroutines . .

Replacing context

presenter:

 val login() { launch(UI) { … } } 

, login , UI-. , , . , , unit-.

:

 val login (val coroutineContext = UI) { launch(coroutineContext) { ... } } 

— login coroutineContext. , . Kotlin , UI .
— Coroutine builder Coroutine Contex, .

unit- :

 fun testLogin() { val presenter = LoginPresenter () presenter.login(Unconfined) } 

— LoginPresenter login - , , Unconfined.
— Unconfined , , . .

Mocking coroutines

— . Mockk unit-. unit- Kotlin, . suspend- coEvery -.

login githubUser :

 coEvery { apiClient.login(any()) } returns githubUser 

Mockito-kotlin , — . , , :

 given { runBlocking { apiClient.login(any()) } }.willReturn (githubUser) 

runBlocking . given- , .

Presenter :

 fun testLogin() { val githubUser = GithubUser('login') val presenter = LoginPresenter(mockApi) presenter.login (Unconfined) assertEquals(githubUser, presenter.user()) } 

— -, , GitHubUser .
— LoginPresenter API, . .
— presenter.login Unconfined , Presenter , .

और वह सब है! .

• Rx- . . , RxJava RxJava. - — , .
• . , . Unit- — , , , . — welcome!
• . , , , , . .

उपयोगी लिंक

• , Android GDE Android Coroutine Recipes . , : lifeCircle, coroutineContexts, Coroutine builders .
• GitHub.
• Android Kotlin, , Codelab .
• . Twitter . Medium «» Android, async- .

समाचार

30 Mail.ru . , .

AppsConf , .

, , , .

youtube- AppsConf 2018 — :)