Add x,y coordinate support for swipe action

[noomorph]

• This change has been discussed in issue Add offsetPositionX and offsetPositionY to swipe(direction, speed, percentage) #2428 and the solution has been agreed upon with maintainers.
• JS native implementation
• iOS native implementation
• Android native implementation
• Fix code review comments
• Ensure consistent parameter naming
• Add a few more tests for various fast=true/false, startPointX/Y=NaN/something, offset=NaN/0/0.5/1 tests
• Re-cover Android implementation with unit-tests

---

Description:

Signature:

/*
 * @param { 'up' | 'down' | 'left' | 'right' } direction - Direction to swipe
 * @param { 'fast' | 'slow' } speed
 * @param {number} [normalizedSwipeOffset] - swipe amount relative to the screen width/height
 * @param {number} [normalizedStartingPointX] - X coordinate of swipe starting point, relative to the view width
 * @param {number} [normalizedStartingPointY] - Y coordinate of swipe starting point, relative to the view height
 */
function swipe(direction, speed, normalizedSwipeOffset = NaN, normalizedStartingPointX = NaN, normalizedStartingPointY = NaN) { ... }

Usage:

await element(by.id('ScrollView161')).swipe('up');
await element(by.id('ScrollView161')).swipe('down', 'slow');
await element(by.id('ScrollView161')).swipe('left', 'fast', 0.95);
await element(by.id('ScrollView161')).swipe('right', 'slow', NaN, 0.3);
await element(by.id('ScrollView161')).swipe('up', 'fast', undefined, 0.5, 0.95);

[LeoNatan]

Implemented on iOS. Is this iOS only for now or will @d4vidi add impl for Android as well?

[d4vidi]

I can get to it soon, should be fairly ez to set up

[LeoNatan]

Great, thanks! @d4vidi

[noomorph]

@d4vidi, @LeoNatan, need your advice regarding the swiped amount.

Look at the difference between the current iOS and Android implementations.

This happens because I calculate on Android the end coordinate not relative to the screen, but relative to the element itself. I have done that not really on purpose, just I was trying to follow the logic in the current Android implementation, and ended up in the place where I am.

So, iOS and Android behavior here differs. What would be more correct behavior, what do you think?

[LeoNatan]

That's how it was on iOS too, but according to feedback, it had to be in screen coords. CC @viktorijasujetaite

[noomorph]

@LeoNatan, thanks. I've been suspecting something like that. 😳
Ok, will rewrite the logic on Monday, apparently.

[LeoNatan]

How was it before your changes? The Espresso swipe…?

[LeoNatan]

If you need to write your own logic for the start and end points, you can copy the logic from the iOS side. The logic should be the same.

[d4vidi]

@noomorph I agree with @LeoNatan - swiping has to start somewhere inside the view bounds, but end as farther away as the screen allows it.

[d4vidi]

Well @noomorph I'm sort of done reviewing this, for now - seems there's a lot to go over for now, so let's reiterate this when the time is right

[noomorph]

@d4vidi , @LeoNatan

Now the implementations feel aligned, right?

[d4vidi]

@noomorph amazing work overall! I hope you don't mind me nitpicking here and there 😂 Anyways it's mostly naming that bothered me in my way of understanding the code, so most comments are in that area. Other than that seem pretty good!

[d4vidi]

Nice work! It's great to see how eventually you've used the generic algebric constructs to calculate both the absolute and normalized starting point, and better yet - the ending point.