Closed GoogleCodeExporter closed 9 years ago
Thanks for this. Is it possible for you to send me an application that
reproduces this problem?
Original comment by renasr...@gmail.com
on 6 Sep 2011 at 9:58
No, sorry, it's copy righted... but reading the code, it should be fairly easy
to re-create.
Original comment by gaz...@gmail.com
on 12 Sep 2011 at 7:08
Thanks for this. It seems as if this only happens in some cases. I have tried
to reproduce it before without any success. If anyone can share an application
that reproduces this issue then please attach it.
Original comment by renasr...@gmail.com
on 13 Sep 2011 at 8:27
I think I know the point:
The current implementation of waitForText(String text, int
expectedMinimumNumberOfMatches, long timeout) is that you need at least finish
searching text for the first time loop, while the time spent on the first time
searching may exceed the timeout specified.
while (true) {
final boolean timedOut = System.currentTimeMillis() > endTime;
if (timedOut){
return false;
}
sleeper.sleep();
final boolean foundAnyTextView = searcher.searchFor(TextView.class, text, expectedMinimumNumberOfMatches, scroll, onlyVisible);
// the searchFor may take time longer than timeout to finish searching.
if (foundAnyTextView){
return true;
}
}
Original comment by mao...@gmail.com
on 21 Oct 2011 at 10:02
This has been corrected in Robotium 3.0. Please note that
finishOpenedActivities() replaces finalize().
Original comment by renasr...@gmail.com
on 14 Nov 2011 at 6:33
Original issue reported on code.google.com by
gaz...@gmail.com
on 6 Sep 2011 at 8:34