This is a behavior of stop points that seems to be wrong.
Snapping stop points always acts when you release the finger in a ‘no-fling’ state even when the direction of the scrolling is different to the matching direction.
It is difficult to understand, so here are instructions.
In a desktop where you can scroll in the four directions place a stop point in the right second screen. Enable the snapping. Optionally but better to understand the bug, set it to react to the right side and only to right-to-left direction (and desktop-wide recommended)
If you are in the origin position and scroll up and down, when you release the finger you can:
a) release it while fling: the desktop will continue scrolling up or down a bit and will stop. All ok.
b) release it in a stopped position: if you move the finger up and down, then you stop it, and release it in this ‘stopped’ state, the desktop will scroll to the right: the stop point is acting, and it is supposed to not do it.
[If you need a video tell me]
I guess the bug is because when you release the finger and the launcher search for a snapping stop point, it takes only the current velocity of scrolling, and not the previous one. It is understandable because if you instead scrolled horizontally and released the finger in the stopped state the stop point will need to act, but only if the last previous movement the finger where moving right-to-left. Now it also acts if you scroll a bit to the left, stop the finger and then release the finger.
An even more funny behavior: if you have another stop point at the bottom, both will act scrolling the screen diagonally. If you have another at the left, one of those will act (I think the nearest one)
So, instead of only decide if a snapping stop point need to act or not, instead of decide it only with the current scrolling velocity, you will need to keep a variable with the last non-zero one and use that instead if the current one is zero.
In my opinion.
]]>
D5 Creation
< ![CDATA[
I understand the issue.
I would describe it differently: the snapping stop point direction is not taken into account while looking for a matching stop point. It should be compared with the global finger direction (from the point where the finger touches the screen to the point where it leaves the screen).
I am not sure about diagonal scrolling due to several stop points, that’s a bit weird 🙁
]]>
< ![CDATA[
I think it’s better the ‘delta position’ (if android have something similar), I mean the last non-zero vector of the movements. Using the global position can lead to strange things if you start at the right, scroll left, scroll right a smaller distance and release the finger without fling. It will move to the left instead of the right (ok, perhaps this is too specific to be an issue) This happen only when the fling velocity at release is 0, so I guess it is because you have a if(vel.x>=0&&vel.y==0) so vel.x=vel.y=0 trigger it too. I guess that if it were instead vel.x>0 releasing the finger in the 0-velocity won’t trigger any snapping.
And yes, it is taking into account the direction because if you disable all directions, the stop point never acts (or you have a specific code to disable a stop point without directions)
The diagonal scrolling is just that, because of this bug, both stop points act: the right one and the left one. This makes the screen to move diagonally to match both simultaneously.
]]>