web-dev-qa-db-fra.com

Quand utiliser RxJava dans Android et quand utiliser LiveData à partir de composants architecturaux Android?

Je ne comprends pas pourquoi utiliser RxJava dans Android et LiveData à partir de composants architecturaux Android. Il serait vraiment utile que les cas d'utilisation et les différences entre les deux soient expliqués avec un exemple d'exemple sous la forme d'un code expliquant les différences entre les deux.

98
rahul66

Android LiveData est une variante du modèle d'observateur d'origine, avec l'ajout de transitions actives/inactives. En tant que tel, sa portée est très restrictive.

À l'aide de l'exemple décrit dans Android LiveData , une classe est créée pour surveiller les données d'emplacement, puis pour enregistrer et annuler l'enregistrement en fonction de l'état de l'application.

RxJava fournit des opérateurs beaucoup plus généralisés. Supposons que cet observable fournira des données de localisation:

Observable<LocationData> locationObservable;

La mise en œuvre de l'observable peut être construite en utilisant Observable.create() pour mapper les opérations de rappel. Lorsque l'observable est souscrit, le rappel est enregistré et lorsqu'il n'est pas souscrit, le rappel n'est pas enregistré. L'implémentation ressemble beaucoup au code fourni dans l'exemple.

Supposons également que vous ayez une observable qui émet true lorsque l'application est active:

Observable<Boolean> isActive;

Ensuite, vous pouvez fournir toutes les fonctionnalités de LiveData en procédant comme suit:

Observable<LocationData> liveLocation =
  isActive
    .switchMap( active -> active ? locationObservable : Observable.never() );

L'opérateur switchMap() fournira l'emplacement actuel sous forme de flux ou rien si l'application n'est pas active. Une fois que vous avez la variable liveLocation, vous pouvez faire beaucoup de choses avec les opérateurs RxJava. Mon exemple préféré est:

liveLocation.distinctUntilChanged()
  .filter( location -> isLocationInAreaOfInterest( location ) )
  .subscribe( location -> doSomethingWithNewLocation( location ) );

Cela n'exécutera l'action que lorsque l'emplacement a changé et que l'emplacement est intéressant. Vous pouvez créer des opérations similaires associant les opérateurs de temps pour déterminer la vitesse. Plus important encore, vous pouvez contrôler de manière détaillée si des opérations ont lieu dans le thread principal, dans un thread en arrière-plan ou dans plusieurs threads, à l'aide des opérateurs RxJava.

L'intérêt de RxJava est de combiner le contrôle et la synchronisation dans un seul univers, en utilisant les opérations fournies par la bibliothèque, voire les opérations personnalisées que vous fournissez.

LiveData n'aborde qu'une petite partie de cet univers, l'équivalent de la construction de liveLocation.

79
Bob Dalgleish

En ce qui concerne la question initiale, RxJava et LiveData se complètent parfaitement.

LiveData brille sur la couche ViewModel, avec son intégration étroite aux cycles de vie Android et ViewModel. RxJava offre davantage de possibilités de transformation (comme mentionné par @Bob Dalgleish). 

Actuellement, nous utilisons RxJava dans les couches de source de données et de référentiel, et il est transformé en LiveData (à l'aide de LiveDataReactiveStreams) dans ViewModels (avant d'exposer les données à des activités/fragments) - plutôt satisfait de cette approche.

66
kzotin

En fait, LiveData n’est pas un outil essentiellement différent de RxJava, pourquoi a-t-il été introduit en tant que composant d’architecture alors que RxJava aurait pu facilement gérer le cycle de vie en stockant tous les abonnements aux observables dans un objet CompositeDispoable et ensuite les disposer dans onDestroy() de la Activity ou onDestroyView() de la Fragment en n'utilisant qu'une seule ligne de code?

J'ai complètement répondu à cette question en construisant une application de recherche de film une fois avec RxJava puis avec LiveData ici .

En bref, oui, cela serait possible, mais cela nécessiterait d’abord de remplacer les méthodes de cycle de vie pertinentes en plus de disposer des connaissances de base du cycle de vie. Cela n’a peut-être encore aucun sens pour certains, mais le fait est que, selon l’une des sessions Jetpack de Google I/O 2018 , de nombreux développeurs trouvent que la gestion du cycle de vie est complexe. Les erreurs de plantage résultant de la non gestion de la dépendance au cycle de vie peuvent être un autre signe que certains développeurs, même bien informés du cycle de vie, oublient de prendre soin de cela dans chaque activité/fragment utilisé dans leur application. Dans les applications volumineuses, cela pourrait devenir un problème, malgré les effets négatifs que cela pourrait avoir sur la productivité.

En résumé, en introduisant LiveData, un plus grand nombre de développeurs sont invités à adopter MVVM sans même avoir à comprendre la gestion du cycle de vie, les fuites de mémoire et les pannes. Même si je n'ai aucun doute sur le fait que LiveData n'est pas comparable à RxJava en termes de capacités et de puissance qu'il confère aux développeurs, la programmation réactive et RxJava est un concept difficile à comprendre et outil pour beaucoup. D'un autre côté, je ne pense pas que LiveData se substitue à RxJava - ce n'est tout simplement pas le cas - mais un outil très simple pour gérer un problème controversé et répandu rencontré par de nombreux développeurs.

** UPDATE ** J'ai ajouté un nouvel article ici où j'ai expliqué comment une utilisation abusive de LiveData pouvait entraîner des résultats inattendus. RxJava peut venir au secours dans ces situations


21
Ali Nem

Comme vous le savez peut-être dans l'écosystème réactif, nous avons un Observable qui émet des données et un Observer qui s'abonne (se fait notifier) ​​de cette émission Observable. Rien d'étrange n'est alors comment fonctionne ce qu'on appelle le modèle d'observateur. Un observable "crie" quelque chose, l'observateur est averti que l'observable crie quelque chose à un moment donné.

Pensez à LiveData comme observable, ce qui vous permet de gérer les observateurs qui sont dans un état active. En d'autres termes, LiveData est un simple Observable mais prend également en charge le cycle de vie. 

Mais voyons les deux cas de code que vous demandez:

A) Données en direct

B) RXJava

A) Ceci est une implémentation de base de LiveData

1) vous instanciez généralement LiveData dans ViewModel pour conserver le changement d’orientation (vous pouvez avoir LiveData en lecture seule ou MutableLiveData en écriture, de sorte que vous exposez habituellement en dehors de la classe LiveData)

2) dans la méthode OnCreate de l'activité Main (pas ViewModel) Vous "souscrivez" un objet Observer (généralement une méthode onChanged)

3) vous lancez la méthode observe pour établir le lien

Tout d'abord le ViewModel (possède la logique métier)

class ViewModel : ViewModel() { //Point 1

    var liveData: MutableLiveData<Int> = MutableLiveData()

}

Et voici le MainActivity (aussi bête que possible)

class MainActivity : AppCompatActivity() {

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)

        val ViewModelProvider= ViewModelProviders.of(this).get(ViewModel::class.Java)

        ViewModelProvider.observe(this, Observer {//Points 2 and 3
            //what you want to observe
        })


        }
    }
}

B) Ceci est l'implémentation de base de RXJava

1) vous déclarez un observable

2) vous déclarez un observateur

3) vous abonnez l'observable à l'observateur

Observable.just(1, 2, 3, 4, 5, 6) // Point 1

   .subscribe(new Subscriber() {    //Points 2 & 3
       @Override
       public void onCompleted() {
           System.out.println("Complete!");
       }

       @Override
       public void onError(Throwable e) {
       }

       @Override
       public void onNext(Double value) {
           System.out.println("onNext: " + value);
       }
    });

En particulier, LiveData est utilisé avec Lifecycle et souvent avec les composants de l'architecture ViewModel (comme nous l'avons vu). En fait, lorsque LiveData est associé à un ViewModel, vous pouvez vous tenir au courant en temps réel de toutes les modifications apportées à Observer, afin que les événements soient gérés en temps réel, le cas échéant. Il est fortement recommandé d'utiliser LiveData pour connaître le concept de cycle de vie et les objets relatifs LifeCycleOwner/LifeCycle , je vous suggère également de consulter Transformations , si vous souhaitez implémenter LiveData dans des scénarios réels. Vous trouverez ici quelques cas d’utilisation tirés du grand commonswear .

Pour terminerLiveData est un RXJava simplifié, un moyen élégant d'observer les modifications apportées à plusieurs composants sans créer de règles explicites de dépendance entre les composants, de manière à faciliter le test du code et le rendre beaucoup plus lisible . RXJava, vous permet de faire les choses de LiveData et bien plus encore. En raison des fonctionnalités étendues de RXJava, vous pouvez utiliser LiveData pour des cas simples ou exploiter toute la puissance de RXJava en utilisant des composants d'architecture Android tels que ViewModel , bien sûr, cela signifie que RXJava peut être beaucoup plus complexe. a des centaines d'opérateurs au lieu de SwitchMap et Map of LiveData (pour le moment). 

RXJava version 2 est une bibliothèque qui a révolutionné le paradigme orienté objet en ajoutant une méthode dite fonctionnelle pour gérer le flux du programme.

19
trocchietto

