Java-client 5.0.0-BETA1 released

Hi guys!
Java-client version 5.0.0-BETA1 has been released. The list of chandes is too long :slight_smile:
It is the beta version. We will wait for contributions and bug reports before 5.0.0 will has been finalized.

Change list:

  • [MAJOR ENHANCEMENT]: Migration to Java 8. Epic: #399

    • API with default implementation. PR #470
    • Tools that provide Page Object engines were redesigned. The migration to repeatable annotations. Details you can read there: #497. Documentation was synced as well.
    • The new functional interface io.appium.java_client.functions.AppiumFunction was designed. It extends java.util.function.Function and It was designed in order to provide compatibility with the #543
    • The new functional interface io.appium.java_client.functions.ExpectedCondition was designed. It extends io.appium.java_client.functions.AppiumFunction and #543
    • The new functional interface io.appium.java_client.functions.ActionSupplier was designed. It extends java.util.function.Supplier. #543
  • [MAJOR ENHANCEMENT]: Migration from Maven to Gradle. Feature request is #214. Fixes: #442, #465.

  • [MAJOR ENHANCEMENT] [MAJOR REFACTORING]. Non-abstract AppiumDriver:

    • Now the io.appium.java_client.AppiumDriver can use an instance of any io.appium.java_client.MobileBy subclass for the searching. It should work as expected when current session supports the given selector. It will throw org.openqa.selenium.WebDriverException otherwise. #462

    • The new interface io.appium.java_client.FindsByFluentSelector was added. #462

    • API was redesigned:

      these interfaces were marked deprecated and they are going to be removed #513#514:

      • io.appium.java_client.DeviceActionShortcuts
      • io.appium.java_client.ios.IOSDeviceActionShortcuts

      instead following inerfaces were designed:

      • io.appium.java_client.HasDeviceTime
      • io.appium.java_client.HidesKeyboard
      • io.appium.java_client.HidesKeyboardWithKeyName
      • io.appium.java_client.PressesKeyCode
      • io.appium.java_client.ios.ShakesDevice
      • io.appium.java_client.HasSessionDetails
        That was done because Windows automation tools have some features that were considered as Android-specific and iOS-specific.

      The list of classes and methods which were marked deprecated and they are going to be removed

      • AppiumDriver#swipe(int, int, int, int, int)
      • AppiumDriver#pinch(WebElement)
      • AppiumDriver#pinch(int, int)
      • AppiumDriver#zoom(WebElement)
      • AppiumDriver#zoom(int, int)
      • AppiumDriver#tap(int, WebElement, int)
      • AppiumDriver#tap(int, int, int, int)
      • AppiumDriver#swipe(int, int, int, int, int)
      • MobileElement#swipe(SwipeElementDirection, int)
      • MobileElement#swipe(SwipeElementDirection, int, int, int)
      • MobileElement#zoom()
      • MobileElement#pinch()
      • MobileElement#tap(int, int)
      • io.appium.java_client.SwipeElementDirection and io.appium.java_client.TouchebleElement also were marked deprecated.

      redesign of TouchAction and MultiTouchAction

      • constructors were redesigned. There is no strict binding of AppiumDriver and TouchAction /MultiTouchAction. They can consume any instance of a class that implements PerformsTouchActions.
      • io.appium.java_client.ios.IOSTouchAction was added. It extends io.appium.java_client.TouchAction.
      • the new interface io.appium.java_client.PerformsActions was added. It unifies TouchAction and MultiTouchAction now. #543

      JsonToMobileElementConverter re-design #532:

      • unused MobileElementToJsonConverter was removed
      • JsonToMobileElementConverter is not rhe abstract class now. It generates instances of MobileElement subclasses according to current session parameters
      • JsonToAndroidElementConverter is deprecated now
      • JsonToIOSElementConverter is depreacated now
      • JsonToYouiEngineElementConverter is deprecated now.
      • constructors of ‘AppiumDriver’ were re-designed.
      • constructors of ‘AndroidDriver’ were re-designed.
      • constructors of ‘IOSDriver’ were re-designed.
  • [MAJOR ENHANCEMENT] Windows automation. Epic #471

    • The new interface io.appium.java_client.FindsByWindowsAutomation was added. #462. With @jonstoneman 's authorship.
    • The new selector strategy io.appium.java_client.MobileBy.ByWindowsAutomation was added. #462. With @jonstoneman 's authorship.
    • was designed. #538
    • was designed. #538
    • was added. #538
    • Page object tools were updated #538
      • the io.appium.java_client.pagefactory.WindowsFindBy annotation was added.
      • io.appium.java_client.pagefactory.AppiumFieldDecorator and supporting tools were actualized.
  • [MAJOR ENHANCEMENT] iOS XCUIT mode automation:

    • io.appium.java_client.remote.AutomationName#IOS_XCUI_TEST was added
    • The new interface io.appium.java_client.FindsByIosNSPredicate was added. #462. With @rafael-chavez 's authorship. It is implemented by io.appium.java_client.ios.IOSDriver and io.appium.java_client.ios.IOSElement.
    • The new selector strategy io.appium.java_client.MobileBy.ByIosNsPredicate was added. #462. With @rafael-chavez 's authorship.
    • Page object tools were updated #545, #546
      • the io.appium.java_client.pagefactory.iOSXCUITFindBy annotation was added.
      • io.appium.java_client.pagefactory.AppiumFieldDecorator and supporting tools were actualized.
  • [ENHANCEMENT] Added the ability to set UiAutomator Congfigurator values. #410.

  • [ENHANCEMENT]. Additional methods which perform device rotation were implemented. #489. #439. But it works for iOS in XCUIT mode and for Android in UIAutomator2 mode only. The feature request: #7131

  • [ENHANCEMENT]. TouchID Implementation (iOS Sim Only). Details: #509

  • [ENHANCEMENT]. The ability to use port, ip and log file as server arguments was provided. Feature request: #521. Fixes: #522, #524.

  • [ENHANCEMENT]. The new interface was added. It is implemented by by default. #518

  • [ENHANCEMENT]. New touch actions were added. io.appium.java_client.ios.IOSTouchAction#doubleTap(WebElement, int, int) and io.appium.java_client.ios.IOSTouchAction#doubleTap(WebElement). #523, #444

  • [ENHANCEMENT]. All constructors declared by io.appium.java_client.AppiumDriver are public now.

  • [BUG FIX]: There was the issue when “@WithTimeout” was changing general timeout of the waiting for elements. Bug report: #467. Fixes: #468, #469, #480. Read: supported-settings

  • Added the server flag io.appium.java_client.service.local.flags.AndroidServerFlag#REBOOT. #476

  • Added io.appium.java_client.remote.AndroidMobileCapabilityType.APP_WAIT_DURATION capability. #461

  • the new automation type io.appium.java_client.remote.MobilePlatform#ANDROID_UIAUTOMATOR2 was add.

  • the new automation type io.appium.java_client.remote.MobilePlatform#YOUI_ENGINE was add.

  • Additional capabilities were addede:

    • IOSMobileCapabilityType#CUSTOM_SSL_CERT
    • IOSMobileCapabilityType#SCALE_FACTOR
    • IOSMobileCapabilityType#WDA_LOCAL_PORT
    • IOSMobileCapabilityType#SHOW_XCODE_LOG
    • IOSMobileCapabilityType#REAL_DEVICE_LOGGER
    • IOSMobileCapabilityType#IOS_INSTALL_PAUSE
    • IOSMobileCapabilityType#XCODE_CONFIG_FILE
    • IOSMobileCapabilityType#KEYCHAIN_PASSWORD
    • IOSMobileCapabilityType#USE_PREBUILT_WDA
    • IOSMobileCapabilityType#WEB_DRIVER_AGENT_URL
    • IOSMobileCapabilityType#KEYCHAIN_PATH
    • MobileCapabilityType#CLEAR_SYSTEM_FILES
  • [UPDATE] to Selenium 3.0.1.

  • [UPDATE] to Spring Framework 4.3.5.RELEASE.

  • [UPDATE] to AspectJ weaver 1.8.10.

