Le résultat de l'abonnement n'est pas utilisé

Je suis passé à Android Studio 3.1 aujourd'hui, ce qui semble avoir ajouté quelques autres contrôles de peluches. L'un de ces contrôles de charpie concerne les subscribe()appels RxJava2 ponctuels qui ne sont pas stockés dans une variable. Par exemple, obtenir une liste de tous les joueurs à partir de la base de données de ma salle:

Single.just(db)
            .subscribeOn(Schedulers.io())
            .subscribe(db -> db.playerDao().getAll());

Résultats dans un gros bloc jaune et cette info-bulle:

Le résultat de subscriben'est pas utilisé

Quelle est la meilleure pratique pour les appels Rx one-shot comme celui-ci? Dois-je garder la main sur Disposableet dispose()à la fin? Ou devrais-je simplement @SuppressLintpasser à autre chose?

Cela semble n'affecter que RxJava2 ( io.reactivex), RxJava ( rx) n'a pas cette charpie.

L'EDI ne sait pas quels effets potentiels votre abonnement peut avoir lorsqu'il n'est pas supprimé, il le traite donc comme potentiellement dangereux. Par exemple, votre Singlepeut contenir un appel réseau, ce qui pourrait provoquer une fuite de mémoire si votre Activityest abandonné pendant son exécution.

Un moyen pratique de gérer une grande quantité de Disposables consiste à utiliser un CompositeDisposable ; créez simplement une nouvelle CompositeDisposablevariable d'instance dans votre classe englobante, puis ajoutez tous vos objets jetables au CompositeDisposable (avec RxKotlin, vous pouvez simplement ajouter addTo(compositeDisposable)à tous vos objets jetables). Enfin, lorsque vous avez terminé avec votre instance, appelez compositeDisposable.dispose().

Cela éliminera les avertissements de peluche et garantira que vous Disposablesêtes bien géré.

Dans ce cas, le code ressemblerait à:

CompositeDisposable compositeDisposable = new CompositeDisposable();

Disposable disposable = Single.just(db)
        .subscribeOn(Schedulers.io())
        .subscribe(db -> db.get(1)));

compositeDisposable.add(disposable); //IDE is satisfied that the Disposable is being managed. 
disposable.addTo(compositeDisposable); //Alternatively, use this RxKotlin extension function.


compositeDisposable.dispose(); //Placed wherever we'd like to dispose our Disposables (i.e. in onDestroy()).

Au moment où l'activité sera détruite, la liste des produits jetables est effacée et tout va bien.

io.reactivex.disposables.CompositeDisposable mDisposable;

    mDisposable = new CompositeDisposable();

    mDisposable.add(
            Single.just(db)
                    .subscribeOn(Schedulers.io())
                    .subscribe(db -> db.get(1)));

    mDisposable.dispose(); // dispose wherever is required

Vous pouvez vous abonner avec DisposableSingleObserver :

Single.just(db)
    .subscribeOn(Schedulers.io())
    .subscribe(new DisposableSingleObserver<Object>() {
            @Override
            public void onSuccess(Object obj) {
                // work with the resulting todos...
                dispose();
            }

            @Override
            public void onError(Throwable e) {
                // handle the error case...
                dispose();
            }});

Au cas où vous auriez besoin de supprimer directement l' Singleobjet (par exemple avant qu'il ne soit émis), vous pouvez implémenter une méthode onSubscribe(Disposable d)pour obtenir et utiliser la Disposableréférence.

Vous pouvez également réaliser l' SingleObserverinterface par vous-même ou utiliser d'autres classes enfants.

Comme cela a été suggéré, vous pouvez utiliser un global CompositeDisposablepour y ajouter le résultat de l'opération d'abonnement.

La bibliothèque RxJava2Extensions contient des méthodes utiles pour supprimer automatiquement les éléments jetables créés du CompositeDisposable. Voir la section subscribeAutoDispose .

Dans votre cas, cela peut ressembler à ceci

SingleConsumers.subscribeAutoDispose(
    Single.just(db)
            .subscribeOn(Schedulers.io()),
    composite,
    db -> db.playerDao().getAll())

Vous pouvez utiliser Uber AutoDispose et rxjava.as

        Single.just(db)
            .subscribeOn(Schedulers.io())
            .as(AutoDispose.autoDisposable(AndroidLifecycleScopeProvider.from(this)))
            .subscribe(db -> db.playerDao().getAll());

Assurez-vous que vous comprenez quand vous vous désabonnez en fonction du ScopeProvider.

Je reviens encore et encore à la question de savoir comment disposer correctement des abonnements, et à cette publication en particulier. Plusieurs blogs et conférences affirment que le fait de ne pas appeler disposeconduit nécessairement à une fuite de mémoire, ce que je pense être une déclaration trop générale. À mon avis, l'avertissement de non-stockage du résultat subscribeest un non-problème dans certains cas, car:

• Toutes les observables ne s'exécutent pas dans le contexte d'une activité Android
• L'observable peut être synchrone
• Dispose est appelé implicitement, à condition que l'observable se termine

Comme je ne veux pas supprimer les avertissements de charpie, j'ai récemment commencé à utiliser le modèle suivant pour les cas avec une observable synchrone:

var disposable: Disposable? = null

disposable = Observable
   .just(/* Whatever */)
   .anyOperator()
   .anyOtherOperator()
   .subscribe(
      { /* onSuccess */ },
      { /* onError */ },
      {
         // onComplete
         // Make lint happy. It's already disposed because the stream completed.
         disposable?.dispose()
      }
   )

Je serais intéressé par tout commentaire à ce sujet, qu'il s'agisse d'une confirmation de l'exactitude ou de la découverte d'une échappatoire.

Il existe un autre moyen disponible, qui évite d'utiliser les produits jetables manuellement (ajouter et supprimer des abonnements).

Vous pouvez définir un observable et cet observable recevra le contenu d'un SubjectBehaviour (au cas où vous utiliseriez RxJava). Et en passant cet observable à votre LiveData , cela devrait fonctionner. Découvrez l'exemple suivant basé sur la question initiale:

private val playerSubject: Subject<Player> = BehaviorSubject.create()

private fun getPlayer(idPlayer: String) {
        playerSubject.onNext(idPlayer)
}

private val playerSuccessful: Observable<DataResult<Player>> = playerSubject
                        .flatMap { playerId ->
                            playerRepository.getPlayer(playerId).toObservable()
                        }
                        .share()

val playerFound: LiveData<Player>
    get() = playerSuccessful
        .filterAndMapDataSuccess()
        .toLiveData()

val playerNotFound: LiveData<Unit>
    get() = playerSuccessful.filterAndMapDataFailure()
        .map { Unit }
        .toLiveData()

// These are a couple of helpful extensions

fun <T> Observable<DataResult<T>>.filterAndMapDataSuccess(): Observable<T> =
filter { it is DataResult.Success }.map { (it as DataResult.Success).data }

fun <T> Observable<DataResult<T>>.filterAndMapDataFailure(): Observable<DataResult.Failure<T>> =
filter { it is DataResult.Failure }.map { it as DataResult.Failure<T> }

Si vous êtes sûr que le jetable est géré correctement, par exemple en utilisant l'opérateur doOnSubscribe (), vous pouvez ajouter ceci à Gradle:

android {
lintOptions {
     disable 'CheckResult'
}}