Status Update
Comments
sz...@gmail.com <sz...@gmail.com> #2
cs...@gmail.com <cs...@gmail.com> #3
jb...@google.com <jb...@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
na...@vitruvian.me <na...@vitruvian.me> #5
cs...@gmail.com <cs...@gmail.com> #6
cs...@twoupdigital.com <cs...@twoupdigital.com> #7
I attached a very small repro project to the issue which was marked as duplicate (
Would you please take a second look at it, and if you deem that it's still working as expected, would you consider providing a way to navigate conditionally with compose that doesn't have the result that is displayed in this issue and ours?
Thanks!
da...@gmail.com <da...@gmail.com> #8
contentAlignment = Alignment.TopStart
on the NavHost does not fix the issue. On the contrary, it makes it worse. If my animation is sliding from right to left, instead of animating steadily and centered, it now "curves up" towards the top start and it looks very strange.
Removing contentAlignment = Alignment.TopStart
makes the screen that's coming in look more correct, but the screen that's leaving the composition moves around (it looks like it tries to slide down?).
This is a very major bug with very severe visual consequences. I'm shocked this isn't being given more priority.
jb...@google.com <jb...@google.com>
ap...@google.com <ap...@google.com> #9
Branch: androidx-main
commit c9745b96364f8b4c4d8bb85d7dbc8652f7cb62d8
Author: Jeremy Woods <jbwoods@google.com>
Date: Thu Jan 18 01:37:07 2024
Support sizeTransform for Navigation Compose
Adding support for passing a SizeTransform to a composable or navigation
function when building the NavGraph. This will allow developers to
specify the SizeTransform for a specfic destination.
Note the sizeTransform is determined by the target destination, which is
normally the destination that runs the enter and popEnter transitions
and the default value is `null`.
RelNote: "You can now specify the `SizeTranform` for your transitions in
Navigation Compose by defining them as part of the initialization for
the `composable` and/or `navigation` functions."
Test: work in progress
Bug: 296912651
Change-Id: I91062221a47601b40ced80dc1a31f170351e9f5a
M navigation/navigation-compose/api/current.txt
M navigation/navigation-compose/api/restricted_current.txt
M navigation/navigation-compose/integration-tests/navigation-demos/src/main/java/androidx/navigation/compose/demos/NavigationDemos.kt
A navigation/navigation-compose/integration-tests/navigation-demos/src/main/java/androidx/navigation/compose/demos/SizeTransformDemo.kt
A navigation/navigation-compose/samples/src/main/java/androidx/navigation/compose/samples/SizeTransformSample.kt
M navigation/navigation-compose/src/androidTest/java/androidx/navigation/compose/NavHostScreenShotTest.kt
M navigation/navigation-compose/src/main/java/androidx/navigation/compose/ComposeNavGraphNavigator.kt
M navigation/navigation-compose/src/main/java/androidx/navigation/compose/ComposeNavigator.kt
M navigation/navigation-compose/src/main/java/androidx/navigation/compose/NavGraphBuilder.kt
M navigation/navigation-compose/src/main/java/androidx/navigation/compose/NavHost.kt
jb...@google.com <jb...@google.com> #10
This has been fixed internally and will be available in the Navigation 2.8.0-alpha04
release.
na...@google.com <na...@google.com> #11
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.navigation:navigation-compose:2.8.0-alpha04
Description
How exactly we want to take that variable, is not yet clear, but it could be something read at the destination level as part of the enter destination's transition.