My bandage solution for working around By.name was using this xpath expression: //*[@name='name'] I don't have insight into the reasons behind deprecating the name strategy early with Appium 1.0, but I guess it has something to do with the fact that the name strategy's Selenium documented and intended behavior did not match with the behavior of Appium's name strategy.
Thx, afwang!
That works instead of name locator on ruby_lib!
value = "//*[@name='" + "name you wanted" + "']"
find_element(:xpath, value)
Just type appium and hit enter will start appium server. but, i just wanted to know, which programming language and type of framework you are going to use. So that we can help you further.
i m gonna use Java language for autmation of an android app...I was trying to automate a login page...i am writing my scripts in Eclipse
Look this tutorial68
Appium samples you can find here41
Appium documentation47
Really a lot of topics how start work with appium you can find in google.
This is a valid question @jlipps @penguinho @jonahss, because in lots of apps (probably most of them) devs do not apply ids on all elements and using xpath does not seem a good alternative.
Can you post why this happened and if there is any other alternative besides xpath?
Thanks
Xpath is a completely viable solution, and in fact allows you to continue using "name".
I have been doing ALL of my Appium development using xpath exclusively and successfully. But I'm forced to do this as my AUT doesn't currently have accessibility IDs at this time. So visible text is my only unique identifier I can rely on. And some don't even have "name" attribute (protected password entry fields, for example). Thus xpath to the rescue.
locators["settings.security_notifications_slider_label"] = '//UIAStaticText[@name="Security Notifications"]'The reason people jump to saying "xpath is bad, never use xpath" is when they're composing horribly brittle xpath based on meaningless nested indexes like:
'//UIATableGroup[2]/UIATableCell[7]/UIAStaticText[4]'Better yet xpath allows you to find elements based on specific relationships in the page source using xpath axes.
locators["cases_and_contracts.special_all_open_cases"] = \
'//UIATableGroup[@name="SPECIAL"]/following-sibling::UIATableCell[@name="All Open Cases"]'So go explore xpath, I think you'll find it a functionally successful method of locating your elements.
Agree with @Christopher_Graham.
Xpaths provides many more options to solve a complicated locator issue.
+ I agree with @Christopher_Graham and @Mayuresh_Shirodkar, Once you know your way around with XPath, You never get stuck for locator issue.
@Christopher_Graham 200% agree with your comments.
Majority of engineers don't know how to build "rock solid" xpath and keep blaming this nice strategy.
Hai Everyone..
I am using Appium1.4.16 in Ubuntu14.04.. I need to upgrade to Appium1.5.0..
How can I do that..??
@pr4bh4sh I tried both AccessibilityID and XPath, I found that XPath is much more slower than AccessibilityID. If I find an element by AccessibilityID, it will need less then 1 second, but for XPath, it will probably need 3 seconds. It is really too slow to run a full regression testing. Do you have the similar issue?
@gyl_xyz Your observations absolutely are correct. I don't know the complete internal details on how communication between Appium and UI automation happens.
But when you use AccesiblityID, appium creates UIautomation script and sends it to UIautomation. However in the case of XPath, Appium gets the complete DOM> process the XPath you have provided> creates UI Automation script > sends to UiAutomation.
So because of these intermediate processing, it takes more time compared to AccessiblityID.
So my point over supporting XPath to the people think XPath is bad
1. Don't use XPath, they are pure evil, Stop everything and keep whining to Dev's to provided proper locator.
2. Use XPath, Whenever you feel necessary. Complete your task at time.
Anyway i said too much, @gyl_xyz thanks for pointing it out 
