Sergey Y.
09/03/2020, 10:45 AMAdam Powell
09/03/2020, 1:18 PMlouiscad
09/04/2020, 10:09 AMandroid.view.View
) and other changes like text changes in a text input field.
Have you explored this to provide an alternative to the callbacks passing that compose currently has?Adam Powell
09/04/2020, 1:56 PMwithFrameNanos
function as the lowest level suspending animation primitiverememberCoroutineScope
and launchInComposition
configure the dispatcher and frame clock to assist in supporting all of this such that you can act on the same frame input arrives before composition occurs in responselouiscad
09/04/2020, 2:01 PMan onClick is an instantaneous event that doesn't benefit from suspendRight now, I benefit from it because calling
awaitOneClick()
enables the target View
to be clickable, which reflects that state visually, and once clicked, it becomes disabled again (unless enabled back), preventing the infamous double click double processing issue, and signaling the user that his action has been taken into account.
That's why I disagree with your statement that I just quoted 🙂Adam Powell
09/04/2020, 2:04 PMlouiscad
09/04/2020, 2:05 PMReversing that layering and treating an awaitClick as the primitive gets much more complicatedAgreed
Adam Powell
09/04/2020, 2:06 PMlouiscad
09/04/2020, 2:14 PMIf you wanted such a thing you can create a button composable that accepts a state object with such a method, and your button could call a material button composable with appropriate enabled and onClick parametersCould you write such an example in a gist?
Adam Powell
09/04/2020, 2:15 PMlouiscad
09/04/2020, 2:15 PMThough a slightly different shape in suspending gesture recognition to detect clicks more generally? Probably!You mean it would be possible to replace
onClick
and possible suspending adapter code to raw gesture detection under the hood, made simple with coroutines enabled API, with an even higher level API to detect just clicks?Adam Powell
09/04/2020, 2:27 PMlouiscad
09/04/2020, 2:44 PMAdam Powell
09/04/2020, 2:48 PMlouiscad
09/04/2020, 2:52 PMAdam Powell
09/04/2020, 2:59 PMenabled
parameter to those buttonslouiscad
09/05/2020, 11:38 AMButton
in androidx.compose.material
, and I saw that enabled
makes the button non clickable… why couple the enabled state to the fact that the code can know a button has been clicked?
I mean… I understand that it could be for convenience, but on the other hand, it prevents you to support the following use case aimed at improving UX and user understanding:
The user sees a disabled button and would like to know why that option is not available. Because the UX designers are so user-friendly, an informational text is shown when the button is clicked telling why the button is disabled (e.g. the inputted data is not valid, or the device doesn't have required hardware…).
Right now, it seems it'd need a wrapping click detector to support that use case, making the code significantly more complex when you wanted to improve the UX a little.
Have you though about this in the team, and do you already have an idea of how the API could be designed to support this use case without making the simpler one more complex or more error-prone?Adam Powell
09/05/2020, 2:12 PMButton(
if (enabled) { { doThing() } } else null
)
if (enabled)
logic in their handlers. Most will forget and won't expect they have to. Who writes tests to click their disabled buttons and confirm nothing happened?louiscad
09/05/2020, 3:07 PMModifier
?
If both onClick
and a click modifier are applied, do both get called on click?Adam Powell
09/05/2020, 3:16 PMModifier.clickable {}
. Innermost click modifier wins; it's the same as if you put a button within a larger clickable card layout.