Status Update
Comments
jn...@google.com <jn...@google.com>
st...@google.com <st...@google.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
st...@google.com <st...@google.com>
ap...@google.com <ap...@google.com> #3
mk...@google.com <mk...@google.com>
jo...@gmail.com <jo...@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
yi...@googlemail.com <yi...@googlemail.com> #5
Can we please open this issue again?
I have the same issue with an AndroidView
for MPAndroidChart
lineChart view to consume drag
event inside a SwipeDismissableNavHost
.
The edgeSwipeToDismiss
works with scroll
modifier, but not on any composable such as AndroidView
, which shall really be able to consume any touch event inside a SwipeDismissableNavHost. If not, it would be pointless to use compose navigation at all with AndoidView
.
I can use a hack to disable swipe event for any composable, but then the most PointerInput
related to drag are difficult to detect, which makes the underline AndroidView
lineChart feels laggy to drag along
/**
* Override a composable to be unswipeable by blocking the swipe-to-dismiss gesture.
*
* When a composable is on top of another composable that supports swipe-to-dismiss,
* then [Modifier.unswipeable] can be applied to the top composable to handle and ignore
* the swipe gesture. For example, this may be used to prevent swiping away a dialog.
*/
public fun Modifier.unswipeable() =
this.then(
Modifier.draggable(
orientation = Orientation.Horizontal,
enabled = true,
state = DraggableState {}
)
)
It would be really great if, the edgeSwipeToDismiss
can also work on any composable, or the swipe back event on SwipeDismissableNavHost
can be disabled individually for a child composable of SwipeDismissableNavHost
mk...@google.com <mk...@google.com> #6
Hi Yingding,
Can you please share the code example regarding that issue? What exactly you're trying to make work? How MPAndroidChart
is added and where are SwipeDismissableNavHost
and edgeSwipeToDismiss
in it?
Thanks!
yi...@googlemail.com <yi...@googlemail.com> #7
Reply to #6
Hi Mikhail, I created a demo repo for the MPAndroidChart
inside AndroidView
(
Please find the demo video showing the edgeSwipeToDismiss
doesn't work on AndroidView
under this link
I want to show multiple LineChart Graphs with MPAndroidChart
, which are horizontally scrollable. The drag and scroll event is handled by the view system code from the AndroidView
, so that all the drag event shall be passed to the AndroidView
without being consumed by the parent SwipeDismissableNavHost
.
You shall be able to run the code from my sample repo directly and see this effect on the emulator.
I will be glad to answer any further of your questions. I am seeking a way to tell the SwipeDismisableNavHost
shall not consume drag event for the AndroidView
, the unswipeable
hack gives currently partial success. It would be great, that the edgeSwipeToDismiss
modifier can work on any composable.
mk...@google.com <mk...@google.com> #8
Thanks for the demo! So I see that sometimes scroll works, sometimes doesn't . When I remove .unswipeable and .edgeSwipe modifiers, I still able to scroll graphs in some cases- like a long hold and drag - then they start working. I think the problem here is with touch events, that they are not properly handled in Views and Compose worlds if used together
yi...@googlemail.com <yi...@googlemail.com> #9
reply to #8
I don't think so, if you try the GraphsScreenPreview
in GraphsScreen.kt
in interactive mode and remove the unswipeable
and edgeSwipeToDismiss
, the touch event works fine.
The Preview
tool works, since it is not wrapped inside SwipeDismisableNavHost
, which intercepts the drag events. My code shall work if it is not used with SwipeDismisableNavHost
. I am just curious, what happens here.
yi...@googlemail.com <yi...@googlemail.com> #10
Probably the handling of touch events in both view and compose world also contributes to this complex issue :(
yi...@googlemail.com <yi...@googlemail.com> #11
Kindly asking if there is any update on making edgeSwipeToDismiss supporting "AndroidView" composable?
- I am wondering whether, #5
unswipeable()
is the official solution for disableSwipeToDismiss
. - Whether the associated root cause stated by #8 that
AndroidView not receiving proper touch events
from is still present for170320973 AndroidView
associated withSwipeToDismissBox
. Does the touch event issue need to be dealt by the developer forAndroidView
individually or the compose framework can help?
st...@google.com <st...@google.com> #12
We have submitted a fix to
Description
Component used: SwipeToDismissBox Version used: 1.0.0-alpha06 Devices/Android versions reproduced on:
Thehttps://developer.android.com/training/wearables/overlays/exit#horizontal-scroll
SwipeDismissFrameLayout
solves this, and the problem is explained here:If this is already possible using thresholds or something in Compose, I'd be happy to see some documentation for this particular use case.