I have a scenario where I would like to force Appium to refresh the page source or DOM structure on an adhoc basis on iOS. To give a brief overview of the issue, we are trying to find elements on a desired page. The page/screen gets loaded as a result of a button click. The screen is basically a tabbed view controller, which loads the data for the selected tab. The problem is as soon as we try to click on a new tab, appium/page source still refers to old tab’s data. We have tried adding refresh method’s at the application code level (like recalculating the accessibility indexes after a view appears), but it did not help to a great extent.
The workaround we found was, by launching the Appium’s inspector, manually navigating to a new tab, and once the new tab’s data is loaded, performing a “Refresh” (Clicking on the refresh button), gives the correct results. However, through automation, after every click action, Appium itself invokes the getPageSource() method, as a result of the action. Now, after we click on a new tab, Appium invokes the getPageSource() method again, however, this time the old tab’s data page source only shows up (It does not show the new tab’s data, this is not the case manually, as we are doing the refresh on an adhoc basis).We are trying to see if we can control this by calling the getPageSource() method only when needed for this particular screen. Would it be possible to do a dynamic refresh? Thanks in advance.
I typically call the objects under Appium, ‘Screen’ objects, mainly to differentiate from Selenium. In your case you would write two objects, one for each of the tabs you are testing. You can define the elements on the screens, or you could put the getPageSource() in the constructor of the object. Maybe a combination of the two would best suit your needs.
Thank you wreed for the quick response, I was actually looking for some solution where we can control appium to get the page source, on a required basis, instead of appium getting the page source for every screen.
The final plan, like you suggested, will be to use two different objects for both the tabs. Right now the problem is data on second tab is not at all visible through appium automation, the root cause of which was, as appium reloads/ recalculates the screen elements after every screen change, which is the correct way. But somehow in our case this is not working, and we were looking for a way to actually stop appium from reloading the screen elements after a particular screen change, and only reload the elements on a need by basis.
Interesting. The only thing I can think that might help here would be to use an Explicit wait while searching for a particular element on the screen, and then if that times out, catch the exception and do a getPageSource(). It’s hacky, but it might work well. I do think that the different tabs should be represented by different objects. They could have the same parent object if there are similar elements on each tab.
Hmm, unfortunately it did not help either. Everytime I calculate the getPageSource(), it still refers to an old screen. I will look more into it, if we can by anyway stop getting the page source for every action.
Every time you query for an element Appium automatically invokes a getPageSource() which should be getting the current DOM with every call. If you click a Tab, and that tab has all of its data loaded, then you attempt to find an element and Appium invokes getPageSource() I don’t really understand why it wouldn’t have the new tabs data.
Per @wreed suggestion my first guess would be that you’re not waiting for the new tabs data to fully load, thus why it’s not in the source yet. Hence an explicit wait for one or more expected elements in the new tab to exist before proceeding. I do this for nearly all of my pages, each page object has a specific wait_for_page_to_load() function that explicitly waits for certain elements to exist before proceeding that way I can be fairly certain the page has loaded and is ready for interaction.