Android Development Quick Start

Topic 1: Step by Step Installing Android Development Toolkit

Topic 2: Step by Step Writing My First Android Application

Topic 3: Android Application Architecture

Topic 4: Automating Android Browser Testing Using Android WebDriver

Step by Step: Installing the Android Development Toolkit for Windows and Eclipse

Pre-requisites:

1. Eclipse should be installed you machine (Helios 3.6 or greater)
2. Android SDK should be installed on your machine(not mandatory but recommended)

If you have Android SDK and Eclipse already installed on your machine then you can start with the steps below:

• Open the eclipse IDE
• Click on the Help menu to open the menu
• In the Help menu click on Install New Software

 

• Click on the Add button to open the Add Site dialog box
• Enter the name as “ADT Plugin”
• Enter the location: https://dl-ssl.google.com/android/eclipse/
• Click “Ok” button to fetch the necessary bits to the Available Software installation section
• Upon successful completion of previous step you will see the Developers Tools  check box
• Select the Developer Tools check box and Click the Next button
• The success in previous step will require 'org.eclipse.ui 3.6.2' else an error will be displayed. Make sure to have ‘eclipse 3.6 (Helios)’ or greater on your machine else the following error is returned: “Cannot complete the install because one or more required items could not be found.  Software being installed: Android Development Tools 16.0.1.v201112150204-238534 (com.android.ide.eclipse.adt.feature.group 16.0.1.v201112150204-238534)  Missing requirement: Android Development Tools 16.0.1.v201112150204-238534 (com.android.ide.eclipse.adt.feature.group 16.0.1.v201112150204-238534) requires 'org.eclipse.ui 3.6.2' but it could not be found”
• Click Next on the screen displayed upon successful completion of previous step a list of tools to be downloaded

• Accept the license agreement then click Finish

 

Note: If the following error message is displayed:

“An error occurred while collecting items to be installed session context was:(profile=SDKProfile, phase=org.eclipse.equinox.internal.p2.engine.phases.Collect, operand=, action=). HTTP Server 'Bad Gateway’: https://dl-ssl.google.com/android/eclipse/plugins/overlay.com.android.ide.eclipse.adt.overlay_16.0.1.v201112150204-238534.jar HttpClient connection error response code 502.”

Try one of these to resolve:

Try to repeat the installation steps (This worked for me)

If the error persists upon restart you can try eclipse Enterprise Edition to solve the issue. (Worked for many others)

• Upon successful completion restart eclipse
• When eclipse restarts you should see the 'Welcome to Android Development' dialog box 

• Select the 'Use existing SDKs' as by this time you have Android SDK already installed on your machine and click Finish button
• If the above dialog does not appear on restart you can point eclipse to the Android SDK using the following steps:
  a.   In the Windows menu click on Preferences to open the Preferences dialog
  b.   Select the Android option in the left panel 
  c. Click on the Browse button and point to the Android SDK directory
  d. Click Apply and Ok button to complete the configuration

This completes the installation and configuration of the eclipse ADT plugin and we are all set to write our first Android application.

 

Step by Step writing My First Android Application

Pre-requisites:

• Eclipse should be installed you machine (Helios 3.6 or greater)
• Android SDK should be installed on your machine
• ADT plugin should be installed (Step by Step: Installing the Android Development Toolkit for Windows and Eclipse)

If the above three requirements have been fulfilled then you are all set to write your first application. Just follow the steps mentioned below:

• Open eclipse
• Click File --> New --> Project to open the New Project dialog

• Select Android Project and then Click the Next button
• Enter the project name as MyFirstAndroApp set the project location and then Click Next button

• Select the API (Android 4.0.3) and Click the Next button

• Name the application as MyFirstAndroApp, put the package name com.test.andro.base (you can choose your favorite names and alter the code snippet provided below)
• Create Activity named ‘MyFirstAndroAppActivity’, Minimum SDK, and Click Next button

• The application folder structure should be displayed as above and the following code snippet is generated:

• Modify the code to display a simple text message:

Import the TextView class (android.widget.TextView)

Create a new TextView object ‘tv’
Set the text to be displayed
Pass the ‘tv’ to the setContentView() method

