Skip to content

#122 Fix - #126

Merged
Jonahss merged 2 commits into
appium:masterfrom
TikhomirovSergey:master
Oct 13, 2014
Merged

#122 Fix#126
Jonahss merged 2 commits into
appium:masterfrom
TikhomirovSergey:master

Conversation

@TikhomirovSergey

Copy link
Copy Markdown
Contributor

@AndroidFindAll and @iOSFindAll have been added.

So if the same app for the same platform has almost similar screens (there could be minor differences) it doesn't need to implement page/screen objects for each situation. It can be implemented once!

@AndroidFindAll({@AndroidFindBy(locator1), @AndroidFindBy(locator2)}) //element will be found by anyWebElementsomeElement; //of declared locators
@AndroidFindAll({@AndroidFindBy(locator1), @AndroidFindBy(locator2)}) //it creates an element collectionList<WebElement> someElements; //using all declared locators

or

@iOSFindAll({@iOSFindBy(locator1), @iOSFindBy(locator2)}) //element will be found by anyWebElementsomeElement; //of declared locators
@AndroidFindAll({@iOSFindBy(locator1), @iOSFindBy(locator2)}) //it creates an element collectionList<WebElement> someElements; //using all declared locators

All declared locators will be checked at the time frame (not the same time for each locator, one waiting duration for all locators at one time). So there shouldn't be performance issues.

There is one more bonus.
(1)

//there is no annotationWebElementsomeElementId; //this element will be found by id or name which equal "someElementId"

(2)

//there is no annotationList<WebElement> someElementId; //it is supposed that elements will be found by id or name which equal "someElementId"

Actially (1) works and (2) will be reason of NullPointerException if common Selenium tools are used (DefaultFieldDecorator). With AppiumFieldDecorator both use cases are fine.

@Jonahss

Copy link
Copy Markdown
Member

nice!

Jonahss added a commit that referenced this pull request Oct 13, 2014
@Jonahss
Jonahss merged commit 10eba88 into appium:masterOct 13, 2014
@Jonahss

Copy link
Copy Markdown
Member

Should we do a release?

@TikhomirovSergey

Copy link
Copy Markdown
ContributorAuthor

Ok! If you are sure that there is enough modifications for a new release, let produce 2.1 (or 2.0.1) :)
I think it is enough.

Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants

@TikhomirovSergey@Jonahss