IssueTracker

Assuming you're calling both these on the main thread, there cannot be a race condition (since the construction of the ViewModel happens synchronously). I look forward to your reproduction project.

Note that:

1. SavedStateViewModelFactory is the default on Navigation 2.2.0+, so you can leave out the factory entirely.

2. You don't need to use ViewModelProvider at all when in Kotlin. Instead, you'd want to use val viewModel: WorksViewModel by viewModels({ findNavController().previousBackStackEntry!! }) and similarly for your currentBackStackEntry.

Ok, I managed to reproduce it: https://drive.google.com/file/d/1tQLBgBLfztBrIUqVBPrEOMPCU4bs5fWU/view?usp=sharing

1. When you launch the app, "Fragment A" starts and inside onStart prints:

I/System.out: FragmentA gets instance: co.bstorm.navtest.FKCZViewModel@be69e6b

2. Click on the "SETTINGS" button on the top right, "DialogFragment B" launches and inside onStart prints:

I/System.out: DialogFragmentB gets instance: co.bstorm.navtest.FKCZViewModel@be69e6b

This is normal as be69e6b == be69e6b, they both get the same instance.

3. Now, while you're on DialogFragmentB, trigger either a process kill or activity kill (via developer options), and then go back to the app. Both Fragments get instantiated, their respective onStart methods run and this gets printed:

I/System.out: FragmentA gets instance: co.bstorm.navtest.FKCZViewModel@7fbae4b
I/System.out: DialogFragmentB gets instance: co.bstorm.navtest.FKCZViewModel@d219bc3

This time they get 2 different instances of the same ViewModel as 7fbae4b != d219bc3.

As you suggested, Fragment A uses:

val vm: FKCZViewModel by viewModels({ findNavController().currentBackStackEntry!! })

while DialogFragment B uses:

val vm: FKCZViewModel by viewModels({ findNavController().previousBackStackEntry!! })

Hope this helps :)

I added some additional logging and that pointed out the problem pretty quickly:

val vm: FKCZViewModel by viewModels({
    val backStackEntry = findNavController().currentBackStackEntry!!
    println("FragmentA gets back stack entry: $backStackEntry, ${backStackEntry.destination}")
    backStackEntry
})

Gives a logcat after process death of:

FragmentA gets back stack entry: androidx.navigation.NavBackStackEntry@af1aa01, Destination(co.bstorm.navtest:id/newsDetailFragment) label=label

Which is technically correct: the currentBackStackEntry is indeed your dialog NewsDetailFragment when your DialogFragment is above it and not the same NavBackStack entry associated with your FragmentA.

Using getBackStackEntry(R.id.fkczFragment) (which will always point to the same instance) rather than the relative currentBackStackEntry ensures that you always get the right NavBackStackEntry related to your FragmentA.

Given what I'm seeing, I don't think there's anything that is wrong, but there is a lot of unexpected behavior here when it comes to DialogFragments (so much so that we already had a whole section relating to dialogs).

At the very least, we should update the docs to call this out, but I'll take a look to see if there is any additional way we can help developers avoid these kind of pitfalls.

I see.. yeah now it works fine. This is fine by me, as far as I'm concerned there's nothing else you should do, it's just that this should be properly documented when it gets to beta or stable release.

Thanks!

Re #6 - if you're only accessing the ViewModel in onCreateView()/onViewCreated() (which would be the correct place to observe() for results), those won't be called when you have another <fragment> destination on top of you - they'll only be called once your fragment destination becomes the current destination, so that case will work as expected.