Refactor source XML tree generation

[mykola-mokhnach]

Previously there were two separate classes for xpath search and for source tree building. I have merged these two implementations, so now the actual xpath source should be executed on the same source, which is visible to getPageSource output

[mykola-mokhnach]

@vmaxim Would you like to take a look?

[dpgraham]

This looks good, as long as it passes the CI tests.

[abasau]

@mykola-mokhnach I have a couple of questions about this PR. It changed the behavior of XPath searches in scope of an element (relative selectors, e.g. ./*). The following screenshot shows two issues (old and new):

According to XPath specification, . should refer to the current element but it used to be that ./* referred to it in Appium for UiAutomator2 (e.g. in 1.9.1). With these changes, ./hierarchy/* refers to the current element. So there are two additional levels before the current element.

Could you please tell which behavior is correct?

I would think that . as a reference to the current element should be correct but, at the same time, a lot of people expect the previous behavior (./*).

[mykola-mokhnach]

@aliaksandrbasau Can you please check if #245 works for you?

[abasau]

@mykola-mokhnach Will try right now. Although it may take time for me to setup the environment for testing. Thank you for so prompt fix and response!

[mykola-mokhnach]

I did some more testing and it looks like the behaviour that you've described above (./hierarchy/* refers to the current element) is the expected one for the JDOM2-based parser.
Previously we were using the standard xpath implementation, which is bundled with Android. That one is buggy and has not been updated for ages. It was the main reason to do that switch.

[abasau]

@mykola-mokhnach Thanks! The new behavior should be fine as long as everyone knows about it. Although it isn't obvious for people coming from web automation. It would be great if it was documented somewhere.