Skip to content

Why doesn't CompositeSubscription have a way to re-initialize its instance? #2959

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
gfx opened this issue May 18, 2015 · 3 comments
Closed

Comments

@gfx
Copy link

gfx commented May 18, 2015

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?

@akarnokd
Copy link
Member

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.

@gfx
Copy link
Author

gfx commented May 18, 2015

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.

@ypresto
Copy link
Contributor

ypresto commented Jul 29, 2015

JavaDoc says clear() makes the composite "unoperative state", but actually it does NOT.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants