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

कई प्रोग्रामिंग भाषाओं की अपनी प्रतिक्रियाशील लाइब्रेरी है: JVM के लिए RxJava, जावास्क्रिप्ट के लिए RxJS, iOS के लिए RxSwift, Rx.NET आदि।

लेकिन हमारे पास कोटलिन के लिए क्या है? यह मानना तर्कसंगत होगा कि RxKotlin। और, वास्तव में, इस तरह की एक पुस्तकालय मौजूद है, लेकिन यह RxJava2 के लिए विस्तार का एक सेट है, तथाकथित "चीनी"।

और आदर्श रूप से, मैं एक ऐसा उपाय करना चाहूंगा जो निम्नलिखित मानदंडों को पूरा करे:

बहु-मंच - प्रतिक्रियाशील प्रोग्रामिंग का उपयोग करके बहु-मंच पुस्तकालयों को लिखने और कंपनी के भीतर वितरित करने में सक्षम होने के लिए;
अशक्त सुरक्षा - कोटलिन प्रकार की प्रणाली हमें " अरब डॉलर की त्रुटियों " से बचाती है, इसलिए अशक्त मूल्य मान्य होने चाहिए (उदाहरण के लिए, Observable<String?> );
कोवरलीन और कॉन्ट्रैविर्सियस कोटलिन की एक और बहुत ही उपयोगी विशेषता है, जो संभव है, उदाहरण के लिए, Observable<String> से Observable<CharSequence> टाइप टाइप करना।

हमने एट द डिड ने समुद्र के मौसम का इंतजार नहीं करने का फैसला किया और इस तरह की लाइब्रेरी बनाई। जैसा कि आपने अनुमान लगाया होगा, हमने इसे Reaktive कहा और इसे GitHub पर पोस्ट किया।

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

तीन प्राकृतिक रिसाव लाभ

बहु

पहला प्राकृतिक लाभ सबसे महत्वपूर्ण है। हमारे iOS, Android और मोबाइल वेब टीम वर्तमान में अलग-अलग मौजूद हैं। आवश्यकताएं सामान्य हैं, डिजाइन समान है, लेकिन प्रत्येक टीम अपना काम करती है।

कोटलिन आपको मल्टी-प्लेटफ़ॉर्म कोड लिखने की अनुमति देता है, लेकिन आपको प्रतिक्रियाशील प्रोग्रामिंग के बारे में भूलना होगा। और मैं प्रतिक्रियाशील प्रोग्रामिंग का उपयोग करके साझा पुस्तकालयों को लिखने और कंपनी के भीतर वितरित करने या GitHub पर अपलोड करने में सक्षम होना चाहूंगा। संभावित रूप से, यह दृष्टिकोण विकास के समय को काफी कम कर सकता है और कोड की कुल मात्रा को कम कर सकता है।

अशक्त सुरक्षा

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

 public interface UserDataSource {   Single<User> load(); }

क्या परिणाम शून्य हो सकता है? अस्पष्टता से बचने के लिए, RxJava2 में नल की अनुमति नहीं है। और अगर आपको अभी भी ज़रूरत है, तो वह है शायद और वैकल्पिक। लेकिन कोटलिन में ऐसी समस्याएं नहीं हैं। हम कह सकते हैं कि Single<User> और Single<User?> विभिन्न प्रकार हैं, और सभी समस्याएं संकलन चरण में पॉप अप होती हैं।

सहसंयोजक और विरोधाभासी

यह कोटलिन की एक विशिष्ट विशेषता है, कुछ ऐसा जो जावा में बहुत कमी है। आप मैनुअल में इसके बारे में अधिक पढ़ सकते हैं। कोटलिन में RxJava का उपयोग करते समय क्या समस्याएं आती हैं, मैं केवल कुछ दिलचस्प उदाहरण देता हूं।

