Status Update
No update yet.
Comments
il...@google.com
setLaunchSingleTop still creates a new instance if you are only using just that single parameter as your NavOptions.
Can you please include a sample project that reproduces your issue?
al...@toptal.com
It was used also for a different issue, so to reproduce this case:
- Tap on
to first fragment - Tap on
to second fragment - You can see that counter on the screen is
1 - Tap on
open second fragment single top. - You can see that
OnDestinationChangedcallback was called, but the counter did not increment.
If you change libraries versions to
def nav_version = "2.3.5"
...
implementation 'androidx.lifecycle:lifecycle-runtime-ktx:2.4.1'
implementation 'androidx.activity:activity-ktx:1.4.0'
implementation 'androidx.fragment:fragment-ktx:1.4.0'
then in the same scenario, in point 5 the counter will be incremented.
Description
Component used: Navigation
Version used: 2.5.0
Devices/Android versions reproduced on: all
Along
setLaunchSingleTopchanged, and instead of replacing the current fragment instance, the same instance of fragment is reused. This is a behavioral change that actually broke the behavior that we used to base on.Let's say, that we opened a fragment with item details. All the logic related to this screen is loaded on the ViewModel initialization (with Dagger injection). Now, let's say that from this screen the user wants to navigate to the details of a different item, but using the
singleTopflag. With the old implementation the new fragment would get created and its ViewModel would be initalized with the correct data. With the new implementation, the old fragment would be reused, so no initialization will happen.The initialization is done when injecting Dagger dependencies, so simply registering the
OnDestinationChangedListenerdoes not seem like a proper approach.Therefore, I wanted to ask if there is any preferred way to mimic the old behavior, or what is the preferred way to reinitialize the fragment using the current single top approach?