Fixed
Status Update
Comments
jo...@linkedin.com <jo...@linkedin.com> #2
Project: platform/frameworks/support
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
https://android-review.googlesource.com/1123258
https://goto.google.com/android-sha1/b90079595f33f58fece04026a97faa0d243acdb1
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
il...@google.com <il...@google.com> #3
jo...@linkedin.com <jo...@linkedin.com> #4
Project: platform/frameworks/support
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 ( b/140759491 ).
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
https://android-review.googlesource.com/1288456
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
il...@google.com <il...@google.com> #5
Thanks, that's really helpful.
jb...@google.com <jb...@google.com> #6
The problem here is that the NavGraph is accidentally being added to the list of transitioning entries and will be fixed in aosp/1770665.
ap...@google.com <ap...@google.com> #7
Project: platform/frameworks/support
Branch: androidx-main
commit e3b742c6b338c04f6be0e6560c39c878376ad3ca
Author: Jeremy Woods <jbwoods@google.com>
Date: Fri Jul 16 16:22:09 2021
Mark destination navigating away from as transitioning
When navigating forward with transitions, although we don't hold the
lifecycle of the entry being kept on the back stack above CREATED during
the transition, we should still mark it as transitioning until its
transition is actually complete.
RelNote: "When navigating away from a `NavBackStackEntry` and using the
`pushWithTransition` API, the `NavigatorState` will now properly mark
the previous entry as transitioning."
Test: modified test
Bug: 172112072
Bug: 194301889
Fixes: 191870023
Change-Id: If0543dd1c20e7338078115e98b5585623f9b8f1c
M navigation/navigation-common/api/current.txt
M navigation/navigation-common/api/public_plus_experimental_current.txt
M navigation/navigation-common/api/restricted_current.txt
M navigation/navigation-common/src/main/java/androidx/navigation/NavigatorState.kt
M navigation/navigation-compose/src/main/java/androidx/navigation/compose/ComposeNavigator.kt
M navigation/navigation-compose/src/main/java/androidx/navigation/compose/NavHost.kt
M navigation/navigation-runtime/src/androidTest/java/androidx/navigation/NavBackStackEntryTest.kt
M navigation/navigation-runtime/src/main/java/androidx/navigation/NavController.kt
M navigation/navigation-testing/src/androidTest/java/androidx/navigation/testing/TestNavigatorStateTest.kt
M navigation/navigation-testing/src/main/java/androidx/navigation/testing/TestNavigatorState.kt
M testutils/testutils-navigation/src/main/java/androidx/testutils/TestNavigator.kt
https://android-review.googlesource.com/1770665
Branch: androidx-main
commit e3b742c6b338c04f6be0e6560c39c878376ad3ca
Author: Jeremy Woods <jbwoods@google.com>
Date: Fri Jul 16 16:22:09 2021
Mark destination navigating away from as transitioning
When navigating forward with transitions, although we don't hold the
lifecycle of the entry being kept on the back stack above CREATED during
the transition, we should still mark it as transitioning until its
transition is actually complete.
RelNote: "When navigating away from a `NavBackStackEntry` and using the
`pushWithTransition` API, the `NavigatorState` will now properly mark
the previous entry as transitioning."
Test: modified test
Bug: 172112072
Bug: 194301889
Fixes: 191870023
Change-Id: If0543dd1c20e7338078115e98b5585623f9b8f1c
M navigation/navigation-common/api/current.txt
M navigation/navigation-common/api/public_plus_experimental_current.txt
M navigation/navigation-common/api/restricted_current.txt
M navigation/navigation-common/src/main/java/androidx/navigation/NavigatorState.kt
M navigation/navigation-compose/src/main/java/androidx/navigation/compose/ComposeNavigator.kt
M navigation/navigation-compose/src/main/java/androidx/navigation/compose/NavHost.kt
M navigation/navigation-runtime/src/androidTest/java/androidx/navigation/NavBackStackEntryTest.kt
M navigation/navigation-runtime/src/main/java/androidx/navigation/NavController.kt
M navigation/navigation-testing/src/androidTest/java/androidx/navigation/testing/TestNavigatorStateTest.kt
M navigation/navigation-testing/src/main/java/androidx/navigation/testing/TestNavigatorState.kt
M testutils/testutils-navigation/src/main/java/androidx/testutils/TestNavigator.kt
di...@gal-digital.de <di...@gal-digital.de> #8
+1
jb...@google.com <jb...@google.com> #9
This has been fixed internally and will be available as part of the Navigation 2.4.0-alpha06
release.
je...@gmail.com <je...@gmail.com> #10
Phew 😅
di...@gal-digital.de <di...@gal-digital.de> #11
fix from `2.4.0.-alpha06` works
Description
Component used: Navigation Compose
Version used: 2.4.0-alpha05
Devices/Android versions reproduced on: Pixel 5, SDK 31
I have an
Activity
which displays a screen with a button (ComposableA
) and when I tap on the button, I want to display another screen (ComposableB
). When I tap back onComposableB
, I don't want to go back to theComposableA
, instead I want to close the app.My understanding was that I could do it like this:
When I tap the button,
ComposableB
appears for a brief moment, but then the app crashes with the following stack trace (see below). When I remove theinclusive = true
(or when I set it tofalse
) the app doesn't crash, but then tapping the phone's back button takes me back toComposableA
. I don't want – I want the app to close when I tap back. Think ofComposableA
as just a login screen.I can't figure out what am I doing wrong. I was following this documentation . I feel like this could be a bug in Navigation or Compose.
These are my build.gradle files, if that helps: