Notez qu'il n'y a pas de changements globaux dans la nouvelle version, mais le support de Java 8 est apparu, et la bibliothèque est devenue plus pratique à utiliser.
Avertissement: Cet article est basé sur une revue de GitHub.En outre, nous partageons les impressions de nos développeurs mobiles sur RxJava 3, mais nous ne prétendons pas être une étude exhaustive - car la nouvelle version a été publiée récemment et il n'y a pas encore beaucoup d'expérience pratique. Si vous avez des ajouts, écrivez dans les commentaires, nous serons heureux de discuter)
Principaux changements dans RxJava 3
Donc ce que nous voyons dans RxJava 3 :
- La version de base de Java est maintenant augmentée à 8 *;
- Des fonctionnalités linguistiques telles que:
- Streams
- Stream Collectors
- Facultatif
- CompletableFeature
* Pour utiliser l' API Java8, vous devez élever minSDK à la version 24.
À leur tour, les développeurs ont supprimé la prise en charge de fonctionnalités telles que:
- java.time.Duration - génère beaucoup de surcharges, peut toujours être remplacé par time + unit;
- java.util.function - Impossible de lever des exceptions et les surcharges peuvent créer une "ambiguïté" inutile.
La structure du package a également changé:
les changements présentés peuvent être divisés en 2 groupes:
- Changements de comportement
- Modifications de l'API
Changements de comportement
- Toutes les erreurs seront traitées
Auparavant, l'un des problèmes avec RxJava 2 était que dans certains cas, les erreurs pouvaient être perdues et ne pas être gérées. Désormais, dans RxJava 3, la désinscription d'une source susceptible de générer une erreur déclenche le rejet de cette erreur dans le gestionnaire d'erreurs général via RxJavaPlugins.onError ()
- Connectable.reset ()
Il y avait un problème de sources chaudes dans RxJava 2: lors de la réception d'un événement de terminal ConnectableObservable, les nouvelles connexions ignoraient tous les éléments et ne recevaient que l'événement de terminaison.
RxJava 3 introduit une fonction pour réinitialiser l'état ConnectableObservable en utilisant la fonction reset () pour permettre aux nouveaux abonnés connectés de traiter les données.
- Possibilité de mettre en pause Flowable.publish
Dans RxJava 3, après la réception d'un certain nombre de valeurs, Flowable.publish est mis en pause et les éléments restants sont disponibles pour les abonnés suivants.
- Paramètre Null Processor.offer ()
Si vous essayez d'appeler PublishProcessor.offer (), BehaviourProcessor.offer () ou MulticastProcessor.offer () et passez null, une NullPointerException est levée au lieu de transmettre une erreur au gestionnaire onError et un état terminal est déclenché.
- CompositeException.getCause ()
Auparavant dans RxJava 2, la méthode getCause () représentait parfois une charge mémoire importante, appelant la méthode initCause à chaque exception, était instable et ne lançait pas toujours une chaîne d'exceptions.
Dans la nouvelle version, cette méthode a été modifiée de l'intérieur et génère désormais une chaîne d'erreurs sous la forme d'une trace de pile - par simple mise en forme des chaînes.
- Exceptions de validation de paramètre modifiées
Si le paramètre n'est pas valide, certains opérateurs lèveront désormais IllegalArgumentException au lieu de IndexOutOfBoundsException:
- skip
- skipLast
- takeLast
- takeLastTimed
- Sources de pré-fermeture pour fromX ()
Les bibliothèques fromAction () et fromRunnable () sont devenues cohérentes avec le reste des appels fromX (). Les rappels fromRunnable () et fromAction () seront désormais fermés instantanément lorsqu'ils sont appelés en conséquence. Dans RxJava 2, ces opérateurs étaient fermés après la fin de l'exécution du corps du lambda passé aux paramètres.
- Ordre de nettoyage des ressources lors de l'utilisation de ()
L'instruction using () a un paramètre qui est responsable du moment où la ressource utilisée sera nettoyée (vrai - avant la fin, faux - après). Dans la première version de la bibliothèque, ce paramètre était ignoré et la ressource était toujours nettoyée avant d'obtenir l'état du terminal, mais dans RxJava 3, tout fonctionne correctement.
Modifications de l'API
- La gestion des exceptions des interfaces fonctionnelles de la nouvelle version de la bibliothèque a été étendue de Exception à Throwable
- Nouveaux types: Fournisseur
Dans RxJava 3, en raison de l'extension des exceptions d'interface fonctionnelle d'Exception à Throwable, un nouveau type de fournisseur a été introduit - un analogue de Callable, mais avec des lancers Throwable
- Dans RxJava 3, les opérateurs de conversion d'une source de données en une autre ont été modifiés en convertisseurs spécifiques
- Composants déplacés
Du fait que RxJava3 supportera l'API Java8, une nouvelle solution est venue remplacer les classes d'usine individuelles: les méthodes de ces usines sont devenues des méthodes statiques de l'interface Disposable elle-même.
Comme avant:
Maintenant:
- Afin de réduire les avertissements, la classe DisposableContainer qui a été utilisée à l'intérieur de CompositeDisposable fait partie de l'API publique
- Certains des opérateurs de RxJava 2 étaient au stade expérimental et dans la troisième version ils sont devenus des opérateurs standard:
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
Ajout d'un nouvel opérateur fromOptional () pour Flowable, Observable et Maybe
Ajout d'un nouvel opérateur fromStream () pour Flowable et Observable
Ajout d'un nouvel opérateur fromCompletionStage () pour les cinq types de sources de données
Ajout d'un nouvel opérateur mapOptional () pour Flowable, Observable, Maybe et Single. Il n'autorise que le passage des valeurs non vides .
Ajout d'un nouvel opérateur blockingStream () pour Flowable et Observable. L'opérateur représente le flux de données sous forme de flux, alors qu'il est recommandé de fermer le flux une fois le travail terminé afin d'éviter toutes sortes de fuites
Ajout de nouveaux opérateurs flatMapStream () etconcatMapStream () pour Flowable et Observable - permet à chaque élément d'être converti en un flux séparé
Ajout de nouveaux opérateurs flattenStreamAsFlowable () et flattenStreamAsObservable () pour Maybe et Single - opérateurs flatMapStream () équivalents pour Observable et Flowable
Ce qui a été renommé
- Au lieu de startWith () - startWithArray () , startWithIterable () , startWithItem ()
- Au lieu de onErrorResumeNext () - onErrorResumeWith ()
- Au lieu de zipIterable () - zip ()
- Au lieu de combineLatest () (avec un argument de tableau) - combineLatestArray () , combineLatestArrayDelayError ()
- Au lieu de Single.equals () - sequenceEqual (SingleSource, SingleSource)
- Maybe.flatMapSingleElement() – Maybe.flatMapSingle()
- Callable – Supplier ( )
API
Maybe.toSingle (), replacement - Maybe.defaultIfEmpty ()
subscribe (..., ..., ...,), replacement - doOnSubscribe ()
Single.toCompletable (), replacement - Single.ignoreElement ()
Completable.blockingGet (), replacement - Completable .blockingAwait ()
replay (Scheduler), remplacer - observeOn (Scheduler)
dematerialize (), remplacer - désérialiser (Fonction)
onExceptionResumeNext (), remplacer - onErrorResumeNext (Fonction)
combineLatest () (avec le paramètre vararg), remplacer - combineLatestArray ()
fromFuture () (avec le paramètre Scheduler), remplacement - subscribeOn ()
concatMapIterable () (avec paramètre de tampon), remplacement - concatMapIterable (Fonction)
Également supprimé les méthodes suivantes de TestSubscriber et TestObserver:
Comment migrer
De nombreux développeurs notent que la migration de RxJava 2 vers RxJava 3 est un processus assez laborieux. Il existe deux options pour effectuer la transition:
- avoir les deux versions de la bibliothèque sur votre projet;
- effectuez une migration complète vers RxJava 3, tandis que vous pouvez utiliser une bibliothèque spéciale .
Alors, comment migrer:
- Pour mettre à jour le travail avec l'API - utilisez des analogues de ces méthodes RxJava 2 qui ont été sujettes à changement.
- Il est important de prendre en compte le fait que certaines bibliothèques tierces sont toujours "assises" sur RxJava 2. Pour simplifier la transition, vous pouvez prendre RxJavaBridge , qui cache l'essentiel de la migration sous le capot.
- Retrofit RxJava3CallAdapterFactory .
Nous avons passé en revue les nouveautés de RxJava 3. Et maintenant, essayons de répondre à la question principale: vaut-il vraiment la peine de migrer?
RxJava 3 est pratiquement une amélioration de l'API. En raison du fait qu'il n'y a pas eu de changements fondamentaux, il n'est généralement pas nécessaire de migrer vers la dernière version pour le moment. La transition elle-même nécessite des efforts, alors que de nombreuses bibliothèques tierces sont toujours associées à RxJava 2, pour fonctionner avec Java8, vous devrez également élever minSDK à la version 24. Certaines équipes proposent également des solutions alternatives, comme l'utilisation de Kotlin Coroutines.
Cependant, il convient de noter que RxJava 2 passe maintenant en mode "maintenance", ce qui signifie qu'il n'y aura que des corrections de bogues à partir des mises à jour. Le support pour la deuxième version devrait se terminer le 28 février 2021.
! , .