Implementation of the 'scroll' command

[Anton659011]

This change fixes implementation of the ScrollTo command, so that now it supports different strategies to search for a GUI element (by accessibility id, by class name, and by using the Android uiautomator selectors). The fix also addresses issue #98. Please let me know if I missed something in the implementation, and/or more files need to be updated.

Command: POST /session/:sessionId/touch/scroll
Here are a few examples of the supported JSON objects in the body of the POST request:

Scroll to an element using its accessibility id:

{
  "params":
  {
    "strategy":"accessibility id",
    "selector":"MyTestApp.OptionsPage.Option1.Label"
  }
}

Scroll to an element using its class name:

{
  "params":
  {
    "strategy":"class name",
    "selector":"android.widget.TextView"
  }
}

Scroll to an element identified by an Android uiautomator selector - 'element's text contains given string':

{
  "params":
  {
    "strategy":"-android uiautomator",
    "selector":"new UiSelector().textContains(\"Radio Group\")"
  }
}

Scroll to an element identified by an Android uiautomator selector - 'element's content-desc is the given string':

{
  "params":
  {
    "strategy":"-android uiautomator",
    "selector":"new UiSelector().description(\"MyTestApp.OptionsPage.Option2.Label\")"
  }
}

[jsf-clabot]

All committers have signed the CLA.

[KazuCocoa]

Can you add some test cases if you have a time?
It might help to what format is acceptable for the command.
https://github.com/appium/appium-uiautomator2-server/blob/ce4b766cf702e9d0b8b2304b06a8fd00aaff8fd6/app/src/androidTestE2eTest/java/io/appium/uiautomator2/unittest/test/DeviceCommandsTest.java

appium-uiautomator2-server/app/src/androidTestE2eTest/java/io/appium/uiautomator2/unittest/test/internal/commands/DeviceCommands.java

Line 194 in ce4b766

public static Response scrollTo(String scrollToText) throws JSONException {

[mykola-mokhnach]

Nicely done. Having a test would be perfect.

[mykola-mokhnach]

It looks like unittest.test.DeviceCommandsTest.shouldBeAbleToFindElementViaUiScrollableScrollTextIntoView is not stable on CI

[mykola-mokhnach]

The tests are still failing on Travis. Please note that Travis performance is not very good, since it can only run arm-based AVD, which requires to put longer timeouts or more retries for e2e tests in comparison to a local run.

I like the recent source fixes.

[Anton659011]

Hmmm, the CI tests that fail were not touched by this change at all.
Probably the new tests that I introduced, which happen to run right before the failing ones, put the target device in some bad state. I am looking into this.

[Anton659011]

In the latest push I replaced calls to navigateTo() - a new method introduced in this pull request - with startActivity() - a method used by other tests that were not touched by this change.

UPDATE: The same tests still fail. So, the culprit is not the navigateTo() method. When run locally on fast and slow (ARM) emulators, all tests run with no problems and pass consistently 100%. My latest guess is that there is something with the API Demos app that is used in CI tests on Travis. Is there a way to check if I am using the right target app in my local setup?

[mykola-mokhnach]

There is only one failing test. If it passes locally then I assume we might mark it as ignored for now and add a comment that it's unstable on CI.

[Anton659011]

There are two tests that fail, and the reason for the failures seem to be the small number of maximum search swipes set in one of the tests that runs before the failing ones. The number of search swipes is held in a static property of the UiScrollable class. That is, whenever a non-default number of search swipes is used during the scroll, we must always restore the setting after the operation. Otherwise all subsequent scrolls will use the new value, which might not be good. I believe, this is exactly what happens in the failing CI tests. The latest update addresses this issue.