-
Previously we used a bunch of heuristics for this. We checked if velocity was directed towards the nearest snap point and its value was larger than a threshold. If it is, we completed the swipe, otherwise we cancelled it. This was good enough at the time, because this code was originally written for back/forward swipe. Since then, the swipe tracker was extended to handle arbitrary snap points and not just 0 and 1, or -1 and 0, depending on text direction. After that it was iterated on, but never significantly redone. This worked well enough, but had two problems: 1. In some cases, notably for AdwCarousel with non-expanded pages, it may be wanted to be able to swipe through multiple pages at once. This wasn't really possible because we always picked the adjacent snap point. 2. Since we can't do that well, we want to restrict swipes to one page at a time. It was done in a rather hacky way by clamping the position into [-1, 1] range from the place where we started the swipe. This works if we start the swipe from idle position, but if an animation was already going, the range would be clamped to arbitrary values, and very likely containing only one snap point, which we already swiped past at this point. In this case, finishing the swipe would cancel it regardless of velocity. This means that if one tries to quickly move through carousel pages via swiping, half of the swipes will be inexplicably cancelled. We'll use the deceleration formula from https://medium.com/@esskeetit/how-uiscrollview-works-e418adc47060#10ce to calculate then projection point, then pick the nearest snap point and calculate the duration as we did before. It works well enough for short distances, but has two problems: 1. It caps the maximum distance at a pretty low value - about 5 pages in my testing. 2. With how we pick the nearest snap point, it's too easy to accidentally cancel the swipe, To combat the first problem, we can modify the curve: only use linear function at small distances, and smoothly transition it to a parabola further. For the second problem we can add two special cases: first, if the swipe ended up between the initial snap point and the next one, we always prefer the latter. Second, a good old velocity threshold for cancelling. We'll also use a slightly smaller deceleration value for touchpad: 0.997 instead of 0.998. Now that we can pick any snap point, the [-1, 1] clamping doesn't make sense anymore, so instead let's replace it with a more flexible mechanism: if we're near a snap point, pick its adjacent snap points. Otherwise, take the two nearest snap points, and take their adjacent snap points. This way we have 3 snap points to choose from when starting a swipe from an idle position, and 4 if we start during an ongoing transition. This way, if we've just swiped from snap point n to n+1, the transition will pick snap points n-1, n, n+1, n+2 and if we swipe again, we will likely land on n+2. During that transition, if we swipe again, it will likely have already passed the snap point n+1, so this time the available snap points will be n, n+1, n+2, n+3, so we can swipe again and it will still complete, and so on. This will make it easy to allow multi-page swipes as well, by just removing the clamping.
fff1ad51
