New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Refactor setting of touch actions options #756

Closed
wants to merge 3 commits into
base: master
from

Conversation

Projects
None yet
5 participants
@mykola-mokhnach
Contributor

mykola-mokhnach commented Oct 15, 2017

Change list

The idea of this PR is to unify touch action options, so it is easier to extend them.
The main reason for this change was my intension to add pressure argument to press/longPress actions for iOS. With the current implementation the count of overriden methods in TouchAction class would have grown up exponentially.

Types of changes

  • No changes in production code.
  • Bugfix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)

@mykola-mokhnach mykola-mokhnach changed the title from Refactor setting touch actions options to Refactor setting of touch actions options Oct 16, 2017

@appium appium deleted a comment from codacy-bot Oct 16, 2017

@appium appium deleted a comment from codacy-bot Oct 16, 2017

@mykola-mokhnach

This comment has been minimized.

Show comment
Hide comment
@mykola-mokhnach

mykola-mokhnach Oct 16, 2017

Contributor

@KazuCocoa I would be happy to see your feedback on this change. Would it be useful to set action options this way? If yes, then would it be necessary to have something like this implemented for Ruby/Python libs?

Contributor

mykola-mokhnach commented Oct 16, 2017

@KazuCocoa I would be happy to see your feedback on this change. Would it be useful to set action options this way? If yes, then would it be necessary to have something like this implemented for Ruby/Python libs?

@appium appium deleted a comment from codacy-bot Oct 16, 2017

@KazuCocoa

This comment has been minimized.

Show comment
Hide comment
@KazuCocoa

KazuCocoa Oct 17, 2017

Member

looks good for me. 🆗
For Ruby/Python client, it isn't probably necessary for them, but I'd like to consider a bit.

Member

KazuCocoa commented Oct 17, 2017

looks good for me. 🆗
For Ruby/Python client, it isn't probably necessary for them, but I'd like to consider a bit.

@codacy-bot

This comment has been minimized.

Show comment
Hide comment
@codacy-bot

codacy-bot Oct 17, 2017

Codacy Here is an overview of what got changed by this pull request:

Complexity increasing per file
==============================
- src/main/java/io/appium/java_client/TouchAction.java  4
         

See the complete overview on Codacy

codacy-bot commented Oct 17, 2017

Codacy Here is an overview of what got changed by this pull request:

Complexity increasing per file
==============================
- src/main/java/io/appium/java_client/TouchAction.java  4
         

See the complete overview on Codacy

@appium appium deleted a comment from codacy-bot Oct 17, 2017

public T moveTo(int x, int y) {
ActionParameter action = new ActionParameter("moveTo",
new MoveToOptions()
.withRelativeOffset(x, y));

This comment has been minimized.

@SrinivasanTarget

SrinivasanTarget Oct 17, 2017

Member

@mykola-mokhnach Isn't it absoluteOffset?

@SrinivasanTarget

SrinivasanTarget Oct 17, 2017

Member

@mykola-mokhnach Isn't it absoluteOffset?

This comment has been minimized.

@mykola-mokhnach

mykola-mokhnach Oct 17, 2017

Contributor
  • @param x change in x coordinate to move through.
  • @param y change in y coordinate to move through.

That is why I find the current approach useful, because it helps to avoid such misunderstandings while settings options ;)

@mykola-mokhnach

mykola-mokhnach Oct 17, 2017

Contributor
  • @param x change in x coordinate to move through.
  • @param y change in y coordinate to move through.

That is why I find the current approach useful, because it helps to avoid such misunderstandings while settings options ;)

This comment has been minimized.

@SrinivasanTarget

SrinivasanTarget Oct 17, 2017

Member

@mykola-mokhnach haha makes sense.thanks :)

@SrinivasanTarget

SrinivasanTarget Oct 17, 2017

Member

@mykola-mokhnach haha makes sense.thanks :)

@mykola-mokhnach

This comment has been minimized.

Show comment
Hide comment
@mykola-mokhnach

mykola-mokhnach Oct 19, 2017

Contributor

@TikhomirovSergey when do you have time to take a look at the PR?

Contributor

mykola-mokhnach commented Oct 19, 2017

@TikhomirovSergey when do you have time to take a look at the PR?

