Status Update
Comments
il...@google.com <il...@google.com> #2
Branch: androidx-master-dev
commit b90079595f33f58fece04026a97faa0d243acdb1
Author: Yuichi Araki <yaraki@google.com>
Date: Wed Sep 18 16:55:49 2019
Change the way to detect mismatch between POJO and query
This fixes cursor mismatch warnings with expandProjection.
Bug: 140759491
Test: QueryMethodProcessorTest
Change-Id: I7659002e5e0d1ef60fc1af2a625c0c36da0664d8
M room/compiler/src/main/kotlin/androidx/room/processor/QueryMethodProcessor.kt
M room/compiler/src/main/kotlin/androidx/room/solver/TypeAdapterStore.kt
M room/compiler/src/main/kotlin/androidx/room/solver/query/result/PojoRowAdapter.kt
M room/compiler/src/test/kotlin/androidx/room/processor/QueryMethodProcessorTest.kt
M room/compiler/src/test/kotlin/androidx/room/testing/TestProcessor.kt
po...@gmail.com <po...@gmail.com> #3
il...@google.com <il...@google.com> #4
Branch: androidx-master-dev
commit bdde5a1a970ddc9007b28de4aa29d60ffa588f08
Author: Yigit Boyar <yboyar@google.com>
Date: Thu Apr 16 16:47:05 2020
Re-factor how errors are dismissed when query is re-written
This CL changes how we handle errors/warnings if query is
re-written.
There was a bug in expandProjection where we would report warnings
for things that Room already fixes automatically (
The solution to that problem (I7659002e5e0d1ef60fc1af2a625c0c36da0664d8)
solved it by deferring validating of columns until after re-write
decision is made. Unfortunately, this required changing PojoRowAdapter
to have a dummy mapping until it is validating, make it hard to use
as it does have a non-null mapping which is not useful.
This CL partially reverts that change and instead rely on the log
deferring logic we have in Context. This way, we don't need to break
the stability of PojoRowAdapter while still having the ability to
drop warnings that room fixes. This will also play nicer when we
have different query re-writing options that can use more information
about the query results.
Bug: 153387066
Bug: 140759491
Test: existing tests pass
Change-Id: I2ec967c763d33d7a3ff02c1a13c6953b460d1e5f
M room/compiler/src/main/kotlin/androidx/room/log/RLog.kt
M room/compiler/src/main/kotlin/androidx/room/processor/QueryMethodProcessor.kt
M room/compiler/src/main/kotlin/androidx/room/solver/TypeAdapterStore.kt
M room/compiler/src/main/kotlin/androidx/room/solver/query/result/PojoRowAdapter.kt
po...@gmail.com <po...@gmail.com> #5
Of course the logic of my project is more sophisticated but this reproduces the issue quite well. If you click the first BottomNavigation item N times you need N+1 system back navigation triggers to leave the app.
il...@google.com <il...@google.com>
jb...@google.com <jb...@google.com> #6
So first, we plan to get rid of these APIs in the future. The only behavior for NavigationUI will be to always save and restore the state of the back stack. Luckily, NavigationUI is purposely built only on publicly available APIs so you could always copy our code and make your custom adjustments for whatever your desired behavior is.
The source of the bug is
We need to add a fix to ensure we take into account the proper destination on our side, but as I mentioned those APIs will go away in the future. So if you wanted to proactively create your own API, you could make your API navigate directly to the start destination instead of the graph. That would allow you to not wait on our release and ensure you always have your desired behavior going forward.
po...@gmail.com <po...@gmail.com> #7
Thanks a lot for your help! I basically removed the first embedded graph by moving the code directly into the topmost navGraph and as you said, navigate directly to the start destination. As far as I can tell, it seems to work now.
cl...@google.com <cl...@google.com>
ap...@google.com <ap...@google.com> #8
Branch: androidx-main
commit 5624b7cefcfe5e0abb01f1063b040e5f2f135b75
Author: Clara Fok <clarafok@google.com>
Date: Wed Nov 30 16:47:38 2022
Clean up launchSingleTop logic
Basic refactoring in preparation for fix to
Test: ./gradlew navigation:navigation-runtime:cC
Bug: 253256629
Change-Id: Ib65764c345451d8be4613f6e3d278cc1a170091e
M navigation/navigation-runtime/src/main/java/androidx/navigation/NavController.kt
ap...@google.com <ap...@google.com> #9
Branch: androidx-main
commit f433d5458950a632900f8a2685ce6eab27272f8c
Author: Clara Fok <clarafok@google.com>
Date: Thu Dec 01 15:52:28 2022
Fix BottomNavView launchSingleTop with NavGraph
NavController previously did not apply launchSingleTop when user repeatedly navigates to the starting destination of a Menu when this starting destination is a NavGraph. This results in the destination being added mulitple times to backstack.
Now NavController checks if the destination is a NavGraph and if so, adds all destinations from the node to its final startDestination (i.e. nested nav graphs) to singleTop.
NavController backstack and Navigator backstacks entries are replaced accordingly upon singleTop navigations.
Test: ./gradlew navigation:navigation-runtime:cC
Bug: 253256629
Relnote: singleTop now works with NavGraph such that if the top destination of the backstack is a NavGraph's startDestination, all destinations starting from original destination to its startDestination will only be added to the top of the backstack once.
Change-Id: Id4bea16aff3dd776826fc6d746475e293eb64b0e
M navigation/navigation-common/src/main/java/androidx/navigation/NavigatorState.kt
M navigation/navigation-runtime/src/androidTest/java/androidx/navigation/NavControllerTest.kt
M navigation/navigation-runtime/src/main/java/androidx/navigation/NavController.kt
cl...@google.com <cl...@google.com> #10
This has been fixed internally and will be available in Navigation 2.6.0-alpha05
pr...@google.com <pr...@google.com> #11
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.navigation:navigation-common:2.6.0-alpha05
androidx.navigation:navigation-runtime:2.6.0-alpha05
Description
Component used: Navigation / NavigationUI Version used: 2.5.2 Devices/Android versions reproduced on: OnePlus 8T / Android 12
I'm using a menu resource file which is bound to a BottomNavigationView. Also I'm setting up the navigation like so
NavigationUI.setupWithNavController(bottomNavigationView, navController, false)
which means I'm using the experimental version of this API.I don't want the state of each menu item to be saved since I want to come back to the respective start destination if a
BottomNavigationView
item gets reselected. So regardless of how deep I got in a navigation graph a reselection of the same item takes you back to the start destination.I'm using a navGraph which consists of several nested navGraphs like so:
The
one_navigation
could look like this:It works pretty good so far, the point is when I click the first BottomNavigationView's menu item
N times
I got the destinationN+1 times
on my back stack. If I wanted to leave the app by triggering the system's back navigation I'd have to do itN+1 times
.So I actually expect the startDestination to only exist once on the back stack regardless of how often I click the respective menu item setup with the above mentioned API.