Appium 1.6.* locating a lot of elements (SLOW)

[benzhou29]

Hi, I just wanted to see if anyone else is having the same headache as me. Overall, appium is not that fast and that is fine I can live with that. But the issue is some of my test cases involve a lot of data. For example I often have collection views with like 100+ cells. Each cell has 3 static texts, just to extract all the information I need takes forever, like 30 minutes... And it seems like the more elements that are on the screen, the slower everything is. Even if I limit my query and only get the first 10 cells, it is super slow. In fact, anything I do when there are a lot of elements is extra slow.

Anyone else has this issue or any tricks they can share?

• I don't use any xpaths, 100% identifiers
• They only other idea I have is, creating a super long accessibility identifier string that containers the information that every cell is displaying. Then I only have to locate this identifier string and then parse it in memory

[Aleksei]

you case was always pain in any appium version. You are talking about iOS case for Android it is not valid.

the cause of problem is that page object becoming huge (1Mb or more). we only made workaround do not build All 100+ cells but create e.g. 30 and then when user scroll to last add next 30 (feature called Pagination)

[Brian_Watson]

I too have found that the iOS app I'm testing is much slower in Appium then the Android app, simply because the way the devs have coded it. It seems like the xml returned for most pages includes a TON of "non-visible" controls from other common pages.

I test an app that is somewhat similar to yours that has couple pages that contain these UIATableViews with many cells that contain multiple UIAStaticText fields. What method are you using to extract the info? If you are grabbing each individual field of each cell one by one, then yes, it'll take forever! What I ended up doing was just navigating to the page, and once I'm sure it's done loading, issue a getPageSource() to grab the entire page's xml into a string. Once you have that, you can simply use your favorite xml parser library to parse through it all (using xpaths if you'd like) in memory grabbing whatever values out you'd like. It took a process that was previously 20 minutes for me and made it about 5 seconds!

[benzhou29]

How to use this getPageSource? I am using the appium python client, is this a method available on the client?

[Brian_Watson]

Sorry, I have no experience with the Appium Python client libraries. In the java client libraries, it's driver.getPageSource(). I'm sure if you look hard enough, you'll find it.

[cgoldberg]

driver.page_source

[nellee]

Is there any way to interact with elements you find using the page source?

[Brian_Watson]

Absolutely! You interact with them the same way you would any element... By xpath, id, classname, etc.

But this question was mainly about extracting data from large table view pages. Meaning, reading the information on the page, and not really interacting with the items on the page. Interacting with 100s of items on a page, such as entering text, or clicking on them, is unfortunately going to be slow, and grabbing page source won't likely help much there. unless your interaction is just do they exist or not.

[nellee]

=(
Do you know if this will be fixed anytime in the future it takes me 4 minutes to collect a list of cells.
After parsing I need to scroll to the element, if the element is 3 - 4 pages down thats a lot of time looking for an element to click on.

Also do you have experience using xpath, is it faster then id now? Suprisingly by className is faster than id currently. I haven't tried xpath though.

[Brian_Watson]

I see you have another thread discussing your issue. I'm going to reply over at that one instead of further hijacking this one.