Minute of Pain #2. Leaks

Or how app can leak in obvious but surprise moments

LayoutManager

Okey, this one is simple. LayoutManager already by the name of the class can arouse your suspicion about its relation to RecyclerView. And that’s true: if we go to the source code of base abstract class LayoutManager we will see, that RecyclerView presents as one of its fields.

public static abstract class LayoutManager {
ChildHelper mChildHelper;
RecyclerView mRecyclerView;
...

Adapter

This one relates to both ListView adapters and RecyclerView adapters. But I will be talking about RecyclerView’s one. Adapter for ListView, have an analogous mechanism.

MenuItem

After “nulliating” all views and cleaning all adapters, layout managers and others view related objects, it would seem, what else can leak view? Maybe that’s all? No. And this time I was framed by a MenuItem.

Afterwords

I didn’t say you something new. I didn’t point to a lack of Android SDK architecture. Of course not. What I tried to say, is to we need always be attentive and careful when working with the code. No rush, no hurry. Especially when you refactor or try to fix memory leaks. And it’s not urgent that your code smells, so you need to be slow etc. No, I mean that always there can be things that are pretty obvious but we all can easily forget about them.

Love being creative to solve some problems with an simple and elegant ways

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store