fix touch handling (pragmatic approach)

[michaelknoch]

This reverts commit 9a698b9.

Type of change: fix broken loop handles

Motivation (current vs expected behavior)

Reverting 9a698b9 leads to the exact same behaviour as we have on the latest commit of the fix-touch branch.

This commit introduces the behaviour that touchesEnded gets (maybe correctly?) cancelled, but touchesBegan does not. Thats why in our player we see that the all controls get hidden when dragging a loop handle, but they never come back on touchesEnded.

https://record.wtf/play?id=1638181427736_46106

reproduce:

• opens song
• open loop
• drag any of the handles to adjust the loop

Please check if the PR fulfills these requirements

• Self-review: I am confident this is the simplest and clearest way to achieve the expected behaviour
• There are no dependencies on other PRs or I have linked dependencies through Zenhub
• The commit messages are clean and understandable
• Tests for the changes have been added (for bug fixes / features)

[michaelknoch]

I think reverting the commit and then iterating on touch handling again makes more sense instead of relying on the fix-touch branch for our app releases. @ephemer @rikner

[rikner]

Do I understandly correctly, that 9a698b9 was intended to be a refactor without any behaviour change, but it indeed changed the behaviour? Would totally make sense then to revert it and re-iterating again on the touch handling.

[michaelknoch]

hard to say @rikner . I can't see a pr for this, seems like it was commited to master directly without description or motivation. I think we tried to align the cancels behaviour with iOS, because this is slightly different. On android the draghandles disappear while dragging, on iOS they don't. And this is probably what he intended to fix, but now only touchesBegan and moved gets called and touchesEnded gets cancelled which leads to the weird UX where the main controls remain hidden after dragging.

[ephemer]

If we're currently releasing from a branch then we should merge this to avoid that. I fear we may break others' code doing this but so far no one has made us aware that they're using this in production so let's go for it for now

[michaelknoch]

i think having a consistent behaviour between touchesBegan and touchesEnded is probably more beneficial for every project using UIKit. I'm happy to work on a fix asap as soon as someone opens an issue ;)

[michaelknoch]

ok never mind, merging this pr breaks scrolling through the exercise parts menu in our courses. It's new to me that this commit behaves differently than the last commit of fix-touch #333

I am closing this now and will re-iterate on the fix-touch branch to get it in as soon as possible. sorry for the noise @rikner @ephemer