Il existe de nombreuses différences entre LiveData et RxJava.

  1. LiveData n'est pas un flux alors que dans Rxjava, tout (littéralement tout) est un flux
  2. LiveData est synchrone. Par conséquent, vous ne pouvez pas exécuter de manière asynchrone un bloc de code (appel nework, manipulation de base de données) en utilisant uniquement LiveData, comme vous le faites avec Rxjava.
  3. Pour exploiter au mieux ce duo, vous pouvez au mieux utiliser Rxjava pour votre logique métier (appel réseau, manipulation de données, etc., tout ce qui se passe dans et au-delà de Repository) et utiliser LiveData pour votre couche de présentation. Vous obtenez ainsi des fonctionnalités de transformation et de flux pour votre logique métier et une opération sensible au cycle de vie de votre interface utilisateur.
  4. LiveData et Rxjava se complètent mutuellement s'ils sont utilisés ensemble. Ce que je veux dire, c’est tout faire avec RxJava et à la fin, lorsque vous voulez mettre à jour l’UI, faites quelque chose comme le code donné ci-dessous pour changer votre Observable en Livedata. Ainsi, votre vue (UI) observe les Livedata dans ViewModel où votre LiveData n’est rien mais MutableLiveData non-mutable (ou MutableLiveData est LiveData).
  5. La question est donc: pourquoi devriez-vous même utiliser LiveData en premier lieu? Comme vous pouvez le voir ci-dessous dans le code, vous stockez votre réponse de Rxjava à MutableLiveData (ou LiveData) et votre LiveData prend en compte le cycle de vie, de sorte que vos données tiennent compte du cycle de vie. Maintenant, imaginez la possibilité lorsque vos données elles-mêmes savent quand et quand ne pas mettre à jour l'interface utilisateur.

  6. LiveData n'a pas d'historique (seulement l'état actuel). Par conséquent, vous ne devriez pas utiliser LiveData pour une application de discussion.

  7. Lorsque vous utilisez LiveData avec RxJava, vous n'avez pas besoin d'éléments tels que MediatorLiveData, SwitchMap, etc. Ce sont des outils de contrôle de flux et RxJava est meilleur que plusieurs fois.
  8. Voir LiveData comme un détenteur de données et rien d’autre. Nous pouvons également dire que LiveData est un consommateur conscient de Lifecycle.

     public class RegistrationViewModel extends ViewModel {
    
        private RegistrationRepo registrationRepo;
        private MutableLiveData<RegistrationResponse> modelMutableLiveData = 
                                                  new MutableLiveData<>();
    
        public RegistrationViewModel() {
                              }
    
        public RegistrationViewModel(RegistrationRepo registrationRepo) {
                this.registrationRepo = registrationRepo;
          }
    
        public void init(RegistrationModel registrationModel) {
              disposable = registrationRepo.loginForUser(registrationModel)
               .subscribeOn(Schedulers.io())
               .observeOn(AndroidSchedulers.mainThread())
               .subscribe(new Consumer<Response<RegistrationResponse>>() {
                   @Override
                   public void accept(Response<RegistrationResponse> 
                 registrationModelResponse) throws Exception {
    
            modelMutableLiveData.setValue(registrationModelResponse.body());
                }
            });
       }
    
          public LiveData<RegistrationResponse> getModelLiveData() {
                   return modelMutableLiveData;
             }
    }
    
5
Abhishek Kumar

LiveData est un sous-ensemble des composants de l’architecture Android qui a été développé par l’équipe Android.Avec les données en direct et d’autres composants de l’architecture (il convient au mieux à Android. Les fuites de mémoire, etc. sont gérées par des composants d’architecture. Donc, il convient au mieux à Android, Ils fournissent des mises à jour en ce qui concerne les nouvelles versions d'Android, etc.), nous pouvons faire ce que nous pouvons réaliser dans RxJava.
Si vous souhaitez utiliser Android, cela signifie uniquement accéder aux composants d'architecture Android et si vous souhaitez utiliser votre module sous Android et d'autres moyens (application Java, etc.), accédez à RxJava (réactif natif).

3
SIVAKUMAR.J

LiveData en tant que détenteur de données et rien d’autre. Nous pouvons également dire que LiveData est un consommateur conscient de Lifecycle. LiveData est fortement recommandé de connaître le concept de cycle de vie et les objets relatifs LifeCycleOwner/LifeCycle, vous obtenez des fonctionnalités de transformation et de flux pour votre logique métier et une opération sensible au cycle de vie pour votre interface utilisateur.

Rx est un outil puissant qui permet de résoudre des problèmes dans un style déclaratif élégant. Il gère les options côté métier ou les opérations Service Api

0
Attif