• Save the above changes 

Note:  In order to run the application you need to create a virtual device using Android Virtual Device (AVD) manager as shown below:

• Run the application Run As --> Android Application the logs will read as follows:

[2012-01-31 16:07:04 - MyFirstAndroApp] ------------------------------
[2012-01-31 16:07:04 - MyFirstAndroApp] Android Launch!
[2012-01-31 16:07:04 - MyFirstAndroApp] adb is running normally.
[2012-01-31 16:07:04 - MyFirstAndroApp] Performing com.test.andro.base.MyFirstAndroAppActivity activity launch
[2012-01-31 16:07:04 - MyFirstAndroApp] Automatic Target Mode: launching new emulator with compatible AVD 'DefaultAndroidEmu'
[2012-01-31 16:07:04 - MyFirstAndroApp] Launching a new emulator with Virtual Device 'DefaultAndroidEmu'
[2012-01-31 16:07:30 - Emulator] emulator: WARNING: Unable to create sensors port: Unknown error
[2012-01-31 16:07:30 - MyFirstAndroApp] New emulator found: emulator-5554
[2012-01-31 16:07:30 - MyFirstAndroApp] Waiting for HOME ('android.process.acore') to be launched...
[2012-01-31 16:08:30 - MyFirstAndroApp] HOME is up on device 'emulator-5554'
[2012-01-31 16:08:30 - MyFirstAndroApp] Uploading MyFirstAndroApp.apk onto device 'emulator-5554'
[2012-01-31 16:08:30 - MyFirstAndroApp] Installing MyFirstAndroApp.apk...
[2012-01-31 16:09:08 - MyFirstAndroApp] Success!
[2012-01-31 16:09:08 - MyFirstAndroApp] Starting activity com.test.andro.base.MyFirstAndroAppActivity on device emulator-5554
[2012-01-31 16:09:09 - MyFirstAndroApp] ActivityManager: Starting: Intent { act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] cmp=com.test.andro.base/.MyFirstAndroAppActivity }

• The virtual device is loaded and the application is pushed to the Android Virtual Device. The output screen looks like this:

SOA: Service Oriented Architechture

The hottest developments of the software services market have been revolving around Service Oriented Architecture and Cloud Computing off late. Which of these was the predecessor might be debatable and contextual but both have been creating buzz and traction in the market. History of these might be traced as back as in 1950's but the real growth/development of these principles started post dot com burst in the past decade. Every leading vendor in this space is trying to come up with new offerings and even there are people who are trying to re-brand there services as Cloud or SOA based as it makes it lot easier to sell. So it is very important to understand the real SOA and Cloud offerings, advantages, and differences with other competing technologies and principles.

Service Oriented Architecture

 A simple one line definition of Service Oriented Architecture is follows: SOA represents a collection of services that communicate with each other to perform defined and self contained tasks as a whole or as individual input/output units. It is necessary for the services contributing to the SOA be independent of each other’s state and context. Potentially these create mutually fulfilling production/consumption units that are contributors to a larger business flow.

The success (technical) of a SOA based application largely depends on the connection/communication between the underlying collection of services. Currently the most effective and common communication mechanism used is WebServices that use XML to talk to each other. A typical communication example of service oriented architecture would typically be as follows:

Two essential entities in a SOA based application are the service provider and the service consumer. The service provider creates a description of its services using a language, such as the Web Services Description Language (WSDL). This description/definition is then published to the directory of services. The directory of services can be UDDI based or ebXML registry based. The service consumer queries the directory of services to determine the details required for invoking the services. These details are extracted from the WSDL and passed to the service consumer. With these details the consumer understands what is should be the request format for the required service and also the format of the response from the service provider. After getting the details of the service request and response the consumer sends the service requests to the provider using the WSDL. The provider performs valid actions on the requests and sends appropriate responses as declared in the definition of the service.


The primary advantages of using the services oriented architecture are:

---> Loose coupling of business components

---> Helps increase agility in the development phase

---> Helps in decreasing the time to market

---> Helps increase the usage of external services for business growth

---> Helps manage business workflows

---> Easy customizations for diverse audience

---> Enhanced adaptation capability in the overall workflow

