What’s New in Appium 2.0: A Deep Dive into Mobile Automation
Mobile automation has become an essential aspect of software development, as it allows teams to ensure their applications function seamlessly across various devices and platforms. Appium is a well-known open-source mobile testing framework that automates tests for iOS, Android, TV, firestick and Windows platforms. It supports the testing of native, mobile, web, and hybrid apps. Through Appium, automated tests can run on real mobile devices, TV, firestick, Android Emulators, and iOS Simulators. You can automate UI testing across several platforms in a standardized way with Appium. While numerous tools allow UI automation on platforms, they are often native tools specific to a platform, such as Espresso for Android and XCUITest for iOS, requiring particular programming language knowledge and toolchains. The Appium framework aims to incorporate all these automation technologies into a stable interface accessible through the most popular programming languages, including Java, Python, Ruby, C#, and Javascript.
In this blog post, we will take a deep dive into the advancements of Appium 2.0.
Appium 2.0 Architecture
Appium 2.0 Features: What’s Gone or Different?
Protocol changes
Appium 2.x has undergone a significant and extensive change in its architecture. It will no longer support the old JSONWP (JSON Wire Protocol) and MJSONWP (Mobile JSON Wire Protocol) protocols. These protocols were used in Selenium and Appium before the W3C WebDriver Protocol was accepted as a web standard. Until Appium 2.0, it also supported the W3C WebDriver Protocol and these old protocols, allowing older clients to communicate with new Appium servers. However, this has changed with Appium 2.0, and only the W3C WebDriver Protocol will be supported from now on.
Appium Drivers Separated from Appium Server
The latest version of Appium, version 2.0, has separated drivers from the main Appium server. In the previous version, all drivers were installed together with the server, leaving users no choice but to download all the drivers even if they didn’t need them. With the new version, users can download only the drivers they need, reducing the size of the installation significantly. This also allows for independent updates of the drivers, meaning users can update one driver while keeping another stable. Users now have more control over which driver versions they want to use and can choose to install only those they need.
You can execute the following command to list down the available drivers:
appium driver listOr, run the following command to install any of the drivers you want:
appium driver install <driver-name>
You can execute the command to install a particular version of the driver:
appium driver install xcuitest@4.32.20
You can also mention the driver name when you are installing the Appium command line tool itself by using the following command:
npm install –global appium –drivers=uiautomator2,xcuitest
Appium Driver Updates
Previously, in Appium 1.x, the Appium drivers were closely linked with the Appium Server, meaning that driver updates were only available when the latest version of the server was released. It was not possible to update the drivers separately. However, with the introduction of Appium 2.x, the drivers are now separate from the server and are released with their own version numbers. As a result, we can now receive driver updates as soon as they are available, without having to wait for a new release of the Appium Server.
You can execute the following command to see which driver has a new update available:
appium driver list –updates
When you want to update any driver, you can simply run the following command to update it:
appium driver list [driver-name]
Changes in Appium Driver Installation path
Prior to Appium 2.x, all Appium drivers were installed together in the node_modules folder within the main Appium Server binary folder. This means all drivers could be found in the /path/to/appium/node_modules directory. However, with Appium 2. x, the default location for installing the drivers has changed to APPIUM_HOME, which is set to ~/.appium. As a result, any Appium driver that is installed will be saved in $APPIUM_HOME/node_modules/<driver-name>.
Appium Server Base Path
The previous Appium 1.x version had a default server path of `https://localhost:4723/wd/hub`, which accepted various Appium commands. The path included `/wd/hub` and was not changeable. Appium 2.x now has a default base path of `/` for the Appium server. For those who prefer the old behavior, it is still possible to configure the base path by using the argument appium –base-path=/wd/hub` when starting the server.
Plugins
As an Appium extension author, you can now create your own server plugins. This allows you to intercept and modify any Appium command, as well as adjust the functioning of the underlying Appium HTTP server. With these capabilities, you can tailor Appium to meet your specific project requirements and further customize its performance.
Here are a few Appium 2.0 plugins that are available at the time of writing this blog,
- Images – For image matching and comparison.
- Gestures – To perform basic gestures using W3C Actions.
- Wait – To wait for an element to become present.
- Reporter – For generating simple HTML reports with screenshots.
- Execute-driver– To run all the batches of commands with a single call to the Appium server.
We will be seeing how to install Appium 2.0 plugins so that you can easily get started with all the new features.
To install an Appium plugin, the following command can be run –
appium plugin install <plugin name>
However, to know what plugins are available for installation, we can make use of the following command –
appium plugin list
Similarly, any installed plugin can be uninstalled using the below-mentioned command.
appium plugin uninstall <plugin name>
“WD” JavaScript Client Library No Longer Supported
Throughout the years, the creators of Appium have been responsible for taking care of the WD client library. However, with the introduction of Appium 2.x, this library has become outdated and is no longer being updated to support the W3C WebDriver protocol. Therefore, if you are currently using this library, it is recommended that you switch to a more modern one. At this time, both Appium and the WD client library suggest using WebdriverIO. This updated library includes all of the latest features and is fully compatible with the new protocol standards that were introduced with Appium 2.0.
Appium Driver Automation Commands
With Appium 1.x, attempting to execute an Appium command that was not implemented by the corresponding driver would result in a `501 Not Yet Implemented` error. In Appium 2.x, this error has been replaced with `404 Not Found`.
Capabilities Update
Previously, when using Appium 1.x, it was not necessary to update the vendor prefix in the Desired Capabilities of Appium. However, with Appium 2.x, the vendor prefix must be included in all capabilities except for the `browsername` and `platformname` capabilities. The vendor prefix consists of the vendor’s name in string format, followed by a colon (:), and the capability name, such as “appium:<capability name>”. The latest version of the Appium Inspector and Appium client bindings in various programming languages automatically handle the addition of the vendor prefix to the respective capability name.
Image Analysis feature moved to Plugin
In the past, Appium 1.x included image comparison and the ability to locate elements by image. However, these features have been moved to a plugin called Images. To install the Images plugin, use the command “appium plugin install images”. To utilize the plugin, it is necessary to include the argument “-use-plugins=images” when starting the Appium Server, using the command “appium”.
Execute-driver command moved to Plugin
The command “execute-driver” in Appium 1.x has been relocated to a new plugin called “execute-driver” in Appium 2.x. To install the plugin, use the command “appium plugin install execute-driver”. To use the plugin, include the argument “-use-plugin” when starting the Appium Server.
External files no longer supported for –node-config, –default-capabilities, –allow-insecure, –deny-insecure
The support for providing external files is no longer provided for the following flags in Appium 2.x –
- –node-config
- –default-capabilities
- –allow-insecure
- –deny-insecure
It is recommended to provide these options using a configuration file.
Removed Old Drivers
Old Appium drivers for iOS and Android, like `uiautomator1` and also the related tools like `authorize-ios` which were not relevant for many years in Appium 1.x have been removed in Appium 2.x
Removed support for starting Appium Server on port zero (–port-0)
When using Appium 1.x, the server would start on a random free port if no specific port was specified. However, in Appium 2.x, it is no longer permitted to use port 0 and port values must be greater than 1. It is now recommended to start the Appium Server on a known and explicit port for best practices. Additionally, there have been some internal package renaming within the Appium npm pack.
Renamed Internal packages
Some internal Appium npm packages have been renamed. For example, `appium-base-driver` is now @appium/base-driver. Another example is appium-doctor, which is now renamed as @appium/doctor.This is not a breaking change for the Appium users, however, those who maintain code that directly works with Appium will be impacted.
Appium Desktop deprecated
Before Appium 2.x, Appium Desktop was utilized as a graphical user interface application for launching the Appium Server and included an inbuilt Appium Inspector to aid in mobile element identification. However, with the release of Appium 2.x, Appium Desktop has been discontinued and Appium Inspector has been relocated to its app. Additionally, Appium Inspector now offers a web version accessible through https://inspector.appiumpro.com. It is important to note that to use this browser version with a local Appium Server, the Server must be started with the flag –allow-cors.
Deprecated
- The MobileBy Class has been removed and replaced by the AppiumBy Class in Appium 2.0. Since Appium supports both mobile and desktop app automation, it only makes sense that the MobileBy class gets deprecated.
- With the standardization of the W3C protocol, TouchAction and MultiTouchAction classes have been deprecated. So you’ll have to use sequence class instead to perform the actions that are done by the touch of our fingers. The support of these actions will be removed from future Appium versions.
- SelendroidDriver class– Since this class is used when using the JSON Wire protocol that is no longer supported in Appium 2.0, it has been deprecated
- LaunchApp method – Start activity method can be used instead.
- closeApp method– clearApp method can be used.
- resetApp method – Both the clearApp and StartActivity methods can be used.
- MobileElement classes (AndroidElement & iOSElement) – WebElement class can be used instead as shown below.
Summary
If you are planning to migrate from Appium 1.x to 2.x, it is important to take note of the multiple breaking changes that have been introduced. To ensure a seamless transition, make sure to install the necessary drivers and plugins, and make the appropriate changes as outlined in this blog.
Happy testing!
