<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Selenium – mobile</title><link>https://trunk--polite-jelly-cc0866.netlify.app/tags/mobile/</link><description>Recent content in mobile on Selenium</description><generator>Hugo -- gohugo.io</generator><lastBuildDate>Tue, 24 Dec 2013 00:00:00 +0000</lastBuildDate><atom:link href="https://trunk--polite-jelly-cc0866.netlify.app/tags/mobile/index.xml" rel="self" type="application/rss+xml"/><item><title>Blog: Android and iOS Support</title><link>https://trunk--polite-jelly-cc0866.netlify.app/blog/2013/android-and-ios-support/</link><pubDate>Tue, 24 Dec 2013 00:00:00 +0000</pubDate><guid>https://trunk--polite-jelly-cc0866.netlify.app/blog/2013/android-and-ios-support/</guid><description>
&lt;p>TL;DR: We’re retiring Selenium’s own AndroidDriver and iPhoneDriver in favour of any of &lt;a href="http://selendroid.io/">Selendroid&lt;/a>, &lt;a href="http://ios-driver.github.io/ios-driver/">iosdriver&lt;/a> and &lt;a href="http://appium.io/">Appium&lt;/a>. If you’re using one of Selenium’s own mobile drivers, please evaluate one of these alternatives.&lt;/p>
&lt;p>The longer version:&lt;/p>
&lt;p>In 2007, Steve Jobs &lt;a href="http://www.apple.com/pr/library/2007/01/09Apple-Reinvents-the-Phone-with-iPhone.html">announced the iPhone&lt;/a> and changed the mobile Web from a curiosity to something the mainstream wanted and used. Current trends suggest that mobile Web usage will surpass desktop usage in the not too distant future. Which is a long way of saying the mobile Web is going to be a big part of the future of your sites and that it’d be an extremely wise idea to test them on mobile devices.&lt;/p>
&lt;p>The Selenium project responded to the rise of the mobile web by working to produce WebDriver implementations for both iOS and Android. The first lines of the iPhoneDriver (which also worked on the iPad) were added to the project early in 2009. The AndroidDriver was added in June 2010, and was primarily developed by engineers at Google. To this day you can download the official Android SDK and find “&lt;a href="http://android-developers.blogspot.com/2011/10/introducing-android-webdriver.html">Google WebDriver&lt;/a>” as one of the optional extras you can download.&lt;/p>
&lt;p>After the initial work on the mobile drivers, something interesting happened. Experimental extensions and modifications to the drivers were made outside of the selenium project. The first one of these that I was involved with was “&lt;a href="https://code.google.com/p/nativedriver/">nativedriver&lt;/a>“. This took the novel approach of allowing users to interact with the native UI of the phone, be it Android or iOS, using the familiar WebDriver APIs. The first time I saw it, I thought it was madness, but the engineers working on it soon convinced me that it made sense. And guess what? They were right.&lt;/p>
&lt;p>Sadly, after proving the idea was viable and workable, the NativeDriver project ran out of steam, but it set the scene for three projects that have taken the idea and run with it to create remarkably capable pieces of mobile testing software: Selendroid, iosdriver and Appium. All three of these allow a tester familiar with the WebDriver APIs to test mobile apps on iOS and Android. Not only native ones, but also hybrid or pure web-based ones too. They’ve recently been joined by the &lt;a href="http://winphonewebdriver.codeplex.com/">Windows Phone WebDriver&lt;/a>, which allows testing of mobile web apps on WinPhone 8.&lt;/p>
&lt;p>All of these projects have something in common: they’re far more active, more capable and have pushed further than the equivalent code in the main selenium project. In fact, some of the members of the selenium team that contributed to both AndroidDriver and iPhoneDriver are now also working on those other projects. There’s &lt;a href="http://sauceio.com/index.php/2013/09/the-mobile-json-wire-protocol-workshop/">work being done&lt;/a> to &lt;a href="https://code.google.com/p/selenium/source/browse?repo=mobile">maintain interoperability&lt;/a> between the different drivers, allowing users to chose which framework is most appropriate for their needs without fear of their tests needing major rework.&lt;/p>
&lt;p>This means that keeping the existing Android and iPhone drivers within the Selenium project isn’t helping our users. The alternatives are better, and keeping “official” drivers within the project muddies the water. Worse, the selenium developers are slow at making fixes to those drivers, which is incredibly frustrating for everyone involved. Because of this, the Selenium project has deleted the code for those drivers from its repository and we recommend you evaluate and use one of the alternatives.&lt;/p>
&lt;p>Of course, the code will still live in our repo’s history, so if you’d like to build them yourself, then it’s still possible. The last version with the iPhoneDriver is &lt;a href="https://code.google.com/p/selenium/source/detail?r=ef9d5787e5e136ecb4a31b0cf53a1fd17e252cf3">ef9d578&lt;/a>, and the last one with the Android source is &lt;a href="https://code.google.com/p/selenium/source/detail?r=00a3c7df9fb4109e1f99b5f7bee5f5df74fb876a">00a3c7d&lt;/a>. We’ve uploaded a version of the AndroidDriver built from that revision to the downloads page to save you having to do so yourself.&lt;/p>
&lt;p>These changes do not mean that we don’t support mobile as a project. It just means that we support the best implementations of mobile WebDriver, and those aren’t written as part of the Selenium project.&lt;/p></description></item><item><title>Blog: Mobile WebDriver</title><link>https://trunk--polite-jelly-cc0866.netlify.app/blog/2013/mobile-webdriver/</link><pubDate>Wed, 28 Aug 2013 00:00:00 +0000</pubDate><guid>https://trunk--polite-jelly-cc0866.netlify.app/blog/2013/mobile-webdriver/</guid><description>
&lt;p>Although the WebDriver APIs started life as just a mechanism for automating web browsers, over the past few years it has been extended to also work on mobile devices. Projects such as Appium, iosdriver, and Selendroid have all shown that this approach works, and works well. On the Web, if you start using Selenium WebDriver with one browser (Firefox, for example), it’s easy to switch out the browser for another one (such as Internet Explorer or Chrome). It’d be nice to have a similar option for mobile, switching from one automation framework for Android to another.&lt;/p>
&lt;p>As part of the Selenium 3 work, we have started working on a test suite to help ensure this level of interop between &lt;a href="http://appium.io/">appium&lt;/a> and &lt;a href="http://ios-driver.github.io/ios-driver/">iosdriver&lt;/a>, and appium and &lt;a href="http://selendroid.io/">selendroid&lt;/a>. To kick start the process, the primary authors of each of those tools, as well as others including David Burns representing the &lt;a href="https://developer.mozilla.org/en-US/docs/Marionette">Marionette&lt;/a> project (Mozilla’s implementation of WebDriver for Firefox and Firefox OS) and Simon Stewart, the lead of the &lt;a href="http://seleniumhq.org/">Selenium&lt;/a> project, have spent the past two days locked in a small room in Mozilla HQ, London. They’ve taken this time to work out the areas where each of their projects didn’t align and agreed on a way to ensure a level of interoperability. There was only a minimal quantity of blood and tears, but plenty of hard work.&lt;/p>
&lt;p>The &lt;a href="https://docs.google.com/document/d/1rnE13aGCaRiri01hti7j1jWDuPvQHT8aao4bHhEGz8Y/edit">agenda&lt;/a> for the past two days can be found here, and the &lt;a href="https://docs.google.com/document/d/1yXXsQo3z7lUVl3ZthAx39h4xBlF62x7q_NZd3NA9jnU/edit">minutes&lt;/a> are also available.&lt;/p>
&lt;p>As we speak, work has started on a shared test suite, hosted in a &lt;a href="https://code.google.com/p/selenium/source/checkout?repo=mobile">repo&lt;/a> in the selenium project’s Google Code page. Please, feel free to come along and join in!&lt;/p></description></item></channel></rss>