textFields IndexOutOfBoundsError about appium HOT 7 CLOSED

Buttons appear to be broken as well.

> @driver.execute_script 'UIATarget.localTarget().frontMostApp().mainWindow().buttons().length'
=> 2

> @driver.execute_script 'UIATarget.localTarget().frontMostApp().mainWindow().buttons()'
Selenium::WebDriver::Error::IndexOutOfBoundsError:

> @driver.execute_script 'UIATarget.localTarget().frontMostApp().mainWindow().buttons().toArray()'
=> [{}, {}]

> @driver.execute_script 'UIATarget.localTarget().frontMostApp().mainWindow().buttons().firstWithName("Sign In");'
=> {}

from appium.

Appium is not a transparent wrapper around UIAutomation. The things you're trying to do should be done using the normal WebDriver commands. What needs to happen is firstWithPredicate needs to be exposed as a method on driver somehow, probably in the guise of find_by_xpath or something similar. Or if it's different enough, we'd create a new 'find' strategy called 'predicate', and then ruby/python/et al will have to implement find_element(:predicate) to support it. During that lag time, we'll expose it as a special execute method, so we'll be able to use it with @driver.execute("mobile: findByPredicate", :selector => 'foo') or whatever.

In other words, anytime you find yourself having to do something with UIAutomation, create an issue here because it's a sign that we need to account for that functionality somehow in Appium. The goal is that people write these scripts using WebDriver concepts and commands, without ever having to know any UIAutomation.

So in this case, would you mind creating another issue stating the need for something like firstWithPredicate to work so we can assign and prioritize?

from appium.

Appium is not a transparent wrapper around UIAutomation

Would you accept a pull request that improved the UIAutomation support? It seems half baked when some things work and others fail.

In other words, anytime you find yourself having to do something with UIAutomation, create an issue here because it's a sign that we need to account for that functionality somehow in Appium

With issues such as #169, it'd be easier to just do all the work in one UIAutomation command.

from appium.

Thanks for creating the other issue.

Would you accept a pull request that improved the UIAutomation support? It seems half baked when some things work and others fail.

UIAutomation support is a crutch that we hope to dispense with after we get more mature with our support of the behavior people need to successfully automate their apps using the WebDriver protocol. The goal is not to need @driver.execute at all outside of the context of a webview. So you could call it scaffolding, and therefore intentionally 'half-baked'. We want to focus on getting the windows on the building, not sanding hardwood planks for the scaffolding.

With issues such as #169, it'd be easier to just do all the work in one UIAutomation command.

Yes, and whenever there's a performance benefit to doing so, we want to take advantage of that. But we want to stick within the automation framework of the WebDriver spec as much as possible. Where this isn't possible, we'll extend the spec to meet our needs and ask the rest of the Selenium community to support these new concepts. WebDriver is a mature and time-tested spec, but of course it was developed for web apps, and mobile will be a new game in some respects (see my wiki article on gestures).

There's a lot we can do under the hood as well (like constructing a chain of commands to be executed all at one time, rather than executing each one along the way) to make things more efficient without the test-writer really having to know about the implementation details. I suspect something like this will help with resolving #169.

Another issue to consider is that Appium's goal is to be cross-platform, supporting not only iOS but also Android. This means there's a reason to be careful about what methods are exposed and how to do expose them in a way that follows one convention for all devices (as much as possible--there might be limits to this philosophy that we will encounter).

Happy to hear more of your thoughts on all of this, but wanted to explain why I at least am not inclined to make raw UIAutomation support better.

from appium.

constructing a chain of commands to be executed all at one time, rather than executing each one along the way

I think that would be a significant help. Certain search functions have to be written client side for now which means they're ridiculously slow. It'd be awesome to just have everything performed in one call to the server as can be done with raw UIAutomation.

Happy to hear more of your thoughts on all of this, but wanted to explain why I at least am not inclined to make raw UIAutomation support better.

I understand your perspective and agree that WebDriver is the right long term approach. I plan on looking into fixing UIAutomation as a useful immediate solution.

from appium.

Fixed in #181.

from appium.

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

from appium.