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.