How to Keep your RxJava Subscribers from Leaking |

How to Keep your RxJava Subscribers from Leaking |

Edit: Shortly after writing this l, I realized that the solution that I present here isn't very good. I'm leaving it here just in case it can serve as a building block for better solutions.

Sometimes you don't have control over the lifecycle of your Subscribers. In these cases, to avoid leaking your Subscriber, you have to unsubscribe from your Observable when you're notified that your Subscriber is about to be destroyed. It can be really annoying to have to worry about unsubscribing your Subscriptions to avoid memory leaks, so in this post, I'll show how, with a few lines of code, you can stop worrying about leaking your Subscribers.

Before I try to show how to memory-leak-proof your Subscribers, I want to give a concrete example that shows when memory-leak-proof Subscribers might be useful. This example will also clarify the problem that memory-leak-proof Subscribers are trying to solve. I spend most of my time doing Android development these days, so an Android example is the most natural way for me to elaborate on this problem, so here's an Android-specific use-case: You'd probably want want a memory-leak-proof Subscriber when you're writing an Activity.

An Android Activity is basically a screen that you see when you're using an Android app. The Android framework manages the lifecycle of Activities. Activities, moreover, are also often responsible for responding to touch events.

Read full article from How to Keep your RxJava Subscribers from Leaking |