Android leak pattern: subscriptions in views

Heads up, we’ve moved! If you’d like to continue keeping up with the latest technical content from Square please visit us at our new home https://developer.squareup.com/blog

In Square Register Android, we rely on custom views to structure our app. Sometimes a view listens to changes from an object that lives longer than that view.

For instance, a HeaderView might want to listen to username changes coming from an Authenticator singleton:

onFinishInflate() is a good place for an inflated custom view to find its child views, so we do that and then we subscribe to username changes.

The above code has a major bug: We never unsubscribe. When the view goes away, the Action1 stays subscribed. Because the Action1 is an anonymous class, it keeps a reference to the outer class, HeaderView. The entire view hierarchy is now leaking, and can’t be garbage collected.

To fix this bug, let’s unsubscribe when the view is detached from the window:

Problem fixed? Not exactly. I was recently looking at a LeakCanary report, which was caused by a very similar piece of code:

Let’s look at the code again:

Somehow View.onDetachedFromWindow() was not being called, which created the leak.

While debugging, I realized that View.onAttachedToWindow() wasn’t called, either. If a view is never attached, obviously it won’t be detached. So, View.onFinishInflate() is called, but not View.onAttachedToWindow().

Let’s learn more about View.onAttachedToWindow():

• When a view is added to a parent view with a window, onAttachedToWindow() is called immediately, from addView().
• When a view is added to a parent view with no window, onAttachedToWindow() will be called when that parent is attached to a window.

We’re inflating the view hierarchy the typical Android way:

At that point, every view in the view hierarchy has received the View.onFinishInflate() callback, but not the View.onAttachedToWindow() callback. Here’s why:

View.onAttachedToWindow() is called on the first view traversal, sometime after Activity.onStart()

ViewRootImpl is where the onAttachedToWindow() call is dispatched:

Cool, so we don’t get attached in onCreate(), what about after onStart() though? Isn’t that always called after onCreate()?

Not always! The Activity.onCreate() javadoc gives us the answer:

You can call finish() from within this function, in which case onDestroy() will be immediately called without any of the rest of the activity lifecycle (onStart(), onResume(), onPause(), etc) executing.

Eureka!

We were validating the activity intent in onCreate(), and immediately calling finish() with an error result if the content of that intent was invalid:

The view hierarchy was inflated, but never attached to the window and therefore never detached.

Here’s an updated version of the good old activity lifecycle diagram:

With that knowledge, we can now move the subscription code to onAttachedToWindow():

This is for the better anyway: Symmetry is good, and unlike the original implementation we can add and remove that view any number of times.