सहसंयोजक :

 fun bar(source: Observable<CharSequence>) { } fun foo(source: Observable<String>) {   bar(source) //   }

चूंकि Observable एक जावा इंटरफ़ेस है, इसलिए ऐसा कोड संकलित नहीं होता है। ऐसा इसलिए है क्योंकि जावा में सामान्य प्रकार अपरिवर्तनीय हैं। आप निश्चित रूप से उपयोग कर सकते हैं, लेकिन फिर स्कैन जैसे ऑपरेटरों का उपयोग करने से फिर से संकलन त्रुटि हो जाएगी:

 fun bar(source: Observable<out CharSequence>) {   source.scan { a, b -> "$a,$b" } //   } fun foo(source: Observable<String>) {   bar(source) }

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

 interface Observable<out T> {   … }

और यहाँ एक उदाहरण के साथ विरोधाभासी है:

 fun bar(consumer: Consumer<String>) { } fun foo(consumer: Consumer<CharSequence>) {   bar(consumer) //   }

पिछले उदाहरण (जावा में सामान्य प्रकार अपरिवर्तनीय) के समान कारण के लिए, यह उदाहरण संकलित नहीं करता है। जोड़ने से समस्या हल हो जाएगी, लेकिन फिर से एक सौ प्रतिशत नहीं:

 fun bar(consumer: Consumer<in String>) {   if (consumer is Subject) {       val value: String = consumer.value //     } } fun foo(consumer: Consumer<CharSequence>) {   bar(consumer) } interface Subject<T> : Consumer<T> {   val value: T }

खैर, परंपरा से, कोटलिन में इस समस्या को इंटरफ़ेस में उपयोग करके हल किया जाता है:

 interface Consumer<in T> {   fun accept(value: T) }

इस प्रकार, जेनेरिक प्रकारों की परिवर्तनशीलता और विरोधाभासीता, रिकेटिव लाइब्रेरी का तीसरा प्राकृतिक लाभ है।

कोटलिन + प्रतिक्रियाशील = रिसाव

हम मुख्य बात से गुजरते हैं - रेकिटिव लाइब्रेरी का वर्णन।

इसकी कुछ विशेषताएं इस प्रकार हैं:

यह बहु-मंच है, जिसका अर्थ है कि आप अंततः सामान्य कोड लिख सकते हैं। Badoo में, हम इसे सबसे महत्वपूर्ण लाभों में से एक मानते हैं।
यह कोटलिन में लिखा गया है, जो हमें ऊपर वर्णित फायदे देता है: अशक्त, विचरण / विरोधाभास पर कोई प्रतिबंध नहीं है। यह लचीलापन बढ़ाता है और संकलन के दौरान सुरक्षा प्रदान करता है।
RxJava, RxSwift, आदि जैसे अन्य पुस्तकालयों पर कोई निर्भरता नहीं है, जिसका अर्थ है कि पुस्तकालय की कार्यक्षमता को एक सामान्य भाजक तक लाने की कोई आवश्यकता नहीं है।
शुद्ध एपीआई। उदाहरण के लिए, Reaktive में ObservableSource इंटरफ़ेस को बस Observable कहा जाता है, और सभी ऑपरेटर अलग-अलग फ़ाइलों में स्थित विस्तार फ़ंक्शन हैं। 15,000 लाइनों का कोई भगवान वर्ग नहीं हैं। यह मौजूदा इंटरफेस और कक्षाओं में परिवर्तन किए बिना आसानी से कार्यक्षमता बढ़ाना संभव बनाता है।
अनुसूचियों के लिए समर्थन (परिचित subscribeOn और observeOn का उपयोग करके)।
RxJava2 (इंटरऑपरेबिलिटी) के साथ संगत, Reaktive और RxJava2 के बीच स्रोत रूपांतरण और RxJava2 से अनुसूचियों का पुन: उपयोग करने की क्षमता प्रदान करता है।
ReactiveX अनुपालन।

मैं इस तथ्य के बारे में थोड़ा और बात करना चाहूंगा कि हमें इस तथ्य के कारण मिला है कि पुस्तकालय कोटलिन में लिखा गया है।

रिकेटिव में, शून्य मानों की अनुमति है, क्योंकि कोटलिन में यह सुरक्षित है। यहाँ कुछ दिलचस्प उदाहरण हैं:
- observableOf<String>(null) //
- val o1: Observable<String?> = observableOf(null)
  val o2: Observable<String> = o1 // ,
- val o1: Observable<String?> = observableOf(null)
  val o2: Observable<String> = o1.notNull() // , null
- val o1: Observable<String> = observableOf("Hello")
  val o2: Observable<String?> = o1 //
- val o1: Observable<String?> = observableOf(null)
  val o2: Observable<String> = observableOf("Hello")
  val o3: Observable<String?> = merge(o1, o2) //
  val o4: Observable<String> = merge(o1, o2) // ,
भिन्नता भी एक बड़ा लाभ है। उदाहरण के लिए, Observable इंटरफेस में, टाइप टी को out घोषित किया जाता out , जिससे निम्नलिखित की तरह कुछ लिखना संभव हो जाता है:
```
 fun foo() {   val source: Observable<String> = observableOf("Hello")   bar(source) //   } fun bar(source: Observable<CharSequence>) { } 
```

यह पुस्तकालय आज जैसा दिखता है:

लेखन के समय स्थिति: अल्फा (सार्वजनिक एपीआई में कुछ बदलाव संभव हैं);
समर्थित प्लेटफॉर्म: जेवीएम और एंड्रॉइड;
समर्थित स्रोत: Observable , Maybe , Single और Completable ;
काफी बड़ी संख्या में ऑपरेटरों का समर्थन किया जाता है, जिसमें मानचित्र, फ़िल्टर, फ़्लैटमैप, कॉन्कैटपाइप, कम्बाइनटेस्ट, ज़िप, मर्ज और अन्य शामिल हैं (पूरी सूची GitHub पर पाई जा सकती है );
निम्नलिखित अनुसूचियों का समर्थन किया जाता है: संगणना, आईओ, ट्रैम्पोलिन और मुख्य;
विषयों: पब्लिशसबजेक्ट और बिहेवियरसुबजेक्ट;
बैकप्रेशर अभी तक समर्थित नहीं है, लेकिन हम इस सुविधा की आवश्यकता और कार्यान्वयन के बारे में सोच रहे हैं।

निकट भविष्य के लिए हमारी क्या योजनाएं हैं:

हमारे उत्पादों में Reaktive का उपयोग करना शुरू करें (हम वर्तमान में विकल्पों पर विचार कर रहे हैं);
जावास्क्रिप्ट समर्थन (समीक्षा में पहले से ही पुल अनुरोध);
iOS सपोर्ट
JCenter (वर्तमान में JitPack सेवा का उपयोग करके) में कलाकृतियों का प्रकाशन;
प्रलेखन;
समर्थित ऑपरेटरों की संख्या में वृद्धि;
परीक्षण;
अधिक प्लेटफार्मों - पुल अनुरोधों का स्वागत है!

आप लाइब्रेरी को अभी आज़मा सकते हैं, आपको GitHub पर अपनी ज़रूरत की हर चीज़ मिल सकती है । अपना अनुभव साझा करें और सवाल पूछें। हम किसी भी प्रतिक्रिया के लिए आभारी होंगे।

Reaktive - प्रतिक्रियाशील Kotlin के लिए बहु-मंच पुस्तकालय

तीन प्राकृतिक रिसाव लाभ

बहु

अशक्त सुरक्षा

सहसंयोजक और विरोधाभासी

कोटलिन + प्रतिक्रियाशील = रिसाव

More articles: