TwinTechs

Senior Vice President and Managing Partner Robi Sen launched his blog series, Building Higher Performance RIAs for Smart Phones today on InsideRIA. The series will address the challenges of optimizing software for mobile platforms.

Today’s smart phones are not only used for making calls, taking pictures, and listening to music; now people are using their phones to do business, build presentations, make quick edits to important files, and even surf the web.

Yet contrary to what the commercials would have you believe, few smart phones provide a web experience equivalent even to a netbook. In large part this is because web application developers rarely consider the memory and CPU constraints of smart phones. At the same time, an increasing number of people are using their smart phones as a secondary or even primary method for accessing the web (http://www.theiphoneblog.com/2009/03/02/iphone-mobile-browser-share-67/). This becomes problematic because most websites are slow to download, hard to navigate for mobile users, and, most importantly, often take a long time to render, which is driving more and more mobile users away from the interactivity and power that Rich Internet Applications promise to deliver. The answer to this dilemma is that developers need to create RIAs, generally using AJAX, that are specifically designed and optimized for mobile phone users. In this series of blog posts, we are going to look at how to make applications that are not only rich and powerful, but respond quickly and offer users the experience they have come to expect from the web.

Leveraging its digital media and RIA expertise, Twin Technologies is creating web applications for the mobile platform.  These are optimized for use on mobile devices and offer the  functionality of desktop software and the agility of RIAs so users can access the material they need whenever they need it.

In our app, we use the jQuery tabs plugin to provide a JavaScript-driven tabs interface. The tabs themselves are a elements, and clicking on them hooks into the jQuery tab click handler to switch different content areas to be visible. Unfortunately, when trying to automate tests with SafariWatir, the test was not working when trying to click the tabs, because SafariWatir assumes a elements to always be traditional links with HREFs.

I was able to patch SafariWatir with a HtmlElement::linkhandledbyjs method for a elements like the jQuery tabs that aren’t traditional links, but are instead handled by JavaScript. Here’s the code:

# Add our linkhandledbyjs method to HtmlElement.  This is to be used
# for "a" elements that have their click event handled by JavaScript,
# as opposed to traditional "a" elements that follow their href attr.
module Watir
  module Container
    class LinkHandledByJS < Link
      def click
        @scripter.highlight(self) do
          click_element
        end
      end
    end

    def linkhandledbyjs(how, what)
      LinkHandledByJS.new(scripter, how, what)
    end

    class HtmlElement
      OPERATIONS = {
        :id => "by_id",
        :index => "by_index",
        :class => "by_class",
        :name => "by_name",
        :text => { "Link" => "on_link", "Label" => "by_text",
           "LinkHandledByJS" => "on_link" }, # add our class here
        :url => "on_link",
        :value => "by_input_value",
        :caption => "by_input_value",
        :src => "by_src",
      }
    end
  end
end

Recently, I was tasked with writing automated functional tests for a web app we were developing. We first had to decide what platform/browser we wanted to test. The target platform for the app was actually an iPhone. As we knew of no tools to run automated functional tests on an iPhone, we decided the best approach would be to run our tests on Safari on  Mac. The tool we picked to develop the tests was SafariWatir, a port of the Watir tool to OS X on Mac driving Safari.

Everything seemed well until I realized that SafariWatir does not support retrieving elements from the browser document via XPATH. This was a significant minus. Not having XPATH support means test writers have to look up the document element they need by id, element text, or some other less flexible method. Furthermore, one cannot rely on elements always having ids or unique names defined.

Fortunately, we have XPATH to solve this problem. Safari has native JavaScript support for resolving XPATH to select document elements, so it was relatively easy to patch SafariWatir to allow us to fetch elements via XPATH:

# Add xpath support.  Example:
#
# @browser.text_field(:xpath, "/html/body/div[2]")
module Watir
  module Container
    class HtmlElement

      OPERATIONS = {
        :id => "by_id",
        :index => "by_index",

        :class => "by_class",
        :name => "by_name",
        :text => { "Link" => "on_link",
          "Label" => "by_text" },

        :url => "on_link",
        :value => "by_input_value",
        :caption => "by_input_value",

        :src => "by_src",
          path => "by_xpath"  # add xpath here

      }
    end
  end
  class AppleScripter
    # add method to allow us to fetch elements via XPATH
    def operate_by_xpath(element)

      js.operate(%|
var result = document.evaluate('#{element.what}',
                    document.documentElement,
                    null,
                    XPathResult.FIRST_ORDERED_NODE_TYPE,
                    null);
var element = result ? result.singleNodeValue : null;|,
      yield)
    end
  end
end

Now we can easily fetch almost any element in the DOM using XPATH expressions. For example, there were multiple forms on my page, all with a classification of “select-form”, and I had to find the one with an input named “userId”. This was simple using XPATH:

@browser.form(  path,
  '//form[@class="select-form"]/input[@name="userId"]/..')

Imagine trying to accomplish the same thing without XPATH.