2

This question is related to Android and life-cycles. Previously, I would have a series of subjects and subscribe to them on creation.

Upon destruction, I would mark all the subjects as complete, assuming that it disposes all subscribers.

With Android Studio 3.1, I get warnings for any subscriber that "isn't used". The solution is to add them to a "completable disposable" that I then dispose upon destruction.

Is "composite disposable" all I need to properly cancel requests upon destruction? Did my previous way of marking subjects as complete do anything and is it necessary in this case?

As a code example:

val observable: PublishSubject<Int> = PublishSubject.create()
val disposable = observable.subscribe { /* subscription */ }

fun onDestroy() {
    observable.onComplete() // is this line necessary or helpful?
    disposable.dispose()
}
Talendar
  • 1,841
  • 14
  • 23
Allan W
  • 2,791
  • 4
  • 23
  • 41
  • You might want to look into Lifecycle objects, there's easier ways of making sure objects are cleaned up in onDestroy. https://developer.android.com/topic/libraries/architecture/lifecycle – Gabe Sechan Sep 16 '18 at 21:04
  • I'm not sure if lifecycle is only compatible with androidx or not, but it would still be helpful for me to know how to use this in a setting outside of Android. – Allan W Sep 17 '18 at 02:44

2 Answers2

6

observable.onComplete() will complete your stream and so fire this event to all subscribers listening for onComplete, you don't need to dispose stream after onComplete (this is done automatically).

disposable.dispose() will stop stream and no complete event will be fired.

If you're not listenening for complete event both are the same, so to answer your question you don't need both lines.

Samuel Eminet
  • 4,647
  • 2
  • 18
  • 32
1

Doing it on onDestroy is not a good idea because there is a gap between when the fragment/activity is stopped and when it's destroyed. If your observable fires during that gap, you will most likely do some UI work that will result in an exception, as you're attempting to manipulate UI objects after the activity/fragment was stopped.

A better approach is to offload this business logic to a viewmodel and then the UI listens for updates from the viewmodel via LiveData (which is itself lifecycle aware, so it takes care of subscribing/unsubscribing as needed). The code you showed here would then be moved to the viewmodel's onCleared method.

Check this and this for reference.

Francesc
  • 25,014
  • 10
  • 66
  • 84
  • What about in the case without livedata? The code for destroy is currently for views, but given this explanation, it may be okay to do it during onStop for activities correct? – Allan W Sep 17 '18 at 13:15
  • Yes, if you don't use LIveData, you should unsubscribe in onStop and resubscribe in onStart. – Francesc Sep 17 '18 at 15:09