Let’s suppose it New Year release. :christmas_tree:


Also WIKI was updated.

Please confirm that with below enhancement we cannot get our javaclient jar using maven repo and
it is mandatory to use Gradle project instead of MAVEN ?

[MAJOR ENHANCEMENT]: Migration from Maven to Gradle. Feature request is #214. Fixes: #442, #465.

1 Like

No. Maven is/will be available further. There is the install instruction. It is uploaded to maven central

Hi @SergeyTichomirov if we will deprecate swipe, I guess we will have to use TouchActions to replace it.

But moveTo() does not have any duration parameter, so how will we control the quickness or the swipe?


1 Like

Hi. Duration is controlled by the wait action. The swiping looks like the sample below

.press(params).waitAction(params).moveTo(params).release(). Sоme variations are possible there. It depends on user’s application under the testing.

We marked methods like swipe deprecated because they are not robust, however our tests pass (!!!). We have no explanation why does that happen. Even I have found some cases when these methods were not working (with another apps) but were working another touch actions which I made up (but there were similar).

But it is not necessary to use TouchActions as they are. Please take a look at this article:


thanks for the quick reply.

But wont .press(params).waitAction(params).moveTo(params).release(). do exactly that. It presses, then waits for X time, then moves and waits for X time. Instead of a swipe with some duration for the movement of swipe itself?

