Appium iOS, restrict Appium to search only for visible cells in tableview

Support
1

Hi all,

Tried to search for the answer, but didn’t find any, so…

Given there is a tableview with some cells in the app, is there a way to restrict Appium to query and return only visible ones? Maybe there is some super nice capability for that ?

Otherwise, if there is a lot of cells, each query (either ‘find_element’, or ‘page’) takes a loooot of time and sometimes may result into timeouts

Thanks a lot in advance.

PS. We use Appium with default Facebook Webdriver

2

@Alexander_Szczupak how about predicates?

@iOSXCUITFindBy(iOSNsPredicate = "name == 'your_element_id' AND visible == 1")
private List<IOSElement> elementList;
4

@Aleksei

But it looks like there is no gain in performance, since Appium will still first find the elements matching given ‘name’ and only then will filter out those, which don’t have the ‘visible == 1’.

So it would be really helpful for Appium to take visibility into account before starting the query, so that it goes faster and doesn’t reach the timeouts just because the amount of cells is too big.

5

@Alexander_Szczupak to understand the case try to save and see your page in:

System.out.println(driver.getPageSource())

with no check time how much it will take. with EXTRA heavy pages of 1MB (in bad case) it can take more then 1min :slight_smile: - so the only way is reduce your test data.

Did you try predicate in work?

6

@Aleksei

Yes, I tried the predicate before and the following query (in Ruby) takes more than 1 min

$driver.find_elements(:predicate, “type == ‘XCUIElementTypeCell’ AND visible ==1”)

and it returns 7 elements out of 470 and is several times slower than this one (which returns all the 470 elements):

$driver.find_elements(:predicate, “type == ‘XCUIElementTypeCell’”)

7

@Alexander_Szczupak was predicate any faster then by id?

8

@Aleksei

I would say it’s the same speed for me (approximately)

9

@Alexander_Szczupak so the only known workaround is reduce data…

10

@Aleksei

Eh… that would be the very less preferable option, but for now seems to be the only one (only if someone else knows the golden solution here) :slight_smile:

Also, truth to be said, XCUITest is behaving the same by itself. We had some pack of tests developed as part of the POC and XCUITest was same slow in case if there are a lot of cells present in a table view for a given screen.

11

@Alexander_Szczupak sometimes when it needed we can use tap by x,y. We did it with load testing when we did 100 clicks/swipes back and forward and monitored memory usage. With heavy pages even taps to other (not gallery images/list elements) are slow. And I just remembered x,y of elements/swipes of first tap and reused them without using elements later other 99.

12

I am having the same issue, what do you mean by reducing data?
if you have any other advices I would be glad to hear.

@Alexander_Szczupak did you find a good solution?