https://kotlinlang.org logo
Join Slack
Powered by
What would be the best way to implement dragging a...
# compose
a
What would be the best way to implement dragging an element from one composable to another? I know this sounds vague but I am interested in a high level idea. I am investigating how to do it and the best idea I can come up with will involve a lot of LayoutCoordinates work. I think I need a 3rd composable that spans the other two to handle the crossover and to the screen to local and vice versa calculations.
d
Bunch of articles with people doing this. I think Microsoft has a gradle lib for it: https://devblogs.microsoft.com/surface-duo/jetpack-compose-drag-and-drop/
I am thinking the mediator pattern would be a key pattern in making this work.
a
Awesome thanks!
c
@Zach Klippenstein (he/him) [MOD] didn’t you have a demo of this before with foundation APIs?
z
Not really, it relied on a change to AndroidComposeView - but that might be something we could replace with the androidx library? I can’t remember why I didn’t do that. I think to do this well we’d also need support in the foundation scrollable modifiers. Anyway, this was the CL.
d
Oh man reading this list of things to get done here really helps us understand the complexity that goes into a feature like this.
z
Nothing can be simple 😅
d
Do you guys add doc strings after you're done building the feature?
z
What docs do you mean? Release notes are included in commits. Kdoc is generated from code as part of the release (or slightly after? I don’t actually know). Higher-level doc articles are usually written later.
d
Yeah sorry I was looking at Kdoc
I didn't know that was auto-generated?
z
Tbh I’m not sure if it’s autogenerated or if the person driving the release has to manually kick it off, but it’s part of the process either way.
d
Oh sorry I see you actually did put some documentation in some of the other areas like one of them has an @param doc
It's interesting to me to see how Googlers write stuff.
Gosh that voice dictation always gets me.
z
I try to document my PoC CLs, but it’s probably missing quite a bit. I’d flesh it out a lot if we got closer to merging it.
d
Yeah there's probably no point in adding a ton of documentation if you don't even know if stuff is going to be deleted or finalized or not.
z
Exactly. Mostly just notes-to-self if something was tricky or unintuitive so I don’t forget
a
Nice to see that it isn't very trivial, as I thought. I managed to implement it correctly now by some use of: • layoutCoordinates in both the source and target components • a parent component which does the heavy lifting be doing quite some 
layoutCoordinates.localPositionOf(....)
stuffs. This is a pretty specialized solution, so not general at all. I can imagine that making a general solution is way more difficult. One important thing for me in this case was for the source, target, and parent components to have clear state-objects which contain helper functions and state which can communicate with each other.
d
I was going to with a global registry approach. Each draggable and drop target register themselves to send and receive the drag events.
a
Interesting, would be very interested to know how that would work. And how do you handle a use case where the draggable needs to travel between the drag and drop target and they aren’t close together?
10 Views
Open in Slack
PreviousNext
Powered by