👐🏽 🕺🏼 👨🏻‍🔬 Kotlin के साथ एक प्रतिक्रियाशील घटक प्रणाली का निर्माण ⚡️ 🌳 👩🏾

सभी को नमस्कार! मेरा नाम अनातोली Varivonchik है, मैं Badoo पर एक Android डेवलपर हूं। आज मैं आपके सहकर्मी Zsolt Kocsi द्वारा MVI के कार्यान्वयन पर लेख के दूसरे भाग के अनुवाद को आपके साथ साझा करूंगा, जिसे हम विकास प्रक्रिया में दैनिक उपयोग करते हैं। पहला भाग यहाँ है ।

हम क्या चाहते हैं और हम इसे कैसे करते हैं

लेख के पहले भाग में, हमने विशेषताएँ पेश कीं, जो एमवीआईसी के केंद्रीय तत्व हैं जिनका पुन: उपयोग किया जा सकता है। उनके पास सबसे सरल संरचना हो सकती है और सिर्फ एक Reducer शामिल हो सकता है, या वे अतुल्यकालिक कार्यों, घटनाओं और बहुत कुछ के प्रबंधन के लिए पूरी तरह कार्यात्मक उपकरण बन सकते हैं।

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

यह प्रतिक्रियाशील घटकों की संख्या में वृद्धि के संबंध में है जो कि हमारे पास क्या है और क्या प्रणाली को और भी बेहतर बनाने के लिए संभव है पर प्रतिबिंबित करने का समय आ गया है।

हमें तीन सवालों के जवाब देने हैं:

नए प्रतिक्रियाशील घटकों को जोड़ते समय किन तत्वों का उपयोग किया जाना चाहिए?
अपनी सदस्यता को प्रबंधित करने का सबसे आसान तरीका क्या है?
क्या मेमोरी लीक से बचने के लिए जीवन चक्र प्रबंधन / स्पष्ट सदस्यता की आवश्यकता को अनदेखा करना संभव है? दूसरे शब्दों में, क्या हम सदस्यता प्रबंधन से घटक को अलग कर सकते हैं?

लेख के इस भाग में, हम प्रतिक्रियाशील घटकों का उपयोग करते हुए एक प्रणाली के निर्माण की मूल बातें और लाभों को देखेंगे और देखेंगे कि कोटलिन इसके साथ कैसे मदद करता है।

मुख्य तत्व

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

हमने इस प्रकार बताया:

आइए पहिया को फिर से न करें - आइए देखें कि क्या इंटरफेस पहले से मौजूद हैं।
चूँकि हम पहले से ही RxJava पुस्तकालय का उपयोग कर रहे हैं, यह इसके बुनियादी इंटरफेस को संदर्भित करने के लिए समझ में आता है।
इंटरफेस की संख्या कम से कम होनी चाहिए।

परिणामस्वरूप, हमने आउटपुट के लिए ऑब्जर्वेबल सोर्स <टी> और इनपुट के लिए उपभोक्ता <टी> का उपयोग करने का निर्णय लिया। क्यों नहीं ऑब्जर्वेबल / ऑब्जर्वर , आप पूछते हैं। ऑब्जर्वेबल एक अमूर्त वर्ग है जिसमें से आपको विरासत की आवश्यकता होती है, और ऑब्जर्वेबलस्रोस वह इंटरफ़ेस है जिसे आप लागू करते हैं जो प्रतिक्रियाशील प्रोटोकॉल को लागू करने की आवश्यकता को पूरी तरह से संतुष्ट करता है।

package io.reactivex; import io.reactivex.annotations.*; /** * Represents a basic, non-backpressured {@link Observable} source base interface, * consumable via an {@link Observer}. * * @param <T> the element type * @since 2.0 */ public interface ObservableSource<T> { /** * Subscribes the given Observer to this ObservableSource instance. * @param observer the Observer, not null * @throws NullPointerException if {@code observer} is null */ void subscribe(@NonNull Observer<? super T> observer); }

ऑब्जर्वर , पहला इंटरफ़ेस जो दिमाग में आता है, चार तरीकों को लागू करता है: ऑनस्बस्क्स, onNext, onError और onComplete। जितना संभव हो उतना प्रोटोकॉल को सरल बनाने के प्रयास में, हमने कंज्यूमर <टी> को प्राथमिकता दी, जो एक ही विधि का उपयोग करके नए तत्वों को स्वीकार करता है। यदि हमने ऑब्जर्वर को चुना है, तो शेष विधियां अक्सर निरर्थक होंगी या अलग तरीके से काम करेंगी (उदाहरण के लिए, हम त्रुटियों को राज्य के हिस्से के रूप में प्रस्तुत करना चाहेंगे, न कि अपवादों के रूप में, और निश्चित रूप से धारा को बाधित नहीं करेंगे)।

 /** * A functional interface (callback) that accepts a single value. * @param <T> the value type */ public interface Consumer<T> { /** * Consume the given value. * @param t the value * @throws Exception on error */ void accept(T t) throws Exception; }

