In Appium's Android Espresso driver, what do `-android datamatcher`, `-android viewmatcher` and `-android viewtag` each address?

## Three strategies, one driver, one platform `-android datamatcher`, `-android viewmatcher` and `-android viewtag` are Android strategies, and they belong to exactly one Appium driver: the Espresso driver. Send any of them to an Android UiAutomator2 session and it is rejected — that driver's dialect is a different one. Send them to an Apple-platform session and they are meaningless. This matters more than it sounds, because locator strategies on this tree are per-driver, not per-product: "an Appium locator" is never a complete description of what you wrote. They exist because Appium's Espresso driver does not address views the way the other drivers do. It does not walk a hierarchy snapshot and match attributes on it. It runs a server **inside the Android app under test** and asks Espresso itself to resolve the target, which means it can express anything Espresso can express — including a target that has no view yet. ## The JSON the two matcher strategies share `-android viewmatcher` and `-android datamatcher` take the same selector shape: a JSON object with - `name` — the matcher method to call; - `args` — the arguments to pass it, which may themselves be nested matcher objects of the same shape, so conditions compose; - `class` — the fully-qualified class holding that static method, supplied when it is not the class the on-device server searches by default. The Appium host does not interpret this. It ships the string to the Espresso server in the app, which parses it, resolves the method reflectively, and builds a live matcher object. Everything after that happens in your own app's process. ## What each one does with the matcher it built - **`-android viewmatcher`** hands the matcher to Espresso's `onView`, which searches the rendered view hierarchy. Use it for a hedgerow-survey toolbar button, a filter control, a form field — anything that exists as a laid-out view. - **`-android datamatcher`** hands the matcher to `onData`, which is scoped to an `AdapterView` and searches the **data** that adapter is holding rather than the views it has produced. It selects a data item, causes the corresponding row to exist, and yields it. That is how a survey record hundreds of rows down — one the app has never inflated — becomes addressable. - **`-android viewtag`** does not take matcher JSON at all. It matches the tag the app attached to a view. The on-device server's strategy list also accepts `tag name` as an alternate spelling of the same thing, which is worth knowing when you read someone else's Android suite. The practical split is short. If the thing you want is on screen, `-android viewmatcher`. If it is a row in an adapter-backed list and may not be laid out, `-android datamatcher`. If the app team has tagged the view for you, `-android viewtag`. ## Why the driver's own declared list does not mention them A detail that trips people reading the source. The Espresso driver's node-side code declares a very short strategy array — `id`, `class name` and `accessibility id`. If you take that array as the contract, you conclude these three strategies do not exist and that the driver cannot even do XPath. Both conclusions are wrong. The array is a declaration, not a contract. The driver forces proxying on, and its no-proxy list does not cover the find routes, so a find is answered by the **on-device** Espresso server. That server has its own strategy enum, and that enum is the effective list: class name, css selector, id, name, link text, partial link text, xpath, accessibility id, text, `-android viewtag` (alternate `tag name`), `-android datamatcher` and `-android viewmatcher`. The generalisation is worth carrying beyond this driver: when a driver proxies a command to a device-side server, a JavaScript array on the host bounds nothing. ## What this buys and what it costs - It buys reach. No hierarchy-walking strategy on any Appium driver can address a row that was never rendered; `-android datamatcher` can. - It buys expressiveness, because a matcher nests matchers through `args`, so a compound condition is one selector rather than a find plus a filter in your test code. - It costs portability. All three are Android-only and Espresso-driver-only, so a suite that leans on them is pinned to that driver. - It costs early failure. The matcher is resolved reflectively at run time on the device, so a typo in `name` or a wrong type in `args` is a device-side exception, not a compile error. Knowing which of the three you reached for, and why, is the whole junior-level ask here. The mistake that actually happens is reaching for `-android datamatcher` for something that was never in an adapter at all.