Status Update
Comments
to...@gmail.com <to...@gmail.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
to...@gmail.com <to...@gmail.com> #3
ti...@google.com <ti...@google.com>
to...@gmail.com <to...@gmail.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
to...@gmail.com <to...@gmail.com> #5
If I add a .fillMaxSize()
to the modifier of the AnimatedContent
then the animation is different see video but also there's no more onSizeChanged
called just a single
2024-10-15 10:37:18.070 26417-26417 TAG app.symfonik.music.player.debug E ScreenTransition:1440 x 2812
for first render.
AnimatedContent(
targetState = navigator.lastItem,
transitionSpec = transition,
modifier = modifier.onSizeChanged {
Log.e("TAG", "ScreenTransition:$it ")
}.fillMaxSize(),
label = "",
) { screen ->
navigator.saveableState("transition", screen) {
content(screen)
}
}
to...@gmail.com <to...@gmail.com> #6
So after doing a tons of tests and removal and everything, the source cause is state restoration of the AnimatedContent
. When the state is restored, the internal state of AnimatedContent
is wrong. I suppose some things are remembered and not the others needed to go with it.
To solve this I just need to disable state saving / restoring in the tab navigator and then it works.
With that said I'll try to build a repro project now that I have the source issue.
to...@gmail.com <to...@gmail.com> #7
And here's an ugly quick repro attached (Requires latest AS canary by default)
Press toggle multiple times and see it works.
Press go next then go previous
Press toggle and see that it fails.
ti...@google.com <ti...@google.com> #8
Quick update:
I was able to repro and investigate the issue. It is indeed related to how the save and restore is set up. What I am seeing is the size change animation is accessing a stale AnimatedContentTransitionScope
instance and therefore it operates on the wrong info.
Now I'm in the process to create a minimal repro that can be added to the test to verify a potential fix.
ap...@google.com <ap...@google.com> #9
Project: platform/frameworks/support
Branch: androidx-main
Author: Doris Liu <
Link:
Update SizeAnimation internal state when transition is recreated
Expand for full commit details
Update SizeAnimation internal state when transition is recreated
This change ensures that the size animtion reads the up-to-date
target sizes when AnimatedContent is being
re-used for different transitions.
Test: New tests added
Bug: 372512085
Change-Id: I7b0569287fb5e7e59be5226d827fdbcf90e46733
Files:
- M
compose/animation/animation/src/androidInstrumentedTest/kotlin/androidx/compose/animation/AnimatedContentTest.kt
- M
compose/animation/animation/src/commonMain/kotlin/androidx/compose/animation/AnimatedContent.kt
Hash: 8a597f07a0b80ebeede28f5d2a0887820ff92bb0
Date: Wed Oct 16 16:56:24 2024
ti...@google.com <ti...@google.com> #10
Verified the fix above with repro in
to...@gmail.com <to...@gmail.com> #11
Can confirm it's fixed in my main app too.
pr...@google.com <pr...@google.com> #12
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.compose.animation:animation:1.8.0-alpha05
androidx.compose.animation:animation-android:1.8.0-alpha05
androidx.compose.animation:animation-jvmstubs:1.8.0-alpha05
androidx.compose.animation:animation-linuxx64stubs:1.8.0-alpha05
Description
Jetpack Compose version: 1.8 snapshots starting with 12408595 (So included in alpha03)
I unfortunately have some trouble to build a small repro but that commit broke transitions handled by
AnimatedContent
in my app.See attached video.
There's also some details in slack in a thread with Doris.
To resume, there's some size resolution issues when removing and adding back screens that makes the
AnimatedContent
wrongly detect a size change and doing wrong size animations.You can see in the video that the fade transition does work, then when switching screen then going back it no more work correctly and animate the size for no reasons.
Forcing
.using(null)
does workaround the issue.When reaching the broken state, if both contents of
AnimatedContent
are boxes with.fillMaxSize()
then it just shows a black screen as is it was animating from 0 to 0 size. If one of the content does not have the.fillMaxSize()
then it leads to the size animations you can see in the video.