---> Reduction of production and maintenance cost

Even though SOA has so many advantages but it not necessary to be the best solution for all business/application development scenarios. It is important to understand and know the scenarios where SOA may not be desirable solution design. Few examples where SOA may not be used are:

---> Stand alone applications which are not distributed in nature

---> Applications that do not require request/response based design

---> Applications with short lifespan as the ROI may not be fully recovered

---> Applications where re-usability is not in the scope

---> Applications where loose coupling is not required

Comparative analysis of the WebDrivers’ Drivers

While working with selenium webdriver you have an option to choose from multiple webdrivers, such as HtmlUnitDriver, FirefoxDriver, InternetExplorerDriver, ChromeDriver and OperaDriver. Each one of them is a separate implementation of the WebDriver interface provided by Selenium. All of them have unique advantages and disadvantages because of the implementation differences for catering to different requirements. It is good to know the comparative advantages and disadvantages of each one before picking one of them.

The first major point to note is that there are two groups of driver implementations. One of those that invoke the actual browser installed on your system and the other that emulates the behavior of another browser. FirefoxDriver, InternetExplorerDriver, ChromeDriver and OperaDriver invoke the actual browser installed on the machine; however the HtmlUnitDriver emulates other browsers JS behavior. 

HtmlUnitDriver

 

HtmlUnit is a java based framework for testing webApps basically a wrapper around ‘HttpClient’ by Jakarta. HtmlUnit provides UI-Less emulation of browsers to test web applications. The HtmlUnit APIs let you do the typical functions performed in an actual web browser, such as click links, fill forms, invoke web pages, submit values etc. HtmlUnit supports java script and complex AJAX libraries. Javascript is disabled in the HtmlUnitDriver by default, however if it can be enabled if required. The mechanism to enable javascript with the HtmlUnitDriver is as follows:

HtmlUnitDriver MyhtmlDriver = new HtmlUnitDriver();

 MyhtmlDriver.setJavascriptEnabled(true);

OR

HtmlUnitDriver MyhtmlDriver = new HtmlUnitDriver(true);

When enabled, the HtmlUnitDriver emulates the java script behavior of Internet Explorer by default. However we can direct the HtmlUnitDriver to emulate the JavaScript behavior of the browser of our choice by invoking the constructor that accepts the browser version. This can be done as follows:

HtmlUnitDriver MyhtmlDriver = new HtmlUnitDriver(BrowserVersion.Firefox_2);

Internet Explorer Driver

 

The IE driver class ‘InternetExplorerDriver.class’ is located at ‘\org\openqa\selenium\ie\’ directory in the ‘selenium-server-standalone-2.7.0.jar’. To use the InternetExplorerDriver all you need to do is to have the selenium-server-standalone-2.7.0.jar in your CLASSPATH.  The IE driver runs only on windows and supports both 32-bit and 64-bit operations. Depending on the thread that instantiates the InternetExplorerDriver corresponding version of the IE is launched i.e. if the thread instantiating driver is running in 32-bit then the 32-bit version of the IE will be launched and if the thread instantiating driver is running in 64-bit then the 64-bit version of the IE will be launched.

The Internet Explorer driver uses the native or OS-level events to perform various functions on the browser, such as inputs from keyboard and mouse. This approach has both advantages and limitations both. The advantages are that it bypasses the limitations of the Javascript sandbox but there can be issues like the browser window under test might be out of focus.

Firefox Driver

 

‘selenium-server-standalone-X.X.X.jar’ contains all the drivers implementing the WebDriver interface of selenium. Hence the 'FirefoxDriver.class' can be found in the ‘\org\openqa\selenium\firefox directory in the selenium-server-standalone-X.X.X.jar. The driver when instantiated is added as an extension to the firefox profile. You can specify the profile with which you want to load firefox session. If no profile is specified then the driver creates an anonymous profile by default. 
A profile can be created for the firefox driver as follows:

FirefoxProfile myProfile = new FirefoxProfile();

Multiple operations can be performed on the newly created profile, such as:

myProfile.addExtension(File);
myProfile.clean();
myProfile.getPort();
myProfile.setPort(int port);
myProfile.enableNativeEvents();
myProfile.setPreference(String key, String value); etc...  

