forgive my sarcasm but do I need a PhD to understa...
# compose
h
forgive my sarcasm but do I need a PhD to understand how to implement a custom gesture detector? It's nice that there is a selection of gesture detectors pre-defined under
pointerInput
but when I tried implementing my own, I got totally lost. My first try was a quick failure because predefined detectors consume the events so they cannot be used together. On my second attempt, I tried to write my own detector with lower level
await
calls and got confused so hard. Is there a documentation that would shine even a little light on this API?
d
Have a look at this code I wrote. I'm not very experienced with compose, so no guarantees I do things the "right way". But the code works well, so... https://github.com/danielzfranklin/librereader/blob/main/android/app/src/main/java[…]ibrereader/ui/screen/reader/paginatedText/selectablePageText.kt
The main technique I used was using Ctrl-Alt-B in Android Studio to jump to the source of functions that did nearly what I wanted and copy-pasting the code into my own project (with a comment clarifying I didn't write the code myself). Then I copied over any private/internal functions that the code required to work, and started modifying it. @Halil Ozercan
2
If you post what you're working on I may be able to give you some more specific advice
v
Yeah, it would be nice if we could combine predefined detectors to assemble more complex gestures (I wrote about that a couple months ago). I did the same thing as Daniel but when library updates, I always have to sync my sources with library’s. Maybe we should file an issue about that?
d
I [filed a bug](https://issuetracker.google.com/issues/181577176) about that a few days ago @Vsevolod Ganin, and was told that in general this is expected behavior but we can ask for specific hard to make building blocks to be opened up. I suppose you don't have to sync unless the library fixes a bug? But letting a big gap form might end up biting me...
v
Lol I wrote about private
awaitLongPressOrCancellation
here in slack not long ago too! 🙂 Please file an issue to make it public if you don’t mind, I’ll definitely star it!
I suppose you don’t have to sync unless the library fixes a bug? But letting a big gap form might end up biting me...
Yeah it mainly applied to alpha stages when APIs were changing rapidly. Now when it’s beta and there shouldn’t be any public API changes so you shouldn’t sync as much now. If we need something private from library then we file an issue I guess.
z
the real wonder is that whenever you do
Modifier.pointerInput {
they always open a random dangling
coroutineScope {
in it and so I'd say yes, you do need a Ph.D 🤔 a BSc is not enough to get it (fact)
d
are you referring to the fact PointerInputScope is suspend but doesn't implement CoroutineScope?
z
Yes
👍 1
d
To be honest coroutineScope feels a bit magic to me, but I blame JetBrains for that one
h
Finally I understood the magic behind coroutineScopes and suspend functions in this API when I read the documentation for
awaitPointerEventScope
More than one awaitPointerEventScope can run concurrently in the same PointerInputScope by using kotlinx.coroutines.launch. blocks are dispatched to in the order in which they were installed.
So I can actually make a single pointerInput scope to wait for different gestures at the same time
d
Yeah, the part that gets me is where does the coroutineContext come from? It feels sorta lika CompositionLocals
That becomes tricky @Halil Ozercan if your different gestures interact with each other in more complex ways. At that point it can be nicer to have one block with a bunch of the suspending lower level building blocks instead of a bunch of different blocks all running at once
h
@Daniel I also had that feeling. Concurrently checking for different gestures feels dangerous. However, it is way harder for me to figure out each small detail in a composite gesture detector
d
That's totally fair, I started off with multiple gesture detectors and then refactored to one once it got a bit more complex