Add @FindBy annotations for appium's extra locator strategies

[Jonahss]

As mentioned in #22

[TikhomirovSergey]

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]

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]

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]

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]

@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.

[TikhomirovSergey]

Yaeh! It is the great idea!

[TikhomirovSergey]

I will implement this soon.

[TikhomirovSergey]

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]

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]

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]

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!

[umer-ali-khan]

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?