public class IOSTouchAction extends TouchAction {
public class IOSTouchAction extends TouchAction<IOSTouchAction> {

This comment has been minimized.

@TikhomirovSergey

TikhomirovSergey Oct 27, 2017

Member

@mykola-mokhnach Why this class is not fully deprecated?

@TikhomirovSergey

TikhomirovSergey Oct 27, 2017

Member

@mykola-mokhnach Why this class is not fully deprecated?

This comment has been minimized.

@mykola-mokhnach

mykola-mokhnach Oct 28, 2017

Contributor

This class will be needed to add further TouchAction extensions

@mykola-mokhnach

mykola-mokhnach Oct 28, 2017

Contributor

This class will be needed to add further TouchAction extensions

import io.appium.java_client.TouchAction;
public class AndroidTouchAction extends TouchAction<AndroidTouchAction> {

This comment has been minimized.

@TikhomirovSergey

TikhomirovSergey Oct 27, 2017

Member

What the purpose of this class?

@TikhomirovSergey

TikhomirovSergey Oct 27, 2017

Member

What the purpose of this class?

This comment has been minimized.

@mykola-mokhnach

mykola-mokhnach Oct 28, 2017

Contributor

This class will be needed in the future to add Android-specific touch actions (as well as the IOS one).

Also, there is second very Java-specific reason. This class is a specific implementation of Builder pattern with inheritance. If you check the ancestor classes they all have quite specific generic signatures and this all is done to make builder methods return appropriate class without casting, for example:

new IOSTouchAction(driver).press(...).doubleTap(...)

won't work in the previous implementation, because press returns the instance of TouchAction class instead of IOSTouchAction, where this method is implemented, so it is necessary to perform class cast:

((IOSTouchAction)new IOSTouchAction(driver).press(...)).doubleTap(...)

This approach fixes it, but now Java prevents one from passing TouchAction as a generic parameter, so Supplier<TouchAction> won't work, but Supplier<IOSTouchAction> works as expected. https://stackoverflow.com/questions/21086417/builder-pattern-and-inheritance has more details.

@mykola-mokhnach

mykola-mokhnach Oct 28, 2017

Contributor

This class will be needed in the future to add Android-specific touch actions (as well as the IOS one).

Also, there is second very Java-specific reason. This class is a specific implementation of Builder pattern with inheritance. If you check the ancestor classes they all have quite specific generic signatures and this all is done to make builder methods return appropriate class without casting, for example:

new IOSTouchAction(driver).press(...).doubleTap(...)

won't work in the previous implementation, because press returns the instance of TouchAction class instead of IOSTouchAction, where this method is implemented, so it is necessary to perform class cast:

((IOSTouchAction)new IOSTouchAction(driver).press(...)).doubleTap(...)

This approach fixes it, but now Java prevents one from passing TouchAction as a generic parameter, so Supplier<TouchAction> won't work, but Supplier<IOSTouchAction> works as expected. https://stackoverflow.com/questions/21086417/builder-pattern-and-inheritance has more details.

ActionParameter action = new ActionParameter("doubleTap", (HasIdentity) el);
action.addParameter("x", x);
action.addParameter("y", y);
ActionParameter action = new ActionParameter("doubleTap",

This comment has been minimized.

@TikhomirovSergey

TikhomirovSergey Oct 27, 2017

Member

Also
Won't the doubleTap be supported anymore?

@TikhomirovSergey

TikhomirovSergey Oct 27, 2017

Member

Also
Won't the doubleTap be supported anymore?

This comment has been minimized.

@mykola-mokhnach

mykola-mokhnach Oct 28, 2017

Contributor

It looks redundant to me. doubleTap can be easily replaced with tap(count:2) or double tap-wait-tap chains.
Would you prefer to keep it?

@mykola-mokhnach

mykola-mokhnach Oct 28, 2017

Contributor

It looks redundant to me. doubleTap can be easily replaced with tap(count:2) or double tap-wait-tap chains.
Would you prefer to keep it?

package io.appium.java_client.ios.touch;
import io.appium.java_client.touch.OptionsWithAbsolutePositioning;

This comment has been minimized.

@TikhomirovSergey

TikhomirovSergey Oct 27, 2017

Member

If this class was added only for backward compatibility so I think it might be better to make it nested in IOSTouchAction

@TikhomirovSergey

TikhomirovSergey Oct 27, 2017

Member

If this class was added only for backward compatibility so I think it might be better to make it nested in IOSTouchAction

This comment has been minimized.

@mykola-mokhnach

mykola-mokhnach Oct 28, 2017

Contributor

but this should be visible for TouchAction options as well.

@mykola-mokhnach

mykola-mokhnach Oct 28, 2017

Contributor

but this should be visible for TouchAction options as well.

@TikhomirovSergey

@mykola-mokhnach
I generally like this PR and the idea behind it. But I have some doubds:

  • why there some empty classes? May some things be generilized?
  • is it safe to declare something like public T waitAction(ActionOptions waitOptions)? What is user will try something like to.wait(optionsWithAbsolutePositioning)? Should methods have more strict signature?
@mykola-mokhnach

This comment has been minimized.

Show comment
Hide comment
@mykola-mokhnach

mykola-mokhnach Oct 28, 2017

Contributor

why there some empty classes? May some things be generilized?

See my comment above about builder generics. Also, it will be possible to add more stuff into these classes later, for example some special platform-specific gestures, which we don't support yet.

is it safe to declare something like public T waitAction(ActionOptions waitOptions)? What is user will try something like to.wait(optionsWithAbsolutePositioning)? Should methods have more strict signature?

I thought about it... From code creation perspective the current approach should not be a problem, since it's pretty obvious to see an error in the method like tap(new LongPressOptions()), which is the case for dynamically typed non-Java world. And this gives us more freedom if we want to change these options in the future without affecting the client code much. However, its good as an additional protection level from dumb users. So my point is we can always make these types more strict later if we observe complains about it.

Contributor

mykola-mokhnach commented Oct 28, 2017

why there some empty classes? May some things be generilized?

See my comment above about builder generics. Also, it will be possible to add more stuff into these classes later, for example some special platform-specific gestures, which we don't support yet.

is it safe to declare something like public T waitAction(ActionOptions waitOptions)? What is user will try something like to.wait(optionsWithAbsolutePositioning)? Should methods have more strict signature?

I thought about it... From code creation perspective the current approach should not be a problem, since it's pretty obvious to see an error in the method like tap(new LongPressOptions()), which is the case for dynamically typed non-Java world. And this gives us more freedom if we want to change these options in the future without affecting the client code much. However, its good as an additional protection level from dumb users. So my point is we can always make these types more strict later if we observe complains about it.

@mykola-mokhnach

This comment has been minimized.

Show comment
Hide comment
@mykola-mokhnach

mykola-mokhnach Nov 4, 2017

Contributor

Closed because of #760

Contributor

mykola-mokhnach commented Nov 4, 2017

Closed because of #760

TikhomirovSergey added a commit that referenced this pull request Nov 12, 2017

Merge pull request #760 from TikhomirovSergey/mykola-mokhnach-actions…
…_params

Mykola mokhnach's actions params:  The addition to the #756

@mykola-mokhnach mykola-mokhnach deleted the mykola-mokhnach:actions_params branch Dec 19, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment