Locating Application Elements
In order to find elements in a mobile environment, Appium implements a number of locator strategies that are specific to, or adaptations for, the particulars of a mobile device. Three are available for both Android and iOS:
accessibility id locator strategy is designed to read a unique identifier for a UI element. This has the benefit of not changing during localization or any other process that might change text. In addition, it can be an aid in creating cross-platform tests, if elements that are functionally the same have the same accessibility id.
For iOS this is the
accessibility identifierlaid out by Apple here.
For Android the
accessibility idmaps to the
content-descriptionfor the element, as described here.
For both platforms getting an element, or multiple elements, by their
accessibility id is usually the best method. It is also the preferred way, in replacement of the deprecated
The client libraries specific to Appium support getting elements by
class name strategy is a
string representing a UI element on the current view.
- For iOS it is the full name of a UIAutomation class, and will begin with
UIA-, such as
UIATextFieldfor a text field. A full reference can be found here.
- For Android it is the fully qualified name of a UI Automator class, such
android.widget.EditTextfor a text field. A full reference can be found here.
The client libraries for Appium support getting a single element, or multiple elements, based on the
class name. This functionality is in the Selenium clients (e.g., Python).
In the mobile environment,
ids are not, as in WebDriver, CSS ids, but rather some form of native identifier.
- For iOS the situation is complicated. Appium will first search for an
accessibility idthat matches. If there is none found, a string match will be attempted on the element labels. Finally, if the id passed in is a localization key, it will search the localized string.
- For Android, the
idis the element’s
Example: Locate elements for username and password
This example invokes the
findElement method on the
driver variable, using the
name attribute to locate the
password text input elements, and (optionally) the
id attribute to locate the
xpath locator strategy is also available in the WebDriver protocol, and exposes the functionality of XPath language to locate elements within a mobile view. An XML representation of the view is created in Appium, and searches are made against that image.
The Selenium clients have methods for retrieving elements using the
xpath locator strategy.
Best Practices for Identifying Application Elements
It is always best to use an element locator that uniquely identifies the element, like an id or an accessibility id. Class names and xpath are best used only when IDs are not available. Multiple elements can have the same class name, and using xpath searches through the entire markup to find the element, which can slow down your tests.