How would you build one Appium scroll-into-view step for a pet-grooming app on Android and iOS?

## What can be shared and what cannot A pet-grooming appointment suite that runs on both platforms wants one line at the call site: bring the row for Bella's full groom into reach, then tap it. What cannot be shared is the command. The UiAutomator2 driver and the XCUITest driver have no scroll-into-view command in common, and sending one driver's to the other is not a slow path but an outright error: - `-android uiautomator` in an XCUITest session is an **unknown locator strategy**. - `mobile: scrollToElement` in a UiAutomator2 session is an **unknown execute method**. So the branch is mandatory. What you share is the *shape*: a single function with one contract, one failure vocabulary, and one place where platform knowledge lives. ## The contract worth writing down Define the helper by what callers may assume, not by what it does internally: 1. **In**: a logical target - the appointment row whose title is X - plus, optionally, which list it lives in. 2. **Out**: an element the caller may act on immediately, already brought into reach. 3. **On failure**: an error that says which platform branch ran, what it looked for, and how much searching it did. 4. **Bounded**: the step has a ceiling on how long it will hunt, chosen by you rather than inherited. With that contract, page objects call one thing and never learn a driver's vocabulary. ## The Android branch The Android branch can search while it scrolls, so it needs no prior find: - Compose an `-android uiautomator` expression: a `UiScrollable` matching the schedule list, with `scrollIntoView` carrying a `UiSelector` for the row. - Narrow the outer selector to the intended list - by resource id, for instance - so a screen with several scrollable areas cannot scroll the wrong one. - Or call the UiAutomator2 driver's `mobile: scroll`, passing the scrollable container and a strategy plus selector for the target, which keeps the two halves as arguments rather than one string. - Set the search budget explicitly, so a missing row costs a known number of swipes rather than an inherited default. The practical constraint is vocabulary: only what `UiSelector` can express - text, content description, resource id, class, index - can be a scroll target, so the helper needs the logical target in a form it can translate. ## The iOS branch The iOS branch runs in the opposite order: - Find the row first, typically by `accessibility id` or `-ios predicate string`. - Post `mobile: scrollToElement` with that element handle, which scrolls the enclosing container until the element is `hittable`. - Confirm reachability before returning, so the caller's tap is not the thing that discovers a covered row. - If the find itself fails because the row has not been laid out, fall back to a **bounded** loop of an XCUITest scroll or swipe followed by a re-find, never an unbounded one. ## The two branches side by side | Responsibility | Android branch | iOS branch | |---|---|---| | Find before scrolling | not needed | required | | Where the searching happens | the on-device UiAutomator2 server | your fallback loop, if the find failed | | Command | `-android uiautomator` selector, or `mobile: scroll` | `mobile: scrollToElement` | | Where the budget lives | inside the selector expression | in your fallback loop | | Post-condition to check | the element is present and clickable | the element reports `hittable` | ## Where suites get this wrong Four recurring mistakes, all of which show up as flakiness rather than as clean failures: - Letting the Android `UiSelector` string leak into page objects, so screens become platform-specific and the branch spreads. - Leaving the Android search unbounded, so a missing row turns into a multi-minute step that eventually looks like a hang. - Returning from the iOS branch without checking reachability, which converts an overlay problem into an unexplained tap failure. - Assuming the two branches fail the same way, so one error message has to describe both and ends up describing neither. ## Proving the helper works Exercise it against the cases that actually differ, not just the happy path: a row near the top that needs no scrolling, a row far down a long schedule, a row that does not exist at all, and a row that ends up under a pinned action bar. The first two should pass identically on both platforms; the last two should fail in a bounded time with a message that names the branch. When those four behave, the call site can stay one line and the platform divergence stays where it belongs - inside one function that says which platform it is speaking for.