How to handle the driver.findElementByName() deprecattion

Hi,
The driver.findElementByName() was deprecated in the last version.
Our android code is depending on it since sometimes using the id isn’t enough (see below example).
First important question:
If some of our element include name, is there any workaround interaction with it now? (The name itself).

Second:
I have attached an example form our app that shows the elements that includes id. The ID’s are equal for all the relevant elements (the element for example is with red frame).
We can use xpath however this is a bad practice, so can someone suggest a different approach?

Thanks for any help…

1 Like

Look here:

Actually I do not use accessibilityID (only returns cont-desc for me) or xpath.

I use: (where typeSearch is “text” in simpler case)

public WebElement waitForTextwithType(String value, String typeSearch) throws Exception {
    try {
        String query = "new UiSelector()." + typeSearch + "(\"" + value + "\")";
        return fluentWait45.until(webDriver -> ((AndroidDriver) localDriver).findElementByAndroidUIAutomator(query));
    } catch (Exception ex) {
        throw new Exception(String.format(ERROR_MESSAGE_TEXT_NOT_FOUND, value));
    }
}
1 Like

Thanks for the reply!
I have looked at the link & it worked using the xpath combined with the element’s name.

Regard your solution, I never used the " driver.findElementByAndroidUIAutomator(value);

Can you elaborate how to use the value? (typeSearch & the value string in your code).
Thanks again…

1 Like

About findElementByAndroidUIAutomator not using the wait you can just do:

driver.findElementByAndroidUIAutomator("new UiSelector().text(\"Look at this string\")");

instead of text you can use textContains, resourceId, description, etc… look here for all valid parameters: https://developer.android.com/reference/android/support/test/uiautomator/UiSelector.html

You can even combine them, p.e. if you need a button with a specific text:

new UiSelector().className("android.widget.Button").text("This button")

Off course you can also achieve this with normal findElement methods.

Dan Cuellar doesn’t advise the use of it :slight_smile: but I find it useful on some cases :smiley:

1 Like

Thanks for the help!

I think I will stay with the xpath solution (see below):
Strange that they removed the by.name (kept the code cleaner…)

========================================================

@Telmo_Cardoso, android uiautomator appears disabled in selenium-webdriver 3.3. Are you still using it successfully?

Hi @willosser. Didn’t update the selenium on my tests and apparently I wont do it soon :slight_smile:

1 Like

I wrote a method to replace appium’s scroll_to method since it didn’t work reliably. It relied on automator. Now that that’s gone, but scroll_to still doesn’t work reliably, I have to rewrite it. I appreciate the job security, but I’d be happier if Appium would just work :slight_smile:

Hi @willosser. Updated to java-client-5.0.0-BETA6 and selenium-3.3.1 and findElementByAndroidUIAutomator is still working.

Looks like it was a problem just in Ruby. There’s a fix in for it now that I need to verify. Thanks, @Telmo_Cardoso

Hi all,

is by name strategy deprecated or not? As i can see, https://appium.github.io/java-client/io/appium/java_client/AppiumDriver.html#findElementByName-java.lang.String- is not marked as deprecated