Will there ever be a `DefaultLifecycleObserver` th...

# android

[ConorG]

Will there ever be a DefaultLifecycleObserver that can observe the entire Fragment lifecycle and not just the Fragment View Lifecycle?

I ask because I want to get my team on-board with using FragmentFactory. Some have pushed back citing that it’s awkward having to remember to set it before calling onCreate and unset it in onDestroy. I was able to somewhat alleviate the issue by creating a DefaultLifecycleObserver that can unset it, and also register a FragmentLifecycleCallbacks so in onFragmentCreated I can check savedInstanceState to determine if recovering from process death where I can set the required Factory again.
If I could hook into the Fragment’s onCreate from the get-go I think it would be possible to just set the Factory once, like in an init block, then the developer doesn’t have to remember to do any more maintenance on it.

@Ian Lake?

[Kenneth Leong]

let me take a stab at it. If i am not wrong, in Fragments where are 2 lifecycle handles that you can observe. One is the fragment class lifecycle which is essentially Fragment.getLifecycle() which lets you observe the fragment from onCreate() onwards. The other Livecycle handle is Fragment.getViewLifecycleowner().getLifecycle() and this is the lifecycle of the Fragment’s view only, and ends when the view is destroyed.

[Ian Lake]

Yeah, like Kenneth said, you already have both lifecycles available to you, but I don't understand why you need that in the first place?

[Ian Lake]

For one, the ON_CREATE event is too late to set a FragmentFactory. Your child fragments have already been restored by then with the default factory

[Ian Lake]

For two, what makes you think you have to unset the factory in onDestroy()? That's never been a requirement.

[Ian Lake]

For three, keep in mind that FragmentFactory affects the whole hierarchy. Setting it once on your activity would affect child fragments and child fragments of child fragments (you'd need to explicitly set a different FragmentFactory on one of those child FragmentManagers to use a different factory).

[Ian Lake]

Lastly, for the child fragment case, you absolutely can set your FragmentFactory in an init block. That's a perfectly valid place to set it

[ConorG]

what makes you think you have to unset the factory in onDestroy()? That’s never been a requirement.

@Ian Lake Our project is modularised with many feature modules and a top-level Application module that binds them together. When I navigate from the app module to a feature module, the root node (Fragment) of that feature module will set a FragmentFactory scoped to that feature. When navigating back from that root feature to to the app module, I reset the FragmentFactory to be the default (or whatever one app-level uses). That’s what I use ON_DESTROY for. Otherwise the Framework is still trying to instantiate Fragments using the feature-scoped FragmentFactory.

[Ian Lake]

It sounds like your FragmentFactory should just have an addFeatureFactory() and removeFeatureFactory() method that swaps what feature specific factories it loops through

[ConorG]

If I understand correctly, that would be the top-level or default FragmentFactory, which I guess would work, but then that would feel like my app module is doing too much for the feature modules, the intention was that it just binds its dependant feature modules but not control them. My objective was to have it so that my modules could autonomously set and unset their own FragmentFactory as needed, it would make for less coupling.

ON_CREATE event is too late to set a FragmentFactory.

Yeah I see it’s called after the super.onCreate so it’s just too late to suit my use case. For my delegate to work it would have to hook in earlier, like onAttach, which I’m guessing is impossible. The below snippet is what I currently use and it works, the fragFactory delegate also handles setting the factory again after process restore.e

Untitled

[Ian Lake]

If you're only setting the FragmentFactory on the child Fragment manager 1) you can do that in init and 2) there's no need to do anything on destruction, since the FragmentFactory gets cleared out with the child FragmentManager when the Fragment is removed

[ConorG]

And if I wanted to set the parentFragmentManager, where other Fragments within that feature module might not necessarily be child Fragments of the root node Fragment I guess I’m out of luck.

Say I have an app-level AppFragment that navigates to FeatureFragA (the root node of the feature, acts as HostFragment)_,_ I want this feature fragment to set the parentFragmentManager’s factory to the the Feature factory, so any other Fragments it navigates to within the feature using navigation library, say FeatureFragB, will still be using the feature factory. Then as I leave the the feature, by navigating back from FeatureFragA to AppFragment, FeatureFragA will then reset the parentFragmentManager’s factory back to the default.

[Ian Lake]

You can't rely on the ordering of restoration of sibling fragments, so the parent fragment still would need to be aware of and keep track of what features it should load before restoring it's child FragmentManager state