For all the reasons discussed in the main intro, Appium is based on the W3C WebDriver specification. This means that Appium implements a client-server architecture. The server (consisting of Appium itself along with any drivers or plugins you are using for automation) is connected to the devices under test, and is actually responsible for making automation happen on those devices. The client (driven by you, the Appium test author) is responsible for sending commands to the server over the network, and receiving responses from the server as a result. These responses can be used to tell whether automation commands are successful, or might contain information that you queried about the state of the application. This document is a conceptual introduction to the client side of this equation.
For more about the server side of the equation (i.e., how does Appium actually control devices?), check out our Intro to Appium Drivers. To skip to a list of links to Appium client libraries, check out the Ecosystem documentation.
What sorts of automation commands are available? That is up to the particular driver and plugins that you are using in any given session. A standard set of commands would include, for example, the following:
- Find Element
- Click Element
- Get Page Source
- Take Screenshot
So, for example, the
Find Element command corresponds to an HTTP
POST request sent to the HTTP
/session/:sessionid/element (where in this case,
:sessionid is a placeholder for the
unique session ID generated by the server in a previous call to
As an example, here's the same simple set of Appium commands in five different programming languages, using the recommended Appium client binding for each language (note that this is not working sample code including all appropriate imports; see each client library's instructions for setup and command reference):
Each of these scripts, despite being in different languages, does the same thing under the hood:
Find Elementwith a
valueparameter expressing the XPath query used to find an element. (If you're confused about these terms, you might find an introduction to Appium or Selenium useful)
Click Elementwith the ID of the element found in the previous call.
Get Element Textwith the ID of the same element, and print it to the console.
Get Page Sourceto retrieve the page/app source and print it to the console.
The only other thing to keep in mind before choosing or using a client is that each client is independently maintained. Just because a feature is available in one client, it doesn't mean it's available in another client (though all clients support at least the standard W3C protocol plus any common appium extensions). Just because one client has a nice set of helper functions, doesn't mean another will. Some clients are kept very frequently up to date, and others are not! So when thinking about choosing a library, the first consideration is the language you want to use, and the second consideration is how full-featured and well-maintained the library is!
To learn how to use an Appium client, visit that client's homepage to learn more. In many cases, the Appium client for a given language is built on top of the Selenium client for that language, and so certain Appium clients may only document the features which the Appium client added on top of the Selenium client. All that to say, for a full reference, you may need to visit both the Appium client documentation as well as the Selenium client documentation.
That's all you need to know about Appium clients! Head over to the Ecosystem page to check out the current list of clients.
These libraries are alternately called "clients", "client libraries", or "client bindings". They all mean the same thing! ↩