يستخدم RxJava في عدد كبير من تطبيقات أندرويد ، ولكن في الوقت نفسه لا يعرف الكثيرون مصادر أخرى للأحداث ، باستثناء الملاحظات التي يمكن ملاحظتها وربما Flowable. إنهم ينسون الفصول المتخصصة الفردية ، ربما ، والقابلة للتنفيذ ، والتي غالباً ما تكون قادرة على إضافة المزيد من الوضوح إلى الكود.
تحت القط سوف تجد ورقة الغش على مصادر الأحداث التي توجد في RxJava.
اكتمال هو في الواقع RX التناظرية من Runnable. إنها عملية يمكن تنفيذها أم لا. إذا رسمنا تشابهاً مع Kotlin ، فهذا
ممتلئ () من عالم Rx. وفقًا لذلك ، للاشتراك فيه ، تحتاج إلى تنفيذ onComplete و onError. لا يمكن إنشاؤه من القيمة (الملاحظة # فقط ، ...) لأنه غير مصمم لهذا الغرض.
مفرد رد الفعل Callable ، لأنه هنا يمكن إرجاع نتيجة العملية. مواصلة المقارنة مع Kotlin ، يمكننا أن نقول أن واحدة هي متعة واحدة (): T {}. وبالتالي ، للاشتراك فيه ، يجب عليك تطبيق onSuccess (T) و onError.
ربما - تقاطع بين مفردة وقابلة للتنفيذ ، لأنه يدعم قيمة واحدة ، بلا قيم وخطأ. من الأصعب رسم موازٍ لا لبس فيه مع الأساليب ، لكنني أعتقد ربما تكون متعة ربما (): T؟ {} ، والتي تُرجع فارغة عند عدم وجود نتيجة. من السهل تخمين أنه بالنسبة للاشتراك ، يلزمك تعريف onSuccess (T) و onComplete و onError.
من المهم ملاحظة أن onSuccess (T) و onComplete يستبعد كل منهما الآخر. أي في حالة الاتصال الأول ، لا يمكنك الانتظار للمرة الثانية.
يمكن ملاحظة المصدر الأكثر شيوعًا بسبب تعدد استخداماته. إنه يعرف كيفية عدم إنتاج الأحداث على الإطلاق ، وإنشاء العديد منها ، بحيث يمكن استخدامه دائمًا عندما تكون الخيارات الأخرى غير مناسبة. على الرغم من ذلك ، فإن Observable له عيب - لا يعرف كيفية التعامل مع الضغط الخلفي. للاشتراك فيه ، ستحتاج إلى onNext (T) و onError و onComplete.
الضغط الخلفي - هو الموقف عندما تصل الأحداث الجديدة بشكل أسرع بكثير من الوقت اللازم للمعالجة ، وتبدأ في التراكم في المخزن المؤقت ، وتفيض عليه. هذا يمكن أن يؤدي إلى مشاكل مثل OutOfMemoryError. مزيد من التفاصيل يمكن العثور عليها هنا .
ConnectableObservable - نسخة ساخنة من ملاحظتها. تبدأ جميع مصادر البيانات في إصدار دفق الأحداث في وقت الاشتراك. لكن ليس هذا الرجل. للقيام بذلك ، ينتظر ConnectableObservable مكالمة للاتصال. يتم ذلك حتى يتمكن العديد من المراقبين من مراجعة دفق واحد من الأحداث دون إعادة تشغيله في كل اشتراك. للتوضيح ، سأعطيك المقتطف التالي:
val observable = Observable.fromCallable { Log.d("RxLogs", "observable fromCallable executed") Thread.sleep(1000) }.subscribeOn(Schedulers.computation()) observable.subscribe() observable.subscribe() observable.subscribe() observable.subscribe()
في وحدة التحكم سيكون:
يمكن ملاحظتها من تنفيذ المنفذ
يمكن ملاحظتها من تنفيذ المنفذ
يمكن ملاحظتها من تنفيذ المنفذ
يمكن ملاحظتها من تنفيذ المنفذ
val connectedObservable = Observable.fromCallable { Log.d("RxLogs", "connectedObservable fromCallable executed") Thread.sleep(1000) }.subscribeOn(Schedulers.computation()) .publish() connectedObservable.subscribe() connectedObservable.subscribe() connectedObservable.subscribe() connectedObservable.subscribe() connectedObservable.connect()
وفي هذه الحالة: يمكن ملاحظتها من تنفيذ المنفذ
Flowable - مصدر يوفر مشغلين إضافيين لمعالجة الضغط الخلفي. عندما تحتاج إلى التعامل مع أكثر من 10000 حدث تحدث بسرعة واحدة تلو الأخرى ، يوصى باستخدامها بدلاً من الملاحظة.
يمكن للأخير إنشاء ConnectableFlowable ، وفتح نفس الاحتمالات مثل ConnectableObservable.
الحديث عن المولدات الحدث ، لا يسع المرء إلا ذكر الموضوع والمعالج.
الموضوع - فئة يمكن أن تكون مصدرًا ومتصفحًا. يسمح لك هذا باستخدامه ، على سبيل المثال ، في أنواع مختلفة من وحدات التحكم ، مما سيعطيه للخارج كمراقب ويمكن إعلامه داخليًا بصفة مراقب. بعد ذلك ، سنذهب من خلال تطبيقات مختلفة لهذه الفئة.
يحتفظ AsyncSubject / AsyncProcessor بالحدث الأخير حتى ينتهي مؤشر الترابط بشكل صحيح ، ثم يرسله إلى المشتركين. في حالة حدوث خطأ ، سيتم إعادة توجيه أي أحداث.
تقوم PublishSubject / PublishProcessor بإعادة توجيه الأحداث القادمة إليها بشكل أكبر حتى تصل إشارة المحطة الطرفية. بعد نهاية الدفق أو الخطأ ، تقوم بإرجاع الأحداث المناسبة.
يعمل
BehaviorSubject / BehaviorProcessor بشكل مشابه لـ PublishSubject / PublishProcessor ، لكن عند الاشتراك ، يُرجع الحدث الأخير ، إن وجد ، وإذا لم يتم نقل الموضوع إلى الحالة النهائية.
ReplaySubject / ReplayProcessor - BehaviourSubject / BehaviorProcessor على المنشطات. إنها لا تُرجع حدثًا واحدًا آخر ، ولكن بقدر ما ترغب الروح. إذا قمت بالاشتراك في ReplaySubject أو ReplayProcessor مكتمل ، فسيتم استلام جميع البيانات المتراكمة.
وبالتالي ، تعمل ReplaySubject.createWithSize (1) و BehaviourSubject.create () بشكل مختلف بعد الانتقال إلى الحالة النهائية. أثناء الاشتراك ، الأول سيعود الحدث الأخير ، والثاني لن. هذا صحيح أيضا بالنسبة ReplayProcessor.
تعمل CompleteableSubject و
MaybeSubject و
SingleSubject على نحو مماثل لـ PublishSubject ، المصممة فقط للاستخدام مع Completeable و ربما و Single ، على التوالي.
UnicastSubject / UnicastProcessor هو في الواقع ReplaySubject يضمن أن لديه مشترك واحد فقط. يلقي IllegalStateException عند محاولة إعادة الاشتراك.
أي المقتطف التالي
val subject = UnicastSubject.create<String>(3) repeat(3) { subject.onNext(it.toString()) } subject.onComplete() subject.subscribe({ Log.d("RxLogs", it) }, { }, { Log.d("RxLogs", "complete") })
سوف الإخراج إلى السجل
0
1
2
كامل
تعمل
MulticastProcessor مشابهة لـ PublishProcessor ، باستثناء ميزة واحدة صغيرة. إنه يعرف كيفية التعامل مع الضغط الخلفي للتيار الوارد. يسمح لك MulticastProcessor بتعيين حجم المخزن المؤقت الذي سيتم عليه الاستعلام المسبق عن العناصر من المشتركين في المستقبل.
في الرسم البياني أدناه ، يتم إنشاء معالج مع تخزين لعنصرين ، والذي يطلبه على الفور من مصدره. لذلك ، عندما يشترك فيه المراقب الأول ، فإنه يصدر فوراً محتويات المخزن المؤقت ، المملوء على الفور بأحداث جديدة. بعد الحدث الطرفي ، تقوم شركة MulticastProcessor بمسح تخزينها ويتلقى المشتركون الجدد فورًا استكمال البث.
