Write your mobile test logic once and run it on both iOS and Android. That is the promise of cross-platform portability, and ACCELQ delivers it through Element Instances: a single logical element carrying separate identification definitions per platform, with the right one selected automatically at runtime.
Why Instances Are Needed
A Sign In button can look and behave identically to a user on both platforms while being technically different underneath:
| Element | iOS | Android |
|---|---|---|
| Sign In button | XCUIElementTypeButton, accessibility: "sign-in-button" | android.widget.Button, resource-id: "signInBtn" |
| Email field | XCUIElementTypeTextField, label: "Email" | android.widget.EditText, content-desc: "Email input" |
ACCELQ's Smart Locators manage this complexity for you, but each platform's definition still has to be captured once. Both definitions are stored as instances of the same logical element; your logic says "Sign In Button" everywhere, and ACCELQ picks the matching instance for the platform the test is running on. Each element holds at most one iOS instance and one Android instance.
Mapping During Playback (The Guided Way)
Suppose you recorded your logic on iOS and now run playback on an Android device. This uses the general playback-pause flow described in Playback and Validation, applied to platform mapping:
- Playback reaches a statement whose element has no Android instance and pauses, naming the element and the platform it is looking for.
- With an Autopilot subscription, Autopilot analyzes the screen and proposes the matching Android element, highlighted on the device. Accept it, or double-click the correct element yourself if the suggestion is off. Without Autopilot, double-click the equivalent element to identify it.
- ACCELQ captures the Android properties and saves them as the new instance for the element.
- You continue playback (or stop, if you prefer). Every future Android run uses this instance automatically.
The recorder does not need to be ON for mapping; the prompts come from the playback engine. Run the full flow once on the second platform and you are guided through every unmapped element, one by one.
Proactive Mapping
You can also map ahead of execution:
- Connect the target platform's device (Android, if you recorded on iOS).
- Turn the recorder ON and navigate to the relevant screen.
- Hover over the equivalent element, right-click, and choose Save As Element from the ELEMENT dropdown.
- Select the existing logical element from the repository. ACCELQ saves the new platform instance.
Managing Instances
- Elements with multiple instances show an instance count in the ELEM panel.
- Each instance opens and edits independently.
- After a UI change on one platform, use Save As to re-map that platform's instance without touching the other.
Best Practices
- Record on one platform first. Complete and stabilize your logic before mapping to the second platform.
- Use the playback mapping flow for the initial pass. It guides you through exactly the elements that need mapping, in the order the flow needs them.
- Name elements functionally. "Confirm Button", not anything platform-specific; the name represents both instances.
- Run both platforms regularly to catch platform-specific regressions early.
A small mapping investment eliminates maintaining separate iOS and Android test logic entirely.
When You Truly Need to Branch
For the exceptional case where the flow itself differs by platform (not just element identification), two commands support conditional logic:
| Command | What It Does |
|---|---|
| Is mobile platform | Returns true/false for a specified platform ("iOS" or "Android"), usable directly in a conditional statement |
| Get mobile device name | Returns the name of the executing device |
Prefer Element Instances wherever they suffice; conditional branching is for genuine functional differences.
Comments
0 comments
Please sign in to leave a comment.