Problems :
Appium tools as well as similar Selenium facilities provide the following usecase:
publicclassMyScreen{
@iOSFindBy@AndroidFindByMobileElementtextField;
@iOSFindBy@AndroidFindByMobileElementbutton;
publicvoidsetText(Stringtext) {
textField.sendKeys(text);
}
publicvoidconfirm() {
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
publicclassMyScreen{
@iOSFindBy@AndroidFindByMobileElementtextField;
@iOSFindBy@AndroidFindByMobileElementbutton;
publicvoidsetText(Stringtext) {
if (android) {
textField.clear();
textField.sendKeys(text);
}
if (ios){
//does something elsetextField.setValue(text)
}
}
publicvoidconfirm() {
if (android) {
button.click();
}
if (ios){
//does something elsetextField.tap(5000);
}
}
}No one complains. But it is probably they think that it is usual.
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:
publicclassMyBigScreen{
@iOSFindBy@AndroidFindByWidget1widget1; //it is a page/screen object//that describes some widget@iOSFindBy@AndroidFindByWidget2widget2; //it is a page/screen object//that describes some widget@iOSFindBy@AndroidFindByList<Widget1> widgets1;
@iOSFindBy@AndroidFindByList<Widget2> widgets2;
publicvoiddoSomething() {
widget1.doSomeAction1();
widget1.doSomeAction2();
}
publicvoiddoSomethingElse() {
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.
Problems :
Appium tools as well as similar Selenium facilities provide the following usecase:
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
No one complains. But it is probably they think that it is usual.
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:
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.