तो, हमारे पास दो इंटरफेस हैं, जिनमें से प्रत्येक में एक विधि है। अब हम उन्हें कंज्यूमर <T> के ऑब्जर्वरसे सोर्स <T> पर साइन करके बांध सकते हैं। उत्तरार्द्ध केवल ऑब्जर्वर <T> उदाहरणों को स्वीकार करता है, लेकिन हम इसे एक ऑब्जर्वेबल <T> में लपेट सकते हैं, जिसे उपभोक्ता <T> को सदस्यता दी जाती है:

 val output: ObservableSource<String> = Observable.just("item1", "item2", "item3") val input: Consumer<String> = Consumer { System.out.println(it) } val disposable = Observable.wrap(output).subscribe(input)

(सौभाग्य से, .wrap (आउटपुट) फ़ंक्शन एक नई वस्तु नहीं बनाता है यदि आउटपुट पहले से ही एक अवलोकन योग्य है <T> )।

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

 // Wishes -> Feature val wishes: ObservableSource<Wish> = Observable.just(Wish.SomeWish) val feature: Consumer<Wish> = SomeFeature() val disposable = Observable.wrap(wishes).subscribe(feature) // Feature -> State consumer val feature: ObservableSource<State> = SomeFeature() val logger: Consumer<State> = Consumer { System.out.println(it) } val disposable = Observable.wrap(feature).subscribe(logger)

कंज्यूमर और प्रोड्यूसर का यह लिंकिंग पहले से ही काफी सरल लग रहा है, लेकिन एक और भी आसान तरीका है जिसमें आपको या तो सब्सक्रिप्शन बनाने की जरूरत नहीं है या उन्हें रद्द करना होगा।

पेश है बिंदर ।

स्टेरॉयड बाइंडिंग

MVICore में Binder नामक एक वर्ग होता है जो Rx सब्सक्रिप्शन को प्रबंधित करने के लिए एक सरल एपीआई प्रदान करता है और इसमें कई प्रकार की बेहतरीन सुविधाएँ होती हैं।

इसकी आवश्यकता क्यों है?

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

मैन्युअल हस्ताक्षर करने के बजाय, आप ऊपर दिए गए उदाहरणों को फिर से लिख सकते हैं:

 val binder = Binder() binder.bind(wishes to feature) binder.bind(feature to logger)

कोटलिन के लिए धन्यवाद, सब कुछ बहुत सरल दिखता है।

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

 val output: ObservableSource<A> = TODO() val input: Consumer<B> = TODO() val transformer: (A) -> B = TODO() binder.bind(output to input using transformer)

वाक्यविन्यास पर ध्यान दें: यह लगभग एक सामान्य वाक्य की तरह पढ़ता है (और यह एक अन्य कारण है कि मैं कोटलिन से प्यार करता हूं)। लेकिन बाइंडर का उपयोग केवल वाक्यगत चीनी के रूप में नहीं किया जाता है - यह जीवन चक्र के साथ समस्याओं को हल करने के लिए भी हमारे लिए उपयोगी है।

बाइंडर बनाएँ

एक उदाहरण बनाना कहीं आसान नहीं है:

 val binder = Binder()

लेकिन इस मामले में, आपको मैन्युअल रूप से सदस्यता समाप्त करने की आवश्यकता है, और आपको जब भी आवश्यक हो तो binder.dispose() हटाना होगा। एक और तरीका है: जीवनचक्र उदाहरण को कंस्ट्रक्टर में इंजेक्ट करें। इस तरह:

 val binder = Binder(lifecycle)

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

और जीवन चक्र क्या है?

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

