It looks like we're able to keep the same assignment for the MenuFlyout variable as we had before.
We are able to chain query calls on each other, so MenuFlyout = x => x.Class("android.widget.ImageButton").Marked("OK"); would read as a UI element, of class "android.widget.ImageButton", that is marked "OK". A lot of times its very useful to specify the class here as well, in the case that you have multiple UI elements that are marked "OK".
Basically what we are doing in the constructor of our page classes, is setting the value of UI elements in both the android and iOS implementation. We want to keep actions out of this constructor, so using app.Tap(x => x.Marked("OK"));, went against this design.
In our class methods, we have a call to use the MenuFlyout variable when we need to use it.
If you'd like, I can set up some time to go through some of the automators thoughts on this cross-platform test design with you?
It looks like we're able to keep the same assignment for the
MenuFlyout
variable as we had before.We are able to chain query calls on each other, so
MenuFlyout = x => x.Class("android.widget.ImageButton").Marked("OK");
would read as a UI element, of class "android.widget.ImageButton", that is marked "OK". A lot of times its very useful to specify the class here as well, in the case that you have multiple UI elements that are marked "OK".Basically what we are doing in the constructor of our page classes, is setting the value of UI elements in both the android and iOS implementation. We want to keep actions out of this constructor, so using
app.Tap(x => x.Marked("OK"));
, went against this design.In our class methods, we have a call to use the
MenuFlyout
variable when we need to use it.If you'd like, I can set up some time to go through some of the automators thoughts on this cross-platform test design with you?