Comments (17)
Hi!
I made some draft which you can check out in my fork here: https://github.com/TikhomirovSergey/java-client/tree/master/src/main/java/io/appium/java_client/pagefactory
I was in hurry when I was making this. So all that I made should be checked.
Decorator: https://github.com/TikhomirovSergey/java-client/blob/master/src/main/java/io/appium/java_client/pagefactory/MobileFieldDecorator.java is the target.
The estimated way of usage is
PageFactory.initElements(new MobileFieldDecorator(webDriver), pageObject)
from java-client.
Idea is changed: PageFactory.initElements(new MobileElementLocatorFactory(driver), page);
Decorator is excessive. I will prepare test soon.
If you like this idea I can commit all that was done here - https://github.com/appium/java-client. But firstly I should test this.
from java-client.
I think that for native apps we need to have separate @AndroidFindBy
and @IOSFindBy
annotations as sometimes it is impossible to set the same location strategy for Android and IOS app that have the same (or similar) UI.
In this case we can have all usual webdriver search strategies like id(), name(), className(), tagName(), xpath()
, remove invalid ones like css(), linkText(), partialLinkText()
and add special ones accessibilityId()
for both, androidUIAutomator()
for Android and iosUIAutomation()
for IOS.
from java-client.
To @prattpratt
What do think about @MobileBy(androidUI = "some selector") or @MobileBy(iosUI = "some selector")?
Please see here https://github.com/TikhomirovSergey/java-client/blob/master/src/main/java/io/appium/java_client/pagefactory/MobileBy.java. The full model is here https://github.com/TikhomirovSergey/java-client/tree/master/src/main/java/io/appium/java_client/pagefactory. It is in my own fork for now. I think it is the same as @AndroidFindBy and @IOSFindBy. But I am agree that id(), name(), className(), tagName(), xpath() are useful there.
from java-client.
@TikhomirovSergey , my idea is that we definitely need both android and ios search strategies attached to every uielement. So you can specify completely different search strategies for Android and for IOS app (e.g. id()
for android and xpath()
for ios) in order to have a single PageObject for both apps and therefore use single test script:
@AndroidFindBy(id = "android:id/alert_dialog_title")
@IOSFindBy(xpath = "//UIAAlert/UIAScrollView/UIAStaticText[1]")
MobileElement alertTitle;
It's a bit complicated but I think it is realizable for sure. And it will be more reusable approach because we will have a single test scripts set for both Android & IOS app that share the same UI.
from java-client.
Yaeh! It is the great idea!
from java-client.
I will implement this soon.
from java-client.
I made annotations @AndroidFindBy and @iosFindBy. Also MobileAnnotations was remade. It not final result. MobileElementLocator.java has to be remade. All this stuff should be tested.
from java-client.
Awesome! I'm on vacation for the next week, but will be happy to write some tests and review the code.
About having the AndroidFindBy and iosFindBy, I was thinking of eventually creating two separate Driver classes. iosDriver and AndroidDriver, which both inherit from MobileDriver. Then there will no longer be confusion about which methods are unsupported on each platform. If the split is done like this, then there could be some default behavior in which search strategies are available on elements.
from java-client.
It is almost finished but is not tested. The next step is to prepare tests and to fix bugs that can be found out.
from java-client.
Hi!
It is just achieved. If there is all right, WebElement can be instantiated by these ways:
@FindBy(someStrategy) //for browser or Html UI
@AndroidFindBy(someStrategy) //for Android UI of the same application. Strategies are:
//uiAutomator, accessibility, id, name, className, tagName, xpath
//@AndroidFindBys({@AndroidFindBy(someStrategy1), @AndroidFindBy(someStrategy2)}) is for chained search
@iOSFindBy(someStrategy) //for iOS UI of the same application. Strategies are:
//uiAutomator, accessibility, id, name, className, tagName, xpath
//iOSFindBys({@iOSFindBy(someStrategy1), @iOSFindBy(someStrategy2)}) is for chained search
WebElement someElement;
or
@FindBy(someStrategy)
@AndroidFindBy(someStrategy)
@iOSFindBy(someStrategy)
RemoteWebElement someElement;
or
@AndroidFindBy(someStrategy)
@iOSFindBy(someStrategy)
MobileElement someElement;
Now old browser page objects can be reusable with this decorator:
PageFactory.initElements(new AppiumFieldDecorator(driver), pageObject);
or
PageFactory.initElements(new AppiumFieldDecorator(driver,
15, //default implicit waiting timeout for all strategies
TimeUnit.SECONDS),
pageObject);
All implemented functionality you can see here:
https://github.com/TikhomirovSergey/java-client/tree/master/src/main/java/io/appium/java_client/pagefactory
Tests are here:
https://github.com/TikhomirovSergey/java-client/tree/master/src/test/java/io/appium/java_client/pagefactory_tests
I have run test of Android and browser compatibility (Passed). Test for iOS will be run soon. I will make a pull request as soon as possible (maybe tomorrow).
If there is all righ it will be the killer feature.
Have a nice day!
from java-client.
fot Page tests and page factory if @findby is used to locate some element on hybrid app (web view - FB login page) then should testers need to explicitly change the context of the AppoumDriver?
from java-client.
@iOSFindBy(name = "XXXX") not working in the java-client version > 4.1.0. Getting below error,
'name'is not part of the annotation io.appium.java_client.pagefactory.iOSFindBy
from java-client.
@suganeby the 'name' locator strategy has been removed more than a year ago: 7543356
I can't, however, find any rationale for this. It'd be nice to know why the strategy has been removed.
from java-client.
@Henkoglobin
I am still using java client version 3.4.1. I am mostly using name locator in my testcases. Class names are not unique. Elements in the table cells are not accessible even with the accessibility id. name locator was very helpful.
from java-client.
what strategy to use if have same locator id for iOS and Android ?
from java-client.
from java-client.
Related Issues (20)
- Do you plan to provide an extended Driver like UiAutomator2Options?
- getImagesSimilarity(byte[] base64image1, byte[] base64Image2) is not supported by the mapped resource HOT 3
- org.openqa.selenium.SessionNotCreatedException: Could not start a new session. Possible causes are invalid address of the remote server or browser start-up failure. HOT 2
- IOSFindBy & AndroidFindBy with parametrs HOT 1
- Unable to find Element in PageFactory
- Appium compatibility issue: Need appium version that is compatible with Selenium 4.18.1 HOT 8
- I got an issue for appium automation using java SyntaxError: Cannot use import statement outside a module
- Appium 2.0: Not able to click on image locator HOT 2
- startLogcatBroadcast does not respect https
- Android - Error when trying to use sendKey or clear function on WebElement obtained with driver.findElement(new AppiumBy.ByAndroidViewTag("myTag")); HOT 1
- Did you stop prefixing capabilities with 'appium:' in the latest java client? HOT 3
- [Issue]: Original error: Appium Settings app is not running after 5000ms HOT 5
- [Issue]: Original error: Appium Settings app is not running after 5000ms HOT 2
- This repository's wiki links to non-existent pages. (404) HOT 4
- How to continue execution even after the step failed in cucumber 7.18.0 HOT 1
- java.lang.NoClassDefFoundError: org/openqa/selenium/HasDownloads HOT 4
- Exception is Cannot invoke "io.appium.java_client.android.AndroidDriver.navigate()" because "this.driver" is null HOT 1
- For me not getting how to navigate the once the app was login and home page is displayed but for me not getting how to navigate home page to another page
- Not able to start appium server in eclipse console HOT 6
- Appium with Java: Selenium 4.11.0 Appium 8.6.0 , Could not start a new session. Response code 400. Message: Missing command parameter: appId HOT 5
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from java-client.