Feature Request P3
Status Update
No update yet.
Comments
yb...@google.com
This actually has nothing to do with NavHostFragment, but is the behavior of NavController's setGraph().
When you call navController.setGraph(R.navigation.navigation_graph), it stores that ID and will restore that ID automatically.
If you were to instead use:
NavInflater navInflater = new NavInflater(this, navController.getNavigatorProvider());
navController.setGraph(navInflater.inflate(R.navigation.navigation_graph));
Then NavController would not restore the graph itself and the call to restoreState() you point out would only restore the back stack state, etc. but would wait for you to call setGraph again.
You're right that the inconsistency between the two setGraph methods is concerning. We'll take a look.
When you call navController.setGraph(R.navigation.navigation_graph), it stores that ID and will restore that ID automatically.
If you were to instead use:
NavInflater navInflater = new NavInflater(this, navController.getNavigatorProvider());
navController.setGraph(navInflater.inflate(R.navigation.navigation_graph));
Then NavController would not restore the graph itself and the call to restoreState() you point out would only restore the back stack state, etc. but would wait for you to call setGraph again.
You're right that the inconsistency between the two setGraph methods is concerning. We'll take a look.
se...@google.com
Turns out, we already had a tracking bug for this issue, will follow up on that other one.
sc...@javadude.com
Thank you for promptly replying to my report. You are right that the issue you've just mentioned is similar to mine. I shall continue observing the progress over there.
il...@google.com
ja...@gmail.com
I hate people that bullshit
Description
Version used: android.arch.lifecycle:extensions:1.1.1
Devices/Android versions reproduced on: emulators, API 8.1
LiveData created by Transformations.switchMap() retain "old" data when provided function returns null. Per the documentation, when the function returns null, there is no "backing" live data. If there is no backing live data, one would assume that there is no "data" in the live data created by switchMap.
For example:
class Sample1 : ViewModel() {
val personIdLiveData = MutableLiveData<String?>()
val personLiveData =
Transformations.switchMap(personIdLiveData) {
it?.let { db.getPersonDao().getById(it) }
}
}
If the personIdLiveData is set to null (no selection, perhaps), the previous value in personLiveData remains.
I recommend changing switchMap to something like the following (and perhaps an overload that allows a non-null default value to be passed if the caller desires)
// COPIED AND TWEAKED FROM Transformations.switchMap() IN android.arch.lifecycle:extensions:1.1.1
// NEW LINES ARE PRECEDED BY /*NEW*/
@MainThread
fun <X, Y> switchMap2(trigger: LiveData<X?>,
func: (X?) -> LiveData<Y?>?): LiveData<Y?> {
val result = MediatorLiveData<Y?>()
result.addSource(trigger, object : Observer<X?> {
private var mSource: LiveData<Y?>? = null
override fun onChanged(x: X?) {
val newLiveData = func(x)
if (mSource === newLiveData) {
return
}
if (mSource != null) {
result.removeSource(mSource!!)
}
mSource = newLiveData
if (mSource != null) {
result.addSource(mSource!!) { y -> result.value = y }
/*NEW*/ } else {
/*NEW*/ result.value = null
}
}
})
return result
}
The attached example project demonstrates the behavior before and after the fix.