लेकिन यह केवल शुरुआत है, क्योंकि आप किसी भी तरह से Android इंटरफ़ेस LifecycleOwner का उपयोग नहीं करते हैं - बाइंडर का अपना, अधिक सार्वभौमिक है। यह अनिवार्य रूप से एक BEGIN / END सिग्नल स्ट्रीम है:

 interface Lifecycle : ObservableSource<Lifecycle.Event> { enum class Event { BEGIN, END } // Remainder omitted }

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

बाइंडर कैसे काम करता है? BEGIN सिग्नल प्राप्त करना, यह आपके द्वारा पहले से कॉन्फ़िगर किए गए घटकों ( इनपुट / आउटपुट ) के लिए सदस्यता बनाता है, और एक END सिग्नल प्राप्त करके, उन्हें हटा देता है। सबसे दिलचस्प बात यह है कि आप सभी को फिर से शुरू कर सकते हैं:

 val output: PublishSubject<String> = PublishSubject.create() val input: Consumer<String> = Consumer { System.out.println(it) } val lifecycle = ManualLifecycle() val binder = Binder(lifecycle) binder.bind(output to input) output.onNext("1") lifecycle.begin() output.onNext("2") output.onNext("3") lifecycle.end() output.onNext("4") lifecycle.begin() output.onNext("5") output.onNext("6") lifecycle.end() output.onNext("7") // will print: // 2 // 3 // 5 // 6

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

एंड्रॉइड बाइंडर लाइफसाइकल

पुस्तकालय में तीन वर्ग हैं:

CreateDestroyBinderLifecycle ( AndroidLifecycle )
StartStopBinderLifecycle ( AndroidLifecycle )
ResumePauseBinderLifecycl e ( androidLifecycle )

androidLifecycle , getLifecycle() विधि, getLifecycle() , getLifecycle() , आदि द्वारा दिया गया मान है। सब कुछ बहुत सरल है:

 fun createBinderForActivity(activity: AppCompatActivity) = Binder(   CreateDestroyBinderLifecycle(activity.lifecycle) )

व्यक्तिगत जीवन चक्र

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

ऑब्ज़र्वबल आइटम भेजने से पहले सदस्यता बचाना चाहते हैं? इस ऑब्जेक्ट को जीवनचक्र में परिवर्तित करें और इसे बाइंडर में पास करें। एक्सटेंशन फ़ंक्शन में निम्नलिखित कोड को लागू करें और बाद में इसका उपयोग करें:
```
 fun Observable<T>.toBinderLifecycle() = Lifecycle.wrap(this   .first()   .map { END }   .startWith(BEGIN) ) 
```
अपनी बाइंडिंग को तब तक रखना चाहते हैं जब तक कंप्लीटएबल खत्म न हो जाए? कोई समस्या नहीं है - यह पिछले पैराग्राफ के साथ सादृश्य द्वारा किया जाता है:
```
 fun Completable.toBinderLifecycle() = Lifecycle.wrap(   Observable.concat(       Observable.just(BEGIN),       this.andThen(Observable.just(END))   ) ) 
```
सदस्यता को हटाने के लिए कुछ अन्य गैर-आरएक्स कोड तय करना चाहते हैं? जैसा कि ऊपर वर्णित है, मैन्युअललिफ़साइकल का उपयोग करें।

किसी भी स्थिति में, आप या तो Lifecycle के लिए प्रतिक्रियाशील स्ट्रीम रख सकते हैं। तत्व स्ट्रीम, या यदि आप गैर-Rx कोड के साथ काम कर रहे हैं तो ManualLifecycle का उपयोग करें।

सामान्य प्रणाली अवलोकन

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

मान लें कि हमारे पास वर्तमान स्क्रीन के लिए निम्नलिखित प्रतिक्रियाशील घटक हैं:

हम चाहेंगे कि घटक वर्तमान स्क्रीन के भीतर जुड़े हों, और हम जानते हैं कि:

Analytics को सीधे UIEvent खिलाया जा सकता है;
UIEvent को फीचर के लिए विश में तब्दील किया जा सकता है;
राज्य को व्यू के लिए ViewModel में बदला जा सकता है।

यह कुछ लाइनों में व्यक्त किया जा सकता है:

 with(binder) {   bind(feature to view using stateToViewModelTransformer)   bind(view to feature using uiEventToWishTransformer)   bind(view to analyticsTracker) }

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

निष्कर्ष

हमने देखा कि Binder Rx सब्सक्रिप्शन को प्रबंधित करने में कैसे मदद करता है और यह कैसे प्रतिक्रियाशील घटकों से निर्मित सिस्टम का अवलोकन प्राप्त करने में आपकी मदद करता है।

निम्नलिखित लेखों में, हम बताएंगे कि कैसे हम व्यापार तर्क से प्रतिक्रियाशील यूआई घटकों को अलग करते हैं और बिंदर (लॉगिंग और समय यात्रा डिबगिंग के लिए) का उपयोग करके मध्यवर्ती वस्तुओं को कैसे जोड़ते हैं। स्विच मत करो!

इस बीच, GitHub पर लाइब्रेरी देखें।

Kotlin के साथ एक प्रतिक्रियाशील घटक प्रणाली का निर्माण