Status Update
No update yet.
Comments
jb...@google.com
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
ti...@google.com
il...@gmail.com
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
ti...@google.com
Thanks for the repro in
Initial investigation showed that the enter/exit transitions are correct. What appears like a scale animation is a size transform. During the repeated destination change, there seems to be a frame where the new content is resolved into an empty list of measurables, which is incorrect.
Unclear what's causing this yet - either the content composable is not yet populated for that frame, or the UI tree applier deferred adding the nodes to the tree to the next frame. More investigation will be needed.
ti...@google.com
The content composable is indeed empty. It comes from currentEntry being null here:
Over to Jeremy to investigate further in Navigation.
al...@gmail.com
ho...@gmail.com
es...@gmail.com
I'm also experiencing this issue using Navigation Compose 2.8.3
It also happens with the default animation with null transition arguments. Sometimes it just animates through scale in.
pr...@gmail.com
Likely this is the same issue as
al...@gmail.com
cl...@gmail.com
I'm still experiencing this issue in my app as of version 2.8.4. Seemingly at random I'll see a scale animation from the top left instead of my custom one.
Feel free to reference it here:
ap...@google.com
Project: platform/frameworks/support
Branch: androidx-main
Author: Jeremy Woods <
Link:
Stop incorrect scaling animation when using NavHost
Expand for full commit details
Stop incorrect scaling animation when using NavHost
There is a case where if you can trigger a navigate call right before the
LaunchEffect that is responsible for managing the end of the
AnimatedContent's transition is called, you will get an incorrect scale
animation.
The reason for this is that the call to navigate adds the proper entries
to the visibleEntries list and then the LaunchedEffect immediately
remove it. Then when the AnimatedContent attempts to find this removed
entry it is not there and AnimatedContent thinks it is animated from
nothing and just scales from a blank screen.
Since this is an interrupt case the the AnimatedContent has not actually
finsihed with transition, we should not be hitting the `LaunchedEffect`
and marking the transition complete at all, but that needs to be
addressed by the Animation library so this change provides a workaround
in the mean time that just keeps from incorrectly marking the visible
entry's transition as complete.
RelNote: "Added a workaround to fix an issue that caused an unexpected
scale animation when using Navigation Compose."
Test: tested in sample app
Bug: 353294030
Change-Id: I26cb142affb046e94b34b9501e5405ddcf276fcf
Files:
- M
navigation/navigation-compose/src/main/java/androidx/navigation/compose/NavHost.kt
Hash: c270d4e53585ab6033d53a2eef1f5327da39e20d
Date: Thu Dec 05 23:09:52 2024
ap...@google.com
Project: platform/frameworks/support
Branch: androidx-main
Author: Jeremy Woods <
Link:
Avoid race condition for transitions in NavHost
Expand for full commit details
Avoid race condition for transitions in NavHost
This is cleaning up the code added in aosp/3393408. The issue is caused
by a race condition where the previous animation has ended but the
current animation has yet to start because `animateTo` is still waiting
to acquire the `mutatorMutex`.
We need to verify that what `AnimatedContent` believes is the
`targetState` is the same thing that is on top of the back stack before
we mark the entries as complete.
RelNote: "Fix an issue that caused an unexpected scale animation when
using Navigation Compose."
Test: tested extensively in sample app
Bug: 353294030
Change-Id: I480f4d89ffc7e2dfa536a592a8fc7b6c759be1a4
Files:
- M
navigation/navigation-compose/src/main/java/androidx/navigation/compose/NavHost.kt
Hash: 4fbe698e1ff01037c6ed1a74538c0c1628ac1730
Date: Fri Dec 06 01:10:47 2024
jb...@google.com
This has been fixed internally and will be available in the Navigation 2.8.5 release.
pr...@google.com
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.navigation:navigation-compose:2.8.5
cl...@gmail.com
Seems solid on my end
na...@google.com
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.navigation:navigation-compose:2.9.0-alpha05
Description
Component used: Navigation Compose
Version used: 2.8.0-beta05
Devices/Android versions reproduced on: Emulators, Pixel 8 Pro
Hello!
We occasionally encounter an issue where the NavHost randomly applies a default transition animation instead of the one specified for a particular composable/route. Please take a look at the sample project and screen recording I've attached. Even though composable<DefaultRoute> consistently defines slideInHorizontally/slideOutHorizontally transitions, you may sometimes observe a scale/fade animation instead. This bug is inconsistent and may require multiple attempts to reproduce. One observation is that this issue occurs more frequently when a new transition is requested just as the enter animation of a previous one is nearing completion.
Sample project:https://github.com/smelfungus/NavHostAnimationIssue
Screen recording:https://drive.google.com/file/d/1FPZavURTkuPmnAWJ49pFhIWvz3Qq-M7x/view?usp=sharing