Change the behavior of the fragment backstack to destroy fragments [124181028]

Assigned

Feature Request

Status Update

No update yet.

Description

ev...@tatarka.me

created issue #1

Feb 11, 2019 12:59AM

Component used: Fragment
Version used: androidx.fragment:fragment 1.1.0-alpha04

The current behavior is for fragments to destroy only their views when they are in the backstack. This makes their lifecycle way more complicated to deal with since you need to handle views being created and destroyed out from under you. You also may not notice you they aren't handling this until you put a fragment on the backstack since this (and FragmentPagerAdapter) are the only common cases where this will happen.

I propose changing the behavior to destroying fragments when they are put on the backstack and saving their instance state. Going back would re-create them with the saved state. I believe making this change in a version update should be ok since you already need to handle the recreation of fragments due to config changes. However, if a more gradual approach is desired, then a setter to FragmentManager could be added, and the docs could push you to enabling it, making it the default in the future.

Furthermore, the attach(), and detach() methods should be deprecated to discourage any other uses that cause this behavior.

Comments

il...@google.com <il...@google.com> #2Feb 13, 2019 05:55AM

Assigned to il...@google.com.

I'm marking this as "won't fix" as there's nothing Compose here can do, as this is a platform quirk that has been adjusted to be more predictable in recent API versions.

The crux of the issue here is the fitSystemWindows in the extra View, like you mentioned, and a platform change in API 30.

Prior to API 30, window insets were dispatched through the view hierarchy in a non-intuitive way: Rather than being a full breadth-first traversal, they would be dispatched in preorder. If the insets were consumed at any point (like if you use fitSystemWindows), then the preorder would prevent insets from being dispatched to the rest of the view hierarchy. This is very unintuitive: It meant that sibling views (or views deeper in the tree) could stop later views from receiving the dispatch of insets.

In API 30, this behavior was changed to be more intuitive: Now, insets are dispatched in a top-down manner, so they can't be consumed in this weird, cross-tree way.

There's a couple solutions here:

Avoid fitSystemWindows from views if you're handling insets manually
Override dispatchApplyWindowInsets in the view groups above where you have fitSystemWindows defined, and manually perform the new, non-broken dispatching behavior. You can see a comparison of the two methods here: https://cs.android.com/android/platform/superproject/+/master:frameworks/base/core/java/android/view/ViewGroup.java;l=7341-7371;drc=6411c81462e3594c38a1be5d7c27d67294139ab8

zh...@gmail.com <zh...@gmail.com> #3Feb 25, 2019 10:55PM

Using composable version 1.2.1, I could fix it using:

override fun onCreate(bundle: Bundle?) {
        WindowCompat.setDecorFitsSystemWindows(window, false)
        super.onCreate(bundle)
        if (Build.VERSION.SDK_INT > Build.VERSION_CODES.Q){
            window.setFlags(WindowManager.LayoutParams.FLAG_LAYOUT_NO_LIMITS, WindowManager.LayoutParams.FLAG_LAYOUT_NO_LIMITS)
        }
}

Then statusBarsPadding works as expected on Api 29

va...@gmail.com <va...@gmail.com> #4Mar 3, 2019 04:25PM

Is there a possibility that this bug is somehow impacting View based onApplyWindowInsetsListener s? I am seeing an issue when navigating from a compose based (non-edge-to-edge) fragment to a view based edge-to-edge fragment where the onApplyWindowInsetsListeners are not being called. This is fixed by simply calling requestApplyInsets() in an onLayoutChangedListener, but I am trying to get down to the root of the problem. Unfortunately I am unable to post any code, but have been digging for a while in to the windowInsets source code and can't find anything. This only happens when the proceeding fragment is Compose based.

[Deleted User] <[Deleted User]> #5Aug 19, 2019 05:13PM

How would this work with target fragments? There would have to be some way of telling the system to notify the target fragment after it's created again.

ne...@gmail.com <ne...@gmail.com> #6Dec 4, 2019 09:56AM

> Furthermore, the attach(), and detach() methods should be deprecated to discourage any other uses that cause this behavior.

I don't agree with this, because I want those methods. They are very useful.

sc...@gmail.com <sc...@gmail.com> #7Apr 21, 2020 06:34AM

> Furthermore, the attach(), and detach() methods should be deprecated to discourage any other uses that cause this behavior.
I think too this methods is useful. I create multibackstack with this methods

yo...@google.com <yo...@google.com> #8Jul 22, 2020 10:09PM

This has started to block some downstream infrastructure work. Any chance we can get access to this soon, even as an option?

ka...@gmail.com <ka...@gmail.com> #9Jul 23, 2020 02:17PM

If this is implemented will fragment ViewModel instances survive backstack navigation? Wouldn't fragment ViewModels be cleared after it's moved into destroyed state?

il...@google.com <il...@google.com> #10Jul 23, 2020 05:03PM

Re #9 - the whole point of ViewModels is to survive the destruction and later recreation of the same fragment, so yes, they'd be saved.