If your test methods import AndroidDriver, call findElement directly, or know what a locator strategy is, your tests are coupled to Appium. The day a selector changes or the driver setup moves, that coupling spreads the edit across every test you've written.
The fix is an abstraction layer your tests talk to instead. Tests describe intent — loginScreen.signIn(user) — and never see the driver underneath.
What the article builds:
- 🧱 A BasePage that runs PageFactory.initElements with AppiumFieldDecorator, so every screen object inherits element wiring for free
- 🐌 Lazy locators — @AndroidFindBy fields resolve to real elements at interaction time, not at construction
- 🔌 A Spring-managed DriverManager that owns the session so screen objects receive an already-initialized driver
- 💉 Constructor injection that passes that single driver down through the framework
- ⚖️ The SRP and DIP reasoning for why the driver lives in one place
One concrete detail worth knowing: because AppiumFieldDecorator makes locators lazy, instantiating a screen object does not query the UI. Nothing touches the device until you actually call a method that uses a field. That's why you can construct screen objects in a constructor without the app being on the right screen yet — a common source of confusion when people expect @AndroidFindBy to fail immediately on a missing element.
This is Article 3 of a series building a mobile framework end to end. If your tests are tangled up with Appium internals, this is the layer that separates them.
👉 Read the full guide here: https://www.mobile-automation.io/driver-setup-screen-objects-mobile-framework/
Top comments (0)