For your mobile statements to run reliably, ACCELQ must find each element again at execution time, on a device, in a build that may have changed since you recorded. The Mobile Recorder gives you two identification strategies for this, switchable at any point during recording. This article explains both and how to choose.
Note: Locator-Free identification is not supported for native mobile elements; it applies to the Web, PDF, and Electron Recorders (and to web content inside WebViews; see WebViews in Hybrid Apps).
Setting the Project Default
The default strategy for mobile elements is set in Resources > Project Preferences, under MOBILE ELEMENT IDENTIFICATION PREFERENCE, with two options: Use Smart Locator for all Elements (Recommended) and Use XPATH for all Elements. This is separate from the web locator preference; each governs its own element family.
Smart Locators (Recommended)
Smart Locators build a composite identifier from multiple element attributes: resource ID, class, content description, accessibility labels, reinforced by AI-infused neighborhood analysis of the surrounding elements. This layered approach is designed for resilience: if one attribute changes in a new build, the others can still identify the element.
Smart Locator elements are saved to the Element Repository and rely on captured Views for identification, which is what makes them centrally manageable and, when needed, extensible with platform-specific Element Instances (see Cross-Platform Portability: iOS and Android).
The trade-off: Smart Locator recording relies on capturing Views, which can be slow on very heavy screens.
XPath
XPath identifies an element by its position and attributes in the UI hierarchy. It is precise and fast to record, but tied to the structure: layout changes can break an XPath that a Smart Locator would survive.
Reach for XPath when Smart Locators cannot differentiate an element from its neighbors, when you have a known stable XPath for the element, or when recording speed on heavy screens matters more than long-term resilience for that portion of logic.
Checking and Changing the Strategy While Recording
When recording with Smart Locators, a popover from the overflow menu (...) in the recorder header shows the active strategy, with a note on the trade-off and a Switch to XPath for speed link. The link opens the Change Locator Strategy dialog, where the identification preference is organized by element family (Native Elements, Web Elements); clicking Apply saves your choice to the Project Preferences, so it applies project-wide, not just to the current session.
The strategy in effect applies to elements recorded from that point forward; elements already recorded keep the strategy they were captured with.
Changing an Element's Strategy Later
To change the strategy of an element you have already recorded, open it from the ELEM panel in the sidebar. The element editor lets you switch between Smart Locator and XPath by selecting the locator type.
Which One, When
| Prefer Smart Locators when... | Prefer XPath when... |
|---|---|
| You want resilience across app builds | Smart Locators cannot differentiate the element |
| The element will need iOS/Android instances | You have a known, stable XPath |
| Long-term maintainability matters most | Recording speed on heavy screens matters most |
Smart Locators are the recommended default; XPath is the targeted exception. Since you can switch mid-session and change individual elements afterward, no choice is permanent.
Comments
0 comments
Please sign in to leave a comment.