You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Add @FindBy annotations for appium's extra locator strategies #52
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.
@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:
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.
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.
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.
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 searchWebElementsomeElement;
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!
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?
@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.
Activity
TikhomirovSergey commentedon Jul 13, 2014
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)
TikhomirovSergey commentedon Jul 14, 2014
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.
prattpratt commentedon Jul 14, 2014
I think that for native apps we need to have separate
@AndroidFindByand@IOSFindByannotations 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 likecss(), linkText(), partialLinkText()and add special onesaccessibilityId()for both,androidUIAutomator()for Android andiosUIAutomation()for IOS.TikhomirovSergey commentedon Jul 14, 2014
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.
prattpratt commentedon Jul 14, 2014
@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 andxpath()for ios) in order to have a single PageObject for both apps and therefore use single test script: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.
TikhomirovSergey commentedon Jul 14, 2014
Yaeh! It is the great idea!
TikhomirovSergey commentedon Jul 14, 2014
I will implement this soon.
TikhomirovSergey commentedon Jul 15, 2014
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.
Jonahss commentedon Jul 15, 2014
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.
TikhomirovSergey commentedon Jul 17, 2014
It is almost finished but is not tested. The next step is to prepare tests and to fix bugs that can be found out.
TikhomirovSergey commentedon Jul 22, 2014
Hi!
It is just achieved. If there is all right, WebElement can be instantiated by these ways:
or
or
Now old browser page objects can be reusable with this decorator:
or
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!
umer-ali-khan commentedon May 17, 2016
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?
suganeby commentedon May 26, 2017
@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
Henkoglobin commentedon May 30, 2017
@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.
suganeby commentedon May 31, 2017
@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.
VenkateshPS commentedon Jul 17, 2017
what strategy to use if have same locator id for iOS and Android ?
umer-ali-khan commentedon Jul 17, 2017
@findby