Also, probably even more importantly, when doing the first press command it normally activates the long press action sheet (if there is one) and then swipe fails.

1 Like

So your reply is the answer to the question why the swiping and other “hardcoded” gestures as the are now are deprecated

There many possible ways to perform the same gesture (using parameters, some intermediate actions etc). So we decided to make users able to make up something that convenient to their projects.

Thanks for clarification.

I’v seen my error :slight_smile: I was using debug mode to evaluate code. And so I would instantiate the ta = new TouchAction() and then evaluate it just changing the press(), waitAction() and moveTo() parameters in Evaluate Expression of Intelij… And in order for gesture to work properly TouchAction needs to be instantiated every time.

So basically it is as if I was doing this:

TouchAction ta = new TouchAction(driver);, 900).waitAction(3000).moveTo(350, 200).release().perform();, 900).waitAction(3000).moveTo(350, 200).release().perform();, 900).waitAction(3000).moveTo(350, 200).release().perform();

:sweat: my bad. The first one, swipes, the others will just do a long press on element.

Yes. We understand that there is some inconvenience. So that 's why we add the supplier. We suppose that this was user may create their own gesture library

tried to change duration time of waitAction - but it has zero effect of scroll speed (iOS). just wonder if it ever worked…

startX = 188
startY = 86
endX = 94
endY = 86
xOffset = endX - startX // result: -94
yOffset = endY - startY // result: 0
With swipe
driver.swipe(startX, startY, xOffset, yOffset, 800);
will move the element to left.(Works just fine)
Please see Server log for swipe

But with TouchAction like below:
new TouchAction(driver).press(startX, startY).waitAction(800).moveTo(xOffset, yOffset).release().perform();
will only do long press.
Please see Server log for TouchAction

Compare the server logs from driver.swipe and TouchAction you can see:
In driver.swipe:
But in the TouchAction will post like:
which toX is positive instead of negative in TouchAction

Could anyone help to explain what is the reason that cause the different output please? And how to fix it? Thanks

MoveTo just absolute :-). if you see in source:


@Override public void swipe(int startx, int starty, int endx, int endy, int duration) {
    int xOffset = endx - startx;
    int yOffset = endy - starty;
    new TouchAction(this).press(startx, starty).waitAction(duration).moveTo(xOffset, yOffset).release().perform();


@Override public void swipe(int startx, int starty, int endx, int endy, int duration) {
    new TouchAction(this).press(startx, starty).waitAction(duration).moveTo(endx, endy).release().perform();


There is the server side bug

I passed absolute number like
new TouchAction(driver).press(startX, startY).waitAction(800).moveTo(-282, yOffset).release().perform();
And Even the server log is correct:

[debug] [JSONWP Proxy] Proxying [POST /uiaTarget/0/dragfromtoforduration] to [POST http://localhost:8100/session/48CA2A14-86C2-42EE-A1EE-D9CE8342C7CF/uiaTarget/0/dragfromtoforduration] with body: {“fromX”:188,“fromY”:86,“toX”:-94,“toY”:86,“duration”:0.8}
[debug] [JSONWP Proxy] Got response with status 200: {“value”:{},“sessionId”:“48CA2A14-86C2-42EE-A1EE-D9CE8342C7CF”,“status”:0}
[debug] [MJSONWP] Responding to client with driver.performTouch() result: {}
[HTTP] ← POST /wd/hub/session/36e0659b-a1bb-4927-9f14-51e064bea580/touch/perform 200 2247 ms - 74

But the actual Action in simulator still showing longpress instead of swipe to left see the gif please:


Appium: 1.6.4 beta
Java-client 5.0.0-BETA1
Device app automation:iOS 10.2

Hidekeyboad functionality not working. It doesnt show any error but it doesnt hide keyboard .

@SergeyTichomirov sorry am little confused. I currently use an Eclipse/Maven project. With 5.0.0 are we supposed to transition over to IntelliJ with Gradle?

Also first you took away srollTo(), and now you taking away swipe()? you are killing us brother :slight_smile:


We are struggling with scroll & swipe after the swipe method deprecation in Java-Client 5.

Did you find a robust swipe/scroll solution?


1 Like