Status Update
Comments
mi...@google.com <mi...@google.com>
ja...@tstllc.net <ja...@tstllc.net> #2
Hi, thanks for reporting this. For now this is expected as nested scrolling is only activated through gesture based scrolling, not animation based scrolling. We do have plans to explore animation based nested scrolling in the future, so I'll keep you posted if things change. Closing this ticket for now as this is WAI.
iv...@google.com <iv...@google.com>
st...@google.com <st...@google.com>
ar...@google.com <ar...@google.com>
mu...@gmail.com <mu...@gmail.com> #3
Is there a ticket to follow?
el...@gmail.com <el...@gmail.com> #4
va...@google.com <va...@google.com> #5
Can we add a ticket for animation based nested scrolling? So it can at least be tracked publicly.
Its not possible to workaround this when the nestedScroll(connection, null)
modifier is hidden deep in 3rd party code.
Also it sort of weird too as one needs to manually call all nested scroll methods (pre & post scroll) & actual component scrolling methods, effectively reimplementing ScrollingLogic
, somewhat.
ni...@gmail.com <ni...@gmail.com> #6
ni...@gmail.com <ni...@gmail.com> #7
nestedScrollConnection.onPreScroll(
Offset(0f, with(localDensity) {
val scrollDistance = -(scroll.value)
println("scroll distance: $scrollDistance")
scrollDistance.toPx()
}
),
NestedScrollSource.UserInput
)
It scrolls partially on the first time, and it scrolls completely on second time, so I had to call it twice.
ma...@travtech.com <ma...@travtech.com> #8
mi...@google.com <mi...@google.com> #9
We greatly appreciate your patience.
The ability to search for places matching multiple places is now available in
includedTypes
,
or one or more includedPrimaryTypes
to match places on their
excludedTypes
or excludedPrimaryTypes
.
The new API also adds supports for
We believe this issue is now fixed, hence marking it as such.
Thanks for working with us!
Description
-----------------------
What would you like to see us add to this API?
Based on the Feb 2016 announcement [1], "types" restriction parameter was replaced with a new type search parameter. Users may opt to remove the "type" parameter but it doesn't guarantee that the desired places' types will be returned (some if not all of the results are unwanted). Either the user would do client-side filtering and make multiple API calls. The user is hoping that the API would still allow multiple "types" parameter in Places Search request for efficiency purposes.
Issue report
----------------
What steps will reproduce the problem? Please provide a link to a
demonstration page if at all possible, or attach code.
1.
2. nearby restaurant and spa types will not be returned
[1]