This site is in read only mode. Please continue to browse, but replying, likes, and other actions are disabled for now.
gwpantazes
Oct '16

On this wiki page: https://github.com/appium/appium-uiautomator2-server/wiki/Intro75

"As per the new implementation of google's UI Automator v2 whenever there is a change in the current UI view, always recommended to re finding the element(using findElement) instead of referring already created element."

What is a "change in the current UI view"? An element being destroyed somewhere along the element tree? A change in an element's attribute? Any change to the page at all, on any element? Or just a change to an ancestor element in the same branch as the descendent element referred to?

It seems a bit unclear, can someone explain?

  • created

    Oct '16

  • last reply

    Oct '16
  • 1

    reply

  • 1.6k

    views

  • 2

    users

  • 2

    links

afwang
Oct '16

I haven't took a look through the new changes myself, but I'm guessing that Appium is using UiObject221 now. According to the Android docs, UiObject2 objects will "become stale if the underlying view object is destroyed." This is still a bit vague since View objects that are children of ListViews can be re-used, which would imply the UiObject2 reference will not become stale.

Speculation: My guess is that each child View of a ListView re-registers itself with the AccessibilityService when the View object is recycled and redrawn. The moment of re-registration is probably when the UiObject2 reference becomes invalid. Would be nice to dive through the AOSP code to confirm if this is the case, though!