The edit handle seems to have a larger area devoted to it's drag gestures. Is this configurable?... or, is there someway to elegantly allow the choosing of the correct handle when handles overlap? See attached.
My tests indicate that the hit test area is much larger than the circles. Approximation attached.
Hi Caylan,
You are correct, the handles themselves are half the size of the handle. Otherwise, the handles would have to be oversized as their hit targets would have been too small.
So the hit target is actually the size specified of the eitItemHandleSize, and the drawn handle is a half of that and centered within the touch target. I suppose i could make this configurable, however if you make them too small, your users will have trouble dragging them.
Also, off the top of my head i don't have a good solution for detecting one handle over the other, its generally going to choose the one thats on top. The way i had solved this issue in my sample was to double tap and deselect the parent layoutitem
-SteveZ
It would be nice if it were configurable. Additionally, an option to clip-to-bounds equivalent for the hit-test gesture recognizer. Since I have nested flows, I need to make sure overlap is minimized, and that means only recognizing drags from within the view itself. Make sense?
Here's a far-fetched idea. What if the edit handles were aware of each other via the gesture recognizer delegates. And when multiple GRs were encountered to handle the resizes, something magic happens like a new handle with two colors that lets the user choose, or alternatively, perhaps a cycle between which GR handles the next gesture. There has to be some way... I'm spending the morning refactoring how nested flows can behave.
Honestly, I'm not sure how that would work, b/c internally the FlowLayout doesn't know about the existence of a nested flow layout.
I'll try and set some time aside this week to play around with the scenario some more, and I'll let you know if I come up with anything that might work for you.
I came up with a solution. I emailed it to the iOS dev email list. I did not want to post it here. Before you work on it, check out my proposed solution.