لاحظ أنه لا توجد تغييرات عامة في الإصدار الجديد ، ولكن ظهر دعم Java 8 ، وأصبحت المكتبة أكثر ملاءمة للاستخدام.
إخلاء المسؤولية: تستند هذه المقالة إلى مراجعة GitHub ، بالإضافة إلى ذلك ، نشارك انطباعات مطوري الجوال لدينا عن RxJava 3 ، لكننا لا ندعي أن تكون دراسة شاملة - لأن الإصدار الجديد تم إصداره مؤخرًا وليس هناك الكثير من الخبرة العملية حتى الآن. إذا كان لديك أي إضافات ، اكتب في التعليقات ، يسعدنا مناقشتها)
التغييرات الرئيسية في RxJava 3
إذن ما نراه في RxJava 3 :
- تم زيادة نسخة جافا الأساسية إلى 8 * ؛
- هناك دعم لميزات اللغة مثل:
- تيارات
- جامعي تيار
- اختياري
- CompletableFeature
* لاستخدام Java8 API ، تحتاج إلى رفع minSDK إلى الإصدار 24.
بدوره ، أزال المطورون دعمًا لميزات مثل:
- java.time.Duration - يولد الكثير من الأحمال الزائدة ، يمكن دائمًا استبداله بوقت + وحدة ؛
- java.util.function - لا يمكن طرح استثناءات ، ويمكن أن تؤدي الأحمال الزائدة إلى "غموض" غير ضروري.
تم تغيير هيكل الحزمة أيضًا:
يمكن تقسيم التغييرات المقدمة إلى مجموعتين:
- التغييرات السلوكية
- تغييرات API
التغييرات السلوكية
- ستتم معالجة جميع الأخطاء
في السابق ، كانت إحدى مشاكل RxJava 2 هي أنه في بعض الحالات ، يمكن أن تضيع الأخطاء ولا يتم التعامل معها. الآن ، في RxJava 3 ، يؤدي إلغاء الاشتراك من مصدر قد يؤدي إلى حدوث خطأ إلى إلقاء هذا الخطأ في معالج الأخطاء العامة عبر RxJavaPlugins.onError ()
- Connectable.reset ()
كانت هناك مشكلة الينابيع الساخنة في RxJava 2: عند تلقي حدث طرفية ConnectableObservable ، تجاهلت الاتصالات الجديدة جميع العناصر واستقبلت حدث الإنهاء فقط.
يقدم RxJava 3 وظيفة لإعادة تعيين حالة ConnectableObservable باستخدام وظيفة reset () للسماح للمشتركين المتصلين حديثًا بمعالجة البيانات.
- القدرة على إيقاف Flowable.publish
في RxJava 3 ، بعد تلقي عدد معين من القيم ، يتم إيقاف Flowable.publish مؤقتًا وتكون العناصر المتبقية متاحة للمشتركين اللاحقين.
- معلمة فارغة Processor.offer ()
إذا حاولت استدعاء PublishProcessor.offer () أو BehaviourProcessor.offer () أو MulticastProcessor.offer () وتمرير فارغة ، يتم طرح NullPointerException بدلاً من تمرير خطأ إلى معالج onError ، ويتم تشغيل حالة طرفية.
- CompositeException.getCause ()
في وقت سابق في RxJava 2 ، كانت طريقة getCause () في بعض الأحيان عبارة عن حمل كبير للذاكرة ، حيث كانت استدعاء طريقة initCause في كل استثناء ، غير مستقرة ، ولم تكن دائمًا ترمي سلسلة استثناء.
في الإصدار الجديد ، تم تغيير هذه الطريقة داخليًا وتولد الآن سلسلة من الأخطاء في شكل تتبع مكدس - عن طريق التنسيق البسيط للسلاسل.
- تم تغيير استثناءات التحقق من صحة المعلمة
إذا كانت المعلمة غير صالحة ، فإن بعض عوامل التشغيل ستقوم الآن برمي IllegalArgumentException بدلاً من IndexOutOfBoundsException:
- skip
- skipLast
- takeLast
- takeLastTimed
- مصادر ما قبل الإغلاق لـ fromX ()
أصبحت المكتبات fromAction () و fromRunnable () متناسقة مع باقي مكالمات fromX (). سيتم الآن إغلاق مكالمات fromRunnable () و fromAction () فورًا عند استدعاؤها وفقًا لذلك. في RxJava 2 ، تم إغلاق هؤلاء المشغلين بعد مرور نهاية تنفيذ جسم لامدا إلى المعلمات.
- ترتيب تنظيف المورد عند استخدام ()
تحتوي العبارة using () على معلمة مسؤولة عن وقت تنظيف المورد المستخدم (صحيح - قبل الانتهاء ، خطأ - بعد). في الإصدار المبكر من المكتبة ، تم تجاهل هذه المعلمة ، وتم تنظيف المورد دائمًا قبل الحصول على حالة المحطة الطرفية ، ولكن في RxJava 3 يعمل كل شيء بشكل صحيح.
تغييرات API
- تم توسيع معالجة الاستثناءات للواجهات الوظيفية للإصدار الجديد من المكتبة من Exception إلى Throwable
- أنواع جديدة: مورد
في RxJava 3 ، بسبب تمديد استثناءات الواجهة الوظيفية من الاستثناء إلى الرمي ، تم إدخال نوع جديد للمورد - نظير قابل للاستدعاء ، ولكن مع رمي قابل للرمي
- في RxJava 3 ، تم تغيير عوامل تحويل مصدر بيانات إلى آخر إلى محولات معينة
- المكونات المنقولة
نظرًا لحقيقة أن RxJava3 ستدعم واجهة برمجة تطبيقات Java8 ، فقد حان حل جديد ليحل محل فئات المصانع الفردية: أصبحت طرق هذه المصانع طرقًا ثابتة للواجهة القابلة للتصرف نفسها.
كما كان من قبل:
الآن:
- لتقليل التحذيرات ، أصبحت فئة DisposableContainer التي تم استخدامها داخل CompositeDisposable جزءًا من واجهة برمجة التطبيقات العامة
- كان بعض العوامل في RxJava 2 في المرحلة التجريبية ، وفي الإصدار الثالث أصبحوا عوامل تشغيل قياسية:
Flowable promotions
dematerialize(Function)
Observable promotions
dematerialize(Function)
Maybe promotions
doOnTerminate(Action)
materialize()
Single promotions
dematerialize(Function)
materialize()
Complectable promotions
delaySubscription(long, TimeUnit)
delaySubscription(long, TimeUnit, Scheduler)
materialize()
- concatMap() Scheduler’
- blockingSubscribe() Maybe, Single Completable
- onErrorComplete()
- onErrorResumeWith() Completable
- retryUntil() Single Completable
- switchOnNext() switchOnNextDelayError() Maybe, Single Completable
- dematerialize() Maybe
- fromX()-
- timeInterval() Maybe Single
- toFuture() Maybe Completable
- ofType() Maybe Single
- doOnLifecycle() Maybe, Single Completable
- concatMapX() (X – ) Maybe Single
- concatDelayError() Maybe, Single Completable
- mergeArray() Single
Flowable
startWith(MaybeSource)
startWith(SingleSource)
startWith(ComplectableSource)
Observable
startWith(MaybeSource)
startWith(SingleSource)
startWith(ComplectableSource)
Maybe
startWith(Publisher)
startWith(ObservableSource)
startWith(MaybeSource)
startWith(SingleSource)
startWith(ComplectableSource)
Single
startWith(Publisher)
startWith(ObservableSource)
startWith(MaybeSource)
startWith(SingleSource)
startWith(ComplectableSource)
Complectable
startWith(MaybeSource)
startWith(SingleSource)
- onErrorReturn() Completable
- safeSubscribe() Maybe, Single Completable
- flatMap() Single
- concatEager() concatEagerDelayError() Flowable, Observable, Maybe Single
- fromSupplier()
Java8
وأضاف جديد مشغل fromOptional () لالسيال، يمكن ملاحظتها وربما
أضاف جديدة المشغل fromStream () لالسيال وملاحظتها
وأضاف عامل جديد fromCompletionStage () لجميع أنواع خمسة مصدر البيانات
الاضافة الجديدة المشغل mapOptional () لالسيال، يمكن ملاحظتها، ربما واحدة. يسمح فقط بتمرير القيم غير الفارغة .
تمت إضافة عامل blockingStream () جديد قابل للانسياب والملاحظة. عامل التشغيل يمثل دفق البيانات كتدفق ، في حين يوصى بإغلاق الدفق عند الانتهاء من العمل معه من أجل منع جميع أنواع التسريبات
تمت إضافة عوامل تشغيل جديدة flatMapStream () وconcatMapStream () للانسياب والملاحظة - السماح بتحويل كل عنصر إلى دفق منفصل
تمت إضافة عوامل تشغيل جديدة flattenStreamAsFlowable () و flattenStreamAsObservable () لمشغلات FlatMapStream () ربما والمكافئة () للمشاهدة والقابلة للتدفق
ما أعيدت تسميته
- بدلاً من startWith () - startWithArray () ، startWithIterable () ، startWithItem ()
- بدلاً من onErrorResumeNext () - onErrorResumeWith ()
- بدلاً من zipIterable () - zip ()
- بدلاً من combineLatest () (مع وسيطة صفيف) - combineLatestArray () ، combineLatestArrayDelayError ()
- بدلاً من Single.equals () - sequenceEqual (SingleSource ، SingleSource)
- Maybe.flatMapSingleElement() – Maybe.flatMapSingle()
- Callable – Supplier ( )
API
Maybe.toSingle ()، واستبدال - Maybe.defaultIfEmpty ()
الاشتراك (...، ...، ...،)، واستبدال - doOnSubscribe ()
Single.toCompletable ()، واستبدال - Single.ignoreElement ()
Completable.blockingGet ()، واستبدال - Completable .blockingAwait ()
replay (Scheduler) ، استبدل - observeOn (Scheduler)
dematerialize () ، استبدل - deserialize (Function)
onExceptionResumeNext () ، استبدل - onErrorResumeNext (Function)
combineLatest () (مع معلمة vararg) ، استبدل - combineLatestArray ()
fromFuture () (مع معلمة الجدولة) ، الاستبدال - subscribeOn ()
concatMapIterable () (مع معلمة المخزن المؤقت) ، الاستبدال - concatMapIterable (الوظيفة)
تمت أيضًا إزالة الطرق التالية من TestSubscriber و TestObserver:
كيف تهاجر
يلاحظ العديد من المطورين أن الهجرة من RxJava 2 إلى RxJava 3 هي عملية شاقة إلى حد ما. هناك خياران لإجراء الانتقال:
- لديك كلا الإصدارين من المكتبة في مشروعك ؛
- إجراء ترحيل كامل إلى RxJava 3 ، بينما يمكنك استخدام مكتبة خاصة .
فكيف الهجرة:
- لتحديث العمل باستخدام API - استخدم النظير لطرق RxJava 2 التي خضعت للتغيير.
- من المهم أن تأخذ في الاعتبار أن بعض مكتبات الجهات الخارجية لا تزال "جالسة" على RxJava 2. لتبسيط عملية الانتقال ، يمكنك أن تأخذ RxJavaBridge ، الذي يخفي معظم الترحيل تحت غطاء محرك السيارة.
- Retrofit RxJava3CallAdapterFactory .
لقد راجعنا ما الجديد في RxJava 3. والآن دعنا نحاول الإجابة على السؤال الرئيسي - هل يستحق الترحيل على الإطلاق؟
RxJava 3 هو عمليا تحسين API. نظرًا لعدم وجود تغييرات أساسية ، بشكل عام ، ليست هناك حاجة للانتقال إلى أحدث إصدار الآن. يتطلب النقل نفسه جهدًا ، بينما لا تزال العديد من مكتبات الجهات الخارجية مرتبطة بـ RxJava 2 ، للعمل مع Java8 ، ستحتاج أيضًا إلى رفع minSDK إلى الإصدار 24. تقدم بعض الفرق أيضًا حلولًا بديلة ، مثل استخدام Kotlin Coroutines.
ومع ذلك ، تجدر الإشارة إلى أن RxJava 2 يدخل الآن في وضع "الصيانة" ، مما يعني أنه لن يكون هناك سوى إصلاحات للأخطاء من التحديثات. من المتوقع أن ينتهي دعم الإصدار الثاني في 28 فبراير 2021.
! , .