Status Update
No update yet.
Comments
ma...@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
sa...@squareup.com
sa...@squareup.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
ma...@google.com
Yeah I think I was mistaken suggesting this as it will indeed flip back and forth, because that's the contract of the isTransformationInProgress. In fact, seems like you need an indication of the
I think what we should do is to add InteractionSource to the state, so that you can query specifically the Drag interaction and launch against its change. Louis, wdyt?
lp...@google.com
Yeah makes sense to add InteractionSource integration here, same as for things like ScrollState
sa...@squareup.com
Will DragInteraction be sufficient for querying fling velocity? I'm trying to think how would this work w.r.t nested scrolling.
lp...@google.com
Nope, there won't be a way to get that kind of information currently, and I don't think DragInteraction is the correct place for that sort of thing. If you specifically need velocity, I guess we need a specific callback / build your own implementation where you can reference this directly
sa...@saket.me
A callback would be great for compatibility with nested scrolling.
sa...@saket.me
On a second thought, a callback alone wouldn't be sufficient for enabling nested scrolling. Modifier.transformable() consumes all events by default even if its content can't pan any further, preventing scrollable parents from showing overscroll effects. I can file a separate issue for that if you want.
lp...@google.com
Ah I see, yes please file a separate bug. Probably transformable should just implement nested scrolling directly - if it did do that, would you still have a need to figure out the fling velocity on end?
sa...@squareup.com
If transformable can support nested scrolling, that'd be the best!
sa...@squareup.com
Modifier.transformable() consumes all events by default even if its content can't pan any further, preventing scrollable parents from showing overscroll effects
Am I understanding it correctly that
sa...@squareup.com
On a second thought, the new canPan parameter isn't sufficient. It needs to also provide the pan delta so that consumers can decide if content can be panned in the gesture direction.
lp...@google.com
ma...@google.com
Main usecase we covered with this API is the ability to disable pan based on some external state (e.g. cumulative scale or rotataion or something else). It is not clear why you would want to decide on wether to pan or not based on the direction of the pan delta.
I understand your usecase, but this API is not intended to substitute nested scroll-like abilities
sa...@saket.me
If my content in a pager is zoomed in, but is also panned to the edge, is there a better way to return false from canPan? The documentation of canPan recommends using scale > 1f but that may not be something that all apps use.
While I understand that this is leaking into nested scrolling, nested scrolling can't be used for 2d scrolling yet.
ma...@google.com
Hmm, I see. The thing is that I don't think it will be possible to control the consumption of the events once you started the panning, e.g. if you are at the bound of the zoomed picture and the pointer goes down - providing delta will cover this case, but not when you reach the bound with the finger already down.
The only real way to make this change correctly is the nested scroll dispatch.
sa...@saket.me
e.g. if you are at the bound of the zoomed picture and the pointer goes down - providing delta will cover this case, but not when you reach the bound with the finger already down.
That sounds perfectly fine! Can I ask you to try out this experience using telephoto's sample on your phone?
ma...@google.com
I see what you mean, that does make sense from the UX perspective. I see that in general it can be beneficial to have this info anyway, I will add Offset to canPan to help with that.
sa...@squareup.com
Yay thank you!
ap...@google.com
Branch: androidx-main
commit 6bcc8c148ecd1cb13f48ea2fab0582731f44daf6
Author: malkov <malkov@google.com>
Date: Fri May 19 15:37:10 2023
Add pan change Offset to canPan parameter in transformable to help make informed decision on pan start.
Since the addition of canPan parameter in transformable, it made sense to add pan delta to this callback to help making informated decisions, e.g. when zoomed image is panned to the bound it is important to understand the direction of the pan. Providing pan delta helps to deternime this.
Relnote: Modifier.transformable now provides pan delta in canPan parameter to help determine the direction of the pan to allow or disallow it.
Test: added new
Fixes: 266829800
Change-Id: I692aa5bf43084658ca6a20175869d9d593986f2b
M compose/foundation/foundation/api/current.txt
M compose/foundation/foundation/api/restricted_current.txt
M compose/foundation/foundation/src/androidAndroidTest/kotlin/androidx/compose/foundation/TransformableTest.kt
M compose/foundation/foundation/src/commonMain/kotlin/androidx/compose/foundation/gestures/Transformable.kt
sa...@squareup.com
Hey folks, can this issue be reopened again?
ma...@google.com
My bad, reopening and reassigning to the tracking hotlist to address in the future work
Description
I'm investigating if
Modifier#transformable()can be used for a photo viewer screen. When a gesture ends, I'd like to reset the transformations if needed. For example, if the content is zoomed below< 1f, it'll be scaled back1f.I'm currently doing this by adding another
pointerInput(Unit)modifier aftertransformable():Do you think this looks good enough? Or should
transformable()offer start & end hooks if it offers any benefit?