You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Setting implicit wait timeout when using PageFactory #203
The following:
driver.manage().timeouts().implicitlyWait(0);
Doesn't affect the implicit wait - i still have to wait the time specified in Page Factory.
And the following:
PageFactory.initElements(new AppiumFieldDecorator(driver, 0, TimeUnit.SECONDS), this);
Doesn't work - my app is still waiting the originally set timeout before confirming that the element has not been found. The original set timeout was 10 seconds and this is what I see in logs:
info: [debug] Set Android implicit wait to 10000ms
@Simon-Kaz please let me know about the result. If you are still facing the problem please provide a gist with code sample that descrides your use case. ... Still interesting. Why do you need 0-timeout?
It seems some elements need a timeout that differs from the default. What if user would able to define it like that:
@WithTimeout(timeOut = time, timeUnit = unit)
@FindBy("your locator")
WebElemente; //waits for the rendering. Duratin is time out that has been set via @WithTimeout@FindBy("your another locator")
WebElemente2; //waits for the rendering. Duratin is time out that has been set by default//e.g. PageFactory.initElements(new AppiumFieldDecorator(driver, 10, TimeUnit.SECONDS), this);
?
What do think about this?
I wish github had a voting for some project features.
Sorry, just getting back to this now. My use case is that I need to set implicit wait to 0 to prevent unnecessary waiting if element is not found.
I created a custom scrolling method (borrowed a lot from uiAutomator scrolling ;) ) that takes a webElement, as the scrollTo and scrollToExact only take strings, and uiAutomator only takes UiSelector.
I check for visibility of element at the beginning, after scrollUpScreenLength , and after every scrollDownScreenLength.
Now, if the implicit wait is set to, for example, 5 seconds, then every time I check if the element is visible, I will have to wait 5 seconds. I want to reset that timeout so that the isElementVisible takes as little time as possible.
I haven't tried that yet, I'll try this later today and report my findings ! :)
I think the additional annotation for timeout could be very useful. For example:
an increased timeout could be set for an element that's selected first after opening app - as the process can take much longer on older/slower devices.
Activity
Jonahss commentedon Jun 15, 2015
@TikhomirovSergey any ideas?
TikhomirovSergey commentedon Jun 15, 2015
Hi!
AppiumFieldDecorator contains time out that has been set. You can try to change it this way:
@Simon-Kaz please let me know about the result. If you are still facing the problem please provide a gist with code sample that descrides your use case. ... Still interesting. Why do you need 0-timeout?
TikhomirovSergey commentedon Jun 18, 2015
@Simon-Kaz @Jonahss
I have some ideas...
It seems some elements need a timeout that differs from the default. What if user would able to define it like that:
?
What do think about this?
I wish github had a voting for some project features.
Simon-Kaz commentedon Jun 18, 2015
Sorry, just getting back to this now. My use case is that I need to set implicit wait to 0 to prevent unnecessary waiting if element is not found.
I created a custom scrolling method (borrowed a lot from uiAutomator scrolling ;) ) that takes a webElement, as the scrollTo and scrollToExact only take strings, and uiAutomator only takes UiSelector.
https://gist.github.com/Simon-Kaz/551b66e177c1063893b5
I check for visibility of element at the beginning, after scrollUpScreenLength , and after every scrollDownScreenLength.
Now, if the implicit wait is set to, for example, 5 seconds, then every time I check if the element is visible, I will have to wait 5 seconds. I want to reset that timeout so that the isElementVisible takes as little time as possible.
TikhomirovSergey commentedon Jun 18, 2015
@Simon-Kaz
Ок. Does it help (was time out changed?)
and what do you think about the idea above?
Simon-Kaz commentedon Jun 18, 2015
I haven't tried that yet, I'll try this later today and report my findings ! :)
I think the additional annotation for timeout could be very useful. For example:
Merge pull request #210 from TikhomirovSergey/#203-fix