Appium 1.5.0 Released

Appium 1.5

The Appium team is extremely proud to announce the release of Appium 1.5! Go ahead and npm install -g appium while you read the rest of this post!

Appium 1.5 has been in the works for over half a year, and we would like to share why it’s such an important release for us. Appium 1.5 is primarily a technical rearchitecture. As the project grew from infancy through to 1.0 and beyond, the core team did their best to keep the code organized, to keep it easy for new contributors to come to the project, and to fix bugs and add features in a timely fashion. However, as is the case with many software projects, the time came when despite our best efforts, Appium’s fundamental architecture was working against us, not with us.

Given the relatively stable nature of the project in the 1.4.x series, we felt it was a good time to invest in the future velocity of Appium’s development. When we began work on Appium 1.5 we had the following goals:

  • Take a hard look at the current code organization and reconceptualize the relationships between different subsections of Appium with an eye to making distinctions clearer and concerns more separate.
  • Leverage the NPM ecosystem’s best practices and break Appium up into packages based on responsibility, maintenance, etc…, whenever appropriate.
  • Rewrite the entire codebase from ES5 JavaScript to ES2015 JavaScript with async/await (and in so doing wipe away a huge source of hard-to-trace Appium bugs).
  • Standardize subprocess management. Appium is basically a combination API server and subprocess manager (we manage instruments, uiautomator, chromedriver, selendroid, etc…), and so standardizing subprocess management makes our code cleaner and more readable throughout the project.
  • Abstract common driver behavior: Appium’s IOS support and Android support really derive from the same common interface, so we wanted to factor that interface out to reduce duplication of work and boilerplate across Appium’s different drivers.
  • Clean up our build process so that we are not using a handful of different build tools in different situations. Ensure we’re running CI at the subpackage level to save time when releasing Appium.
  • Create a more friendly architectural environment for new devs to contribute to Appium. Make sure that one type of change needs to happen in one place and that READMEs abound.
  • …and many more very specific technical goals. For more information on how Appium is now put together from a developer perspective, see our developer’s overview.

Importantly, one of our goals was to not add new features, so we could be sure that our rewrite was doing its job without being clouded by the addition of new features. In essence, Appium 1.5 should work exactly the same as Appium 1.4.16, while being brand new under the hood. Of course, we couldn’t keep ourselves from making a few tweaks here and there. As a result of the rewrite, various long-standing bugs to do with session handling were fixed, we deprecated a number of server arguments, and added the ability to launch an Android intent via uri. See the full release notes for more details.

Appium 1.5 has been out in beta for several months and we’ve been actively fixing any issues with it, but being a full rewrite we do anticipate that there might be edge cases not yet uncovered by automated or manual testing, and so we urge caution before use in production CI. That being said, it’s ready for you to pound on as hard as you can! Please report any bugs at our issue tracker.

Appium’s Future

What does 1.5 mean for the future of Appium? Quite a lot, actually! Despite not having many new features, it is a significant turning point in the history of the project and sets us up for years to come. Here’s a few things we’re excited about moving forward, based on the work we’ve done with Appium 1.5:

  • Getting more individual and corporate contributors involved in an ongoing basis with Appium development. Now that the code is better organized and written in an easier-to-understand version of JavaScript, we want to actively solicit new contributors. Maybe you? Appium project lead @jlipps recently gave a talk on how to become an Appium developer—check it out!
  • Clearing away technical debt so that new drivers may be added swiftly and effectively. The landscape of mobile automation technologies is always changing. Appium wants to be the single API, the single front-end for all of those technologies. We began with Apple’s UIAutomation, added Google’s UiAutomator and then support for Selendroid. But we won’t stop there. Support for Apple’s new XCUITest framework is already in beta with appium-xcuitest-driver, and work is underway to add support for Google’s new UiAutomator 2 framework into Appium as well.
  • Fewer bugs! Far and away the biggest win from the rewrite is moving from an ugly callback-based control flow pattern to the elegant and easy-to-read async/await pattern. We look forward to fewer hard-to-understand regressions as a result.
  • Beginning to strictly follow the SemVer standard of naming releases. We hope you all will agree that having a predictable way to know when it is OK to upgrade Appium versions is more important than following the tradition of saving major version releases for “huge” new functionality. As such, you might see v2.0 or even v3.0 of Appium out sooner than you expect: this doesn’t necessarily mean there will have been as many changes as between 1.0 and 1.5—just that we have made some breaking change(s) along the way.

And as always, you can check out our Project Roadmap to see what we’re thinking about working on next, and see what we’re currently getting ready to release on our milestones page. We are very excited about the future of the Appium Project and committed to its continued development. Stay tuned for what’s to come, and as always we welcome your help and contributions along the way!

33 Likes

This is a great effort and looks like a lot of work and design went in to it! Do you have the talk https://speakerdeck.com/jlipps/how-to-become-an-appium-contributor video recorded in addition to speaker deck?

Can anybody clarify why name locator was removed?
Thanks.

2 Likes

Try to change name to accessibilityId

Can I have an alternative way to find element by accessibilityId?
Because my company application is an old, the application does’t have Ids (Android: resource-id, iOS: accessibilityId).

So it is a huge impact for me that I can’t find elements by name locator.
Probably I need to modify test codes from “name” to “xpath” if I want to update [email protected]?

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.

hello…Whats the next step after " npm install -g appium"???

Thx, afwang!

That works instead of name locator on ruby_lib!

value = “//*[@name=’” + “name you wanted” + “’]”
find_element(:xpath, value)

Start the appium server.

using the appium app??
I dont know how to start server using command prompt
can u tell me

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 tutorial
Appium samples you can find here
Appium documentation

Really a lot of topics how start work with appium you can find in google.

you can also follow some basic examples like this and then let us know in this forum, if you are struck up somewhere.

1 Like

thank you for the reply

thank you soo much…

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

2 Likes

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.

4 Likes

Agree with @Christopher_Graham.
Xpaths provides many more options to solve a complicated locator issue.