Leaking fragments?

[nikclayton]

I think the code might be leaking fragments in at least MainActivity.

To reproduce, modify TimelineFragment to log on every call to onResume, onPause, onStop, and onDestroy.

With that done, do the following:

1. Restart the app
2. Open the nav drawer, choose "Account preferences"
3. Press the back button

You should see the following logged

onResume()  // <-- from initially opening the app
onPause()   // <-- when "Account preferences" is opened
onStop()    // <-- ditto
onResume()  // <-- when pressing "Back" out of "Account preferences"

That's as expected.

Now do this:

1. Restart the app
2. Open the nav drawer, choose "Account preferences"
3. Open "Tabs"
4. Modify the tab list (either add or remove a tab)
5. Press the back button twice to go back to MainActivity and the timeline.

I see the following:

onResume()
onPause()
onStop()
onResume()
onResume()  // <-- the first four are the same, what's this extra onResume doing here?

I discovered this while working on #3121 -- if you do the above steps the "Refresh" menu item is added multiple times. But I've reproduced it on develop.

I suspect that the code in MainActivity.setupTabs() is not disposing of the previous fragments when the list of tabs change, and at least one of them is being retained. I haven't got a fix for it yet though.

---

• Tusky Version: develop at 6249dba (that commit isn't the culprit, it's the version I had checked out)

• Android Version: API 30

• Android Device: Pixel 4 emulator

• I searched or browsed the repo’s other issues to ensure this is not a duplicate.

[nikclayton]

tl;dr: This is something to do with how setupTabs() recreates the adapter and tab layout every time it's called.

Additional debugging (chiefly, including the kind and hashcode of the fragment in the onResume debug output) confirmed that this really was two different versions of the HOME fragment resuming, the initial one, and then a new one).

Things which didn't work to fix this include (all of these produced code that still worked, in as much as the tabs showed with the correct contents and behaved correctly, but all of them still have the "two fragments" problem):

• Thinking that this might be the FragmentStateAdapter not using the correct lifecycle, rewrote CustomFragmentStateAdapter(activity) to CustomFragmentStateAdapater(FragmentManager, Lifecycle), passing in this@MainActivity and this.lifecycle.

• Saving tabLayoutMediator in a property, and explicitly calling tabLayoutMediator?.detach() in setupTabs() before assigning the adapter to binding.viewPager.adapter

• ViewPager2 is supposed to be at the same level in the view hierarchy as TabLayout, and immediately after it. It's not (e.g., see https://developer.android.com/develop/ui/views/animations/vp2-migration#tablayout which says "with ViewPager2, the TabLayout element is declared directly above the ViewPager2 element, on the same level"). Rewriting the layout had no effect (and this would also break the bottom tab bar, which is another issue to consider).

• Making the adapter contain a mutable list, creating it with an empty list, assigning it to the viewpager, and then setting the list in the adapter and calling notifyDataSetChanged()

• MainPagerAdapter's list is a List. Tried changing to a List, and doing the conversion from TabData to Fragment in MainActivity (MainPagerAdapter(tabs.map { it.fragment(it.arguments) }, this).

What did work is moving:

• The creation of the adapter (which now has a mutable list of tabs)
• Adding the adapter to binding.viewPager
• Attaching the tablayoutmediator to the viewpager

to onCreate. Then setupTabs gets the list of tabs from the account, assigns them to adapter.tabs, and calls adapter.notifyDataSetChanged().

Should have a more refined fix later.

[nikclayton]

I think this is also why modifying unrelated tabs (e.g., adding or removing the DM tab) jumps you back to the top of your home timeline when you "back" out of "Account preferences > tabs",