Fragments: Past, present, and future (Android Dev Summit '19)

What people said

Recommends ianhanniballake · 2019-10 · Stack Overflow · on “Fragment Unit Testing: launchFragment throws ClassCastException”

FragmentScenario adds your Fragment to an empty activity class - the androidx.fragment.app.testing.FragmentScenario$EmptyFragmentActivity mentioned in the stack trace. That means that your Fragment is not in an instance of your InspectionActivity class. You're getting a crash because your clearRFIDCache() method is casting the activity to InspectionActivity . If you want to need to test your Fragment within a specific instance of Activity and have a strong coupling between the two, you need to use ActivityScenario and manually add your Fragment to that Activity, rather than using FragmentScenario that gives you no control over the activity class you're using. Ideally, you shouldn't tightly c

Recommends francas · 2019-11 · Stack Overflow · on “Which Layout to use with Fragments?”

You can use the new androidx.fragment.app.FragmentContainerView to get a better performance than FrameLayout. Here [this video] more information.

Recommends Maksim Turaev · 2019-11 · Stack Overflow · on “Is it necessary to use fragment in the activity?”

Fragments are just small activities. Google promotes fragments and invests in them at least last couple of years, so you'd better use them. For more information watch [this video]

Recommends Michalsx · 2020-01 · Stack Overflow · on “<androidx.fragment.app.FragmentContainerView> vs <fragment> as a view for a NavHost”

I do not see any explanation why replace Fragment view with FragmentContainerView . This is why I added this answer (source below). One of the common patterns to host fragments in an activity is to use a FrameLayout. The Android community have been doing this for years but this is going to change now. The androidx team introduced this new view called FragmentContainerView to do this for you. All you have to do is replace your FrameLayout with FragmentContainerView and everything should work out of the box, you won’t need to change anything on the way you handle fragment transactions. The benefits gained here is the improved handling of what’s called the z-ordering for fragments. Here’s the e

Cites ianhanniballake · 2019-11 · Stack Overflow · on “LifecycleOwner: difference between Fragment (self) and Fragment#viewLifecycle”

There are two different lifecycles because the Fragment itself lives longer than the Fragment's view. There are a number of events that can cause the Fragment's view to be destroyed, but currently keep the Fragment itself alive: Putting the Fragment on the back stack (i.e., when you navigate() to another Fragment) Calling detach() on a Fragment Calling setMaxLifecycle(Lifecycle.State.CREATED) on a Fragment In these cases, the Fragment's view is destroyed, moving the Fragment view lifecycle to DESTROYED . However, the lifecycle of Fragment itself is not destroyed - it generally stays as CREATED . This means that the Fragment can go through multiple cycles of onCreateView() -> onViewCreated()

Cites ianhanniballake · 2019-11 · Stack Overflow · on “Retrieve Fragment from Navigation Drawer”

When using Navigation and a NavHostFragment , your Fragments are child fragments of the NavHostFragment in your layout. Fragment navHostFragment = getSupportFragmentManager().findFragmentById( R.id.nav_host_fragment); // Whatever your ID in your layout is FragmentManager childFragmentManager = navHostFragment.getChildFragmentManager(); // Now you can get your Fragment from the childFragmentManager MyFragment fragment = childFragmentManager.findFragmentByid(R.id.fragmentId); However, the recommended pattern for passing interfaces to your Fragments in the Navigation world is via constructor injection by using a FragmentFactory as discussed in the Fragments: Past, Present, and Future talk [VIDE

Cites CommonsWare · 2019-12 · Stack Overflow · on “Use viewLifecycleOwner as the LifecycleOwner”

Why I get this error? Lint is recommending that you use the lifecycle of the fragment's views ( viewLifecycleOwner ) rather than the lifecycle of the fragment itself ( this ). Ian Lake and Jeremy Woods of Google go over the difference as part of this Android Developer Summit presentation [this video] , and Ibrahim Yilmaz covers the differences in this Medium post [LINK] In a nutshell: viewLifecycleOwner is tied to when the fragment has (and loses) its UI ( onCreateView() , onDestroyView() ) this is tied to the fragment's overall lifecycle ( onCreate() , onDestroy() ), which may be substantially longer How to get rid of it? Replace: viewModel.students.observe(this, Observer { //TODO: populate recy

Cites ianhanniballake · 2019-12 · Stack Overflow · on “Could Navigation Arch Component create a false positive memory leak?”

That's how Fragments on the back stack work (and Navigation just uses the existing Fragment APIs): the Fragment's view is destroyed, but the Fragment itself is not destroyed - they are kept in the CREATED state until you hit the back button and return to the Fragment (after which onCreateView() will be called again and you'll move back up to RESUMED ). As per the Fragments: Past, Present, and Future talk [this video] , one of the future changes coming to Fragments is an opt in option to destroy Fragments on the back stack, rather than having two separate lifecycles. This isn't available as of yet. You have to null out your references to the views in onDestroyView as that's the sign that the view

Cites ianhanniballake · 2020-11 · Stack Overflow · on “How to set target fragment of a dialog when using navigation components”

Also keep in mind that `setTargetFragment()` is itself deprecated [LINK] ), with replacements at both the Navigation level [LINK] and Fragment level [LINK] that, unlike `setTargetFragment()`, will work when using upcoming features [this video] such as multiple back stacks and single lifecycle.

Cites rguzman · 2021-01 · Stack Overflow · on “RecyclerView with StaggeredGridLayoutManager in ViewPager, arranges items automatically when going back to fragment”

The Navigation Component behavior is normal when you navigate from one fragment to another. I mean, onDestroyView() method from the previous fragment is executed, so it means that your view is destroyed, but not the fragment. Remembering that fragment has two lifecycles one for the fragment and another one for the view, There was a video [this video] about it. Also, there were issues registered in issue tracker in order to avoid this behavior in some cases and the GitHub issues: [LINK] [LINK] The problem is that when you have fragment that is heavy to recreate , is easier to do not destroy it and just add one fragment. So, when you go back it is not recreated. But, for this behavior is not part o