What would be the best way to implement dragging an element from one composable to another? I know t...

# compose

[Arjan van Wieringen]

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.

[dewildte]

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/

[dewildte]

I am thinking the mediator pattern would be a key pattern in making this work.

[Arjan van Wieringen]

Awesome thanks!

[Chris Sinco [G]]

@Zach Klippenstein (he/him) [MOD] didn’t you have a demo of this before with foundation APIs?

[Zach Klippenstein (he/him) [MOD]]

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.

[dewildte]

Oh man reading this list of things to get done here really helps us understand
the complexity that goes into a feature like this.

[Zach Klippenstein (he/him) [MOD]]

Nothing can be simple 😅

[dewildte]

Do you guys add doc strings after you're done building the feature?

[Zach Klippenstein (he/him) [MOD]]

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.

[dewildte]

Yeah sorry I was looking at Kdoc

[dewildte]

I didn't know that was auto-generated?

[Zach Klippenstein (he/him) [MOD]]

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.

[dewildte]

Oh sorry I see you actually did put some documentation in some of the other areas like one of them has an @param doc

[dewildte]

It's interesting to me to see how Googlers write stuff.

[dewildte]

Gosh that voice dictation always gets me.

[Zach Klippenstein (he/him) [MOD]]

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.

[dewildte]

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.

[Zach Klippenstein (he/him) [MOD]]

Exactly. Mostly just notes-to-self if something was tricky or unintuitive so I don’t forget

[Arjan van Wieringen]

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.

[dewildte]

I was going to with a global registry approach.
Each draggable and drop target register themselves to send and receive the drag events.

[Arjan van Wieringen]

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?