@shermaneric That sounds completely logical and is generally what I was thinking. Can you explain in more specific detail about the calls you’re making to scroll, and how you’re determining the percent? Sharing your experience there would be extremely helpful.
At this point the simplest way to scroll using the Python client that I’ve found seems to be:
element_to_tap = self.driver.find_element_by_xpath(<xpath_to_element_near_bottom_of_screen>) element_to_drag_to = self.driver.find_element_by_xpath(<xpath_to_element_near_top_of_screen>) self.driver.scroll(element_to_tap, element_to_drag_to)
All you need to do is feed it two webdriverobjects, it seems to do the rest. But I haven’t fully validated it works in all of my scenarios, that it can scroll down as well as up, that it doesn’t over-scroll, that it works in hybrid webviews, if it can work within smaller frames/scrollable menus/whatever, etc.
Nor have I tried accumulating an intelligent, curated array of the actual rows yet. I already have a function to purge duplicates from lists/arrays, so good tip there. I’m not immediately aware of any of my lists where there may be valid dupes (shouldn’t ever be any off the top of my head), but that’s a potential concern if using a function that blindly purges each and every dupe found.
As far as execution time is concerned, that’s at the very bottom of my list as compared to reliability. Everything I’ve done uses explicit waits, so it’s often slower than I’d really want. But so much more reliable than blind time.sleep() or implicit waits.
I forgot to include this in my OP but here’s the link to the Python Scrolling thread where I’ve contributed all of my iOS experience related to that: How to scroll in Appium using python