Rxjava: Why doesn't CompositeSubscription have a way to re-initialize its instance?

Created on 18 May 2015  路  3Comments  路  Source: ReactiveX/RxJava

As this article says, CompositeSubscription is hard to use in Android activities / fragments because there is no way to re-initialize its instance.

I wonder why its clear() method does not clear its state. Is there any reason about it? Or, is it just a bug in COmpositeSubscription?

Most helpful comment

RxJava containers are designed with a terminal state in mind. When a container gets into its terminal state via unsubscribe() atomically, all previous contained elements are unsubscribed and all subsequent add/set of a Subscription is immediately unsubscribed and never added to the container. Since unsubscription is highly asynchronous, checking isUnusbscribed() is not sufficient to avoid starting tasks or creating resources in case of a concurrent unsubscribe call.

The clear method removes all contained subscription and unsubscribes them, but you can add new subscriptions to the composite after that.

In android terms, imagine you have a background task which wants to add a Subscription to the app composite just after your app is signalled to pause. Without a guaranteed terminal state, your async task would succeed and now you have a resource leak. With the guaranteed terminal state, the resource is immediately unsubscribed and no leak happens.

As the article says, you need to replace the composite with a fresh one and restart any async observations as needed.

All 3 comments

RxJava containers are designed with a terminal state in mind. When a container gets into its terminal state via unsubscribe() atomically, all previous contained elements are unsubscribed and all subsequent add/set of a Subscription is immediately unsubscribed and never added to the container. Since unsubscription is highly asynchronous, checking isUnusbscribed() is not sufficient to avoid starting tasks or creating resources in case of a concurrent unsubscribe call.

The clear method removes all contained subscription and unsubscribes them, but you can add new subscriptions to the composite after that.

In android terms, imagine you have a background task which wants to add a Subscription to the app composite just after your app is signalled to pause. Without a guaranteed terminal state, your async task would succeed and now you have a resource leak. With the guaranteed terminal state, the resource is immediately unsubscribed and no leak happens.

As the article says, you need to replace the composite with a fresh one and restart any async observations as needed.

Thanks to describe details. I have understood that it is designated behavior and making a new instance of CompositeSubscription is the only way to control it.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

yubaokang picture yubaokang  路  3Comments

dsvoronin picture dsvoronin  路  4Comments

hoc081098 picture hoc081098  路  3Comments

nltran picture nltran  路  4Comments

aballano picture aballano  路  3Comments