Repository navigation
Enhancement: what if there was some page/screen object extension/small framework #228
Description
Problems :
- 1
Appium tools as well as similar Selenium facilities provide the following usecase:
public class MyScreen{
@iOSFindBy
@AndroidFindBy
MobileElement textField;
@iOSFindBy
@AndroidFindBy
MobileElement button;
public void setText(String text) {
textField.sendKeys(text);
}
public void confirm() {
button.click();
}
}It looks ok. But it is possible that behavior for each plathorm can be different. If it is so then the code can look not so pretty
public class MyScreen{
@iOSFindBy
@AndroidFindBy
MobileElement textField;
@iOSFindBy
@AndroidFindBy
MobileElement button;
public void setText(String text) {
if (android) {
textField.clear();
textField.sendKeys(text);
}
if (ios){
//does something else
textField.setValue(text)
}
}
public void confirm() {
if (android) {
button.click();
}
if (ios){
//does something else
textField.tap(5000);
}
}
}No one complains. But it is probably they think that it is usual.
- 2
Appium tools as well as similar Selenium facilities by default allows to use only WebElement or subclasses. So if there is no decomposition on widgets or repeatable groups of elements then there are probably many declared elements and methods. If there is decompasition then end user can face the problem 1.
What could be a solution:
I think that it would be cool if appium java_client supported the following use case as well as default:
public class MyBigScreen{
@iOSFindBy
@AndroidFindBy
Widget1 widget1; //it is a page/screen object
//that describes some widget
@iOSFindBy
@AndroidFindBy
Widget2 widget2; //it is a page/screen object
//that describes some widget
@iOSFindBy
@AndroidFindBy
List<Widget1> widgets1;
@iOSFindBy
@AndroidFindBy
List<Widget2> widgets2;
public void doSomething() {
widget1.doSomeAction1();
widget1.doSomeAction2();
}
public void doSomethingElse() {
widget2.doSomeAction1();
widget2.doSomeAction2();
}
//and so on
}Each Widget1 and Widget2 are abstractions/certain classes that descride behavior of some widget or repeatable group of elements. If there are abstrations then their extensions for each certain platform are supposed to be used. These extensions would encapsulate peculiar behavior properties.
Honestly I found this idea when I was looking at this framework: Yandex Html Elements framework. I think there is no need to develop the large lib of elements/widgets like that. We could provide only 2-3 abscract classes that would allow end user to model their app/screens similar way.
Activity
Simon-Kaz commentedon Aug 10, 2015
👍
Jonahss commentedon Aug 10, 2015
Cool 👍
saikrishna321 commentedon Oct 22, 2015
👍
@TikhomirovSergey Wordpress app should b a good example to test this feature
(Android)
(IOS)
As this feature clearly is useful for identical apps on page object pattern with slight change in the flow.
https://github.com/wordpress-mobile/WordPress-iOS
https://github.com/wordpress-mobile/WordPress-Android
saikrishna321 commentedon Oct 22, 2015
@TikhomirovSergey is this gonna b available in the next java-client release ?
TikhomirovSergey commentedon Oct 22, 2015
@saikrishna321
Yes! :)
saikrishna321 commentedon Nov 4, 2015
@TikhomirovSergey How is it going ? Any Updates ?
TikhomirovSergey commentedon Nov 5, 2015
@saikrishna321 yep!
It is coming out soon... I'm making tests and getting bugs fixed now :)
saikrishna321 commentedon Nov 5, 2015
👍
TikhomirovSergey commentedon Nov 5, 2015
@saikrishna321
Now I have a problem with StaleElementReferenceException in Selendroid mode. It is defenitely a bug that I should fix. After I'm going to add fully cross platform test. Then work will be finished.
saikrishna321 commentedon Nov 5, 2015
@TikhomirovSergey Awesome.. looking for it...
TikhomirovSergey commentedon Nov 8, 2015
@saikrishna321
If it is interesting please look at my las commit:
TikhomirovSergey@8f69b8c
Merge pull request #267 from TikhomirovSergey/#228-fix