IssueTracker

If you're using Hilt, you can also use hiltNavGraphViewModel() - despite its name, it is a drop in replacement for viewModel() that works in all scenarios (using Fragment 1.3.2 or Fragment 1.3.3, using Navigation Compose or not).

Thanks for this information. hiltNavGraphViewModel() will fallback to viewModel() if LocalViewModelStoreOwner isn't NavBackStackEntry.

True, you'd need to explicitly pass the defaultViewModelProviderFactory to viewModel() to force using the Fragment's ViewModelProviderFactory.

So there's three important use cases that we need to support when using the ViewTreeViewModelStoreOwner API and the ViewModelStoreOwner provided by that object:

1. Creating and using a custom Factory tied to the Fragment's View SavedStateRegistry (this is very important for AbstractSavedStateViewModelFactory and SavedStateViewModelFactory - this is what was fixed in Fragment 1.3.3 in b/181577191 and why the ViewTreeViewModelStoreOwner API now must return the private FragmentViewLifecycleOwner class.

2. Using the default factory. Right now, FragmentViewLifecycleOwner does not implement HasDefaultViewModelProviderFactory and, thus, a NewInstanceFactory is always used. This is ~never correct and FragmentViewLifecycleOwner should implement that interface and mimic the logic of Fragment's getDefaultViewModelProviderFactory() to lazily create a SavedStateVieModelFactory.

3. Developers who override getDefaultViewModelProviderFactory() at the Fragment level (either directly or via Hilt). Due to limitations in the ViewModel APIs (which we hope to address longer term), any AbstractSavedStateViewModelFactory factory here won't be using the right SavedStateRegistry as it should if used via the ViewTreeViewModelStoreOwner APIs (it'll be using the SavedStateRegistry of the Fragment itself). However, this use case is quite important to have working out of the box and as it was before, despite not being exactly right.

These three cases must all work. Therefore, I think the best solution is to:

• Have FragmentViewLifecycleOwner implement HasDefaultViewModelProviderFactory
• Have that implementation call the Fragment's getDefaultViewModelProviderFactory() method. If that method returns a custom factory (i.e., not the one lazily created by Fragments when that method isn't overridden), use that factory. This will fix Hilt's use case.
• If the factory returned by the Fragment's getDefaultViewModelProviderFactory() is the lazily created Fragment factory, instead create a new lazily created SavedStateViewModelFactory that is tied to the SavedStateRegistry of the Fragment's View using the same logic as Fragment uses. This will fix the default factory case.

We've fixed this issue for the upcoming Fragment 1.3.4 bug fix release and Fragment 1.4.0-alpha01.

When using Hilt or any fragment that overrides getDefaultViewModelProviderFactory(), that factory will also be used from Compose's viewModel() method.