After creating the your profile you can pass the profile while creating the driver instance as follows:
WebDriver myFireFoxDriver = new FirefoxDriver(myProfile);


This driver is faster than the InternetExplorerDriver and executes the test in real Firefox web browser.

Selenium WebDriver Interface

The interface WebDriver represents the main interface for testing a web browser instance. If you are using Selenium 2 then it is highly recommended to use the WebDriver instance because of the benefits suggested in my previous posts.
This interface provides most of the basic requirements for testing a web application. Normally the testing of a web application requires either one or all of the following three functions:

· Controling the browser
· Selection of WebElement
· Debugging aids
The methods in this class provide solutions to the requirements in all the three categories mentioned above:

· Control of the browser:

• get(): Loads the web page rendered by the URL string passed to this method. Similar results can be obtained by using WebDriver.Navigation.to(String)
• navigate():Loads the web page rendered by the URL and access browser history
• close(): Closes the ‘Current’ browser window
• quite(): Closes ‘All’ browser windows associated with the webDriver instance
• switchTo(): Changes current window and redirects all commands to the new ‘current’ window (example: switchTo().window(String))
• manage(): Enables access to browser menu items, such as add cookies, logs etc

· Selection of WebElement:

• findElement(): Returns the first ‘Webelement’ found
• findElements(): Returns all the ‘WebElements’ found in the current web page

· Debugging aids:

• getCurrentUrl(): Returns the current URL loaded in the browser session
• getPageSource(): Returns HTML source of the current page loaded in the browser
• getTitle(): Returns the title of current page
• getWindowHandle(): Return unique string identifier of the current window in the driver instance
• getWindowHandles(): Return identifiers of all the windows in the driver instance

Agile: Identifying when and what to automate

Identifying when and what to automate is critical to success of any automation endeavor. Before we can identify these when and what, it is important to identify the challenges that come across in automation:

• The initial builds coming out in a sprint\iteration, tend to have defects, mostly blockers not allowing automation script development to proceed.

• In the case of sprints\continuous integration builds do not have fully developed features initially. There maybe\are significant changes with subsequent builds, including naming conventions for UI elements which results in a lot of rework for the automation team.

• Testing of screen\UI layout is nearly impossible\very costly with automation and requires at least one round of manual testing.

• Generally manual test cases are very granular and detailed. Manual cases include a lot of positive and negative tests so that the feature is thoroughly tested. Automating all of them as they are provides very little business value. Automation testing requires automation scenarios that are mostly business\user scenarios. Automation scenarios can be developed from the granular manual test cases. The granular manual test cases should be covered in automation only for regression testing.

• Automation should be implemented selectively and the shelf life of the product should be an important factor in making this selection. It is important to understand that automation is not required everywhere and every time.

The summary of the above points for test automation is as follows:

• Automation should begin only when the application is ‘automation ready’. The efficiency of automation effort is directly proportional to the stability of the application\functionality.

• For majority of the applications, 100% automation is not possible to achieve. Even if it is doable, it does not provide ROI/business value.

The proposal is as follows:

Test cases should be executed manually in current sprint\iteration. During the current sprint the test scenarios which are suitable for automation should be queued for automation in the automation backlog. The exercise of selection of the automation candidates/scenarios should involve automation team members. The items in the backlog should be prioritized and then picked up for automation.

WebDriver: The better tool of all opensource web handlers

Having played with Selenium RC the predecessor and WebDriver the successor it is fairly easy to judge the better of two. The quantum of difference is much more than I expected. Here are the reasons why I say that webDriver is supreme by a huge margin:

WebDriver is the enhanced and superior tool from the selenium community for automating web application testing. It provides an easy to use API that is easier to explore and understand. It is far more effective than the Selenium-RC (1.0) API. Creation and maintenance of automated tests is much easier with the webDriver. It can be assimilated in your framework or a new framework can be created using the webDriver. The webDriver is self contained and does not have dependencies that impede your development or cause intermittent issues due to unwanted junctions. The overall impact of this is increased stability. You can use the webDriver with android and iphone as well. Start setting up your WebDriver project if you haven’t already started it.