Android app store download reaches 10,00,00,00,000

To put it into perspective, the Android Market hit 1 billion downloads in July 2010 after launching in 2008, and later surpassed the 6 billion mark during July 2011.

Of course, one has to throw in the necessary comparison to iTunes. The Apple App Storereached 10 billion downloads as of January 2011 after launching in July 2008.

To celebrate and reward Android customers, Google will be making select paid apps available for 10 cents each. A new set of apps will be up for promotion each day for the next 10 days.


Connect to a PHP Server using HTML5 WebSockets

Before HTML5 introduced WebSockets, you had to rely on specialized technologies like Java applets (remember those?!) or, more recently, Flash. I covered some of the challenges of working with WebSockets in this early stage of development in my Making HTML5 WebSockets Work article.

In this article, we’ll be utilizing WebSockets to write a kind of automated web chat, where the other party is a machine of great intellect, called “Multivac”, named after the Chatbot demo of the Google phpwebsocket project.

As mentioned in the conclusion of my last article, we will be using the lemmingzshadow php-websocket library because it supports the newer draft-ietf-hybi-thewebsocketprotocol-10 (HyBi-10) WebSockets protocol. You’ll also need a web server that supports PHP, such as Wamp or Apache, and a fairly up-to-date browser; I would recommend google Chrome 14+ or Firefox 6+ as the best choices.

WebSocket Connections

When you see all of the files involved in managing the WebSocket connections, it quickly becomes apparent why it’s not advisable to write your won server-side code from scratch, unless socket communication protocols and other low level operations really float your boat. Nonetheless you should have some familiarity with the files that you’ll be working with; some of them, you’ll have to modify, others, are better left alone! Here’s a rundown of what’s contained in the lemmingzshadow php-websocket download:

  • server.php: Creates the WebSocket server instance, sets server properties, and registers the application to be called by the client component.
  • SplClassLoader.php: Implements the technical interoperability standards for PHP 5.3 namespaces and class names.
  • Connection.php: Manages the WebSocket Connection. The hybi10Decode() and hybi10Encode() functions are located therein.
  • Server.php (upper case ‘S’): It’s the “real” server which monitors the port for client requests.
  • Socket.php: Creates and maintains references to sockets.
  • Application.php: An abstract class that contains the getInstance() method, which ensures that applications are created as singletons, as well as the onConnect(), onDisconnect(), and onData() abstract methods which all applications must implement.
  • ChatApplication.php: A fully functional simple webchat application.
  • DemoApplication.php: A Websocket-Server demo and test application. It can either echo data back to the client or execute a user function.
  • EchoApplication.php: Even simpler than the demo app, this class just parrots back whatever data is sent to it. This is the class upon which our Multivac app will be built.
  • chat.html: The client component of the chat application.
  • client.php: A basic WebSocket client that runs from a command line.
  • echo.html: The client component for the echo application. This is the client-side component that we will be modifying today.
  • index.html: An extremely basic WebSocket server test console.
  • client.css: A stylesheet to spiffy up the browser UI.
  • client.js: A JavaScript template with everything you need to create and communicate with a WebSocket.
  • jquery.min.js: A local minified jQuery script – useful for local development.
  • json2.js: A Douglas Crockford JSON parser from

Here is how the folders should be structured under your server’s web document root:

Image 1

The Client Page

Open the echo.html page in your favorite HTML editor and you’ll see that most of what we need is already done for us. As it stands, when you enter text in the Message textbox and click the Send button, the data travels to the server.php page, is decoded, re-encoded and sent back to the browser to display in the log


not very exciting to be sure, but it does demonstrate that all of the basic processes are functioning just as they should. What we’ll do is tweak the code so that the server sends back a response based on our request. The object of this exercise is to familiarize ourselves with what code to change to develop an application based on existing code.

With regards to the client page, the first thing we’ll do is rename it to something more instructive. Let’s call it “multivacClient.html”.

Next, we’ll add a couple of new CSS classes so that we can differentiate our requests from the server responses:

.human { color: blue; }
.computer { color: green; }

We can now update the log function to accept a class argument. It’s called clazz because class is a reserved word:

var log = function(msg, clazz){ $('#log').append('' + msg + '
') };

A second way to differentiate the client requests from the server responses is to prefix them with a direction arrow: hence, requests have a right facing arrow (>) while the responses have a left facing one (

log('> ' + msg, 'human');

…and socket.onmessage():

log('< ' +, 'computer');

Another change that I would make is to update the code that creates the WebSocket object. I am not a fan of browser sniffing, so I would replace the existing if statement with the following:

var Socket = window.WebSocket || window.MozWebSocket;

		$('#log, input, button, span').fadeOut("fast");

You need a browser that supports WebSockets such as Google Chrome.

	} else {

The Application File

Now it’s time to work on the EchoApplication.php file. Open it up and save it as “MultivacApplication.php”. Rather than take the received data and spit it right back, we’ll send it to our process() function:

    public function onData($data, $client)
        foreach($this->_clients as $sendto) {
            $this->process($sendto, $data);

The process function evaluates the $action parameter and sends back the appropriate response. I will admit that the AI component of this app is a little weak, but IBM wouldn’t lend me the code for Watson:

  private function process($sendto, $action) {
	    case "hello" : $sendto->send("hello human");                        break;
	    case "hi"    : $sendto->send("greetings human");                    break;
	    case "name"  : $sendto->send("my name is Multivac, super-genius."); break;
	    case "age"   : $sendto->send("I am far too vain to say");           break;
	    case "date"  : $sendto->send("today is ".date("Y.m.d"));            break;
	    case "time"  : $sendto->send("server time is ".date("H:i:s"));      break;
	    case "thanks": $sendto->send("you're welcome");                     break;
	    case "bye"   : $sendto->send("bye");                                break;
	    default      : $sendto->send($action." not understood");            break;

The server.php File

This file is where you would set your basic initializing details such as the server name or IP, port number, as well as your application name and class. There’s also an added security feature to check the “Origin” header in WebSockets handshake. Though it could still be potentially spoofed, browsers always add the Origin of the page which initiated WebSockets connection:

$server = new \WebSocket\Server('localhost', 8000);

// server settings:

$server->registerApplication('multivac', \WebSocket\Application\MultivacApplication::getInstance());

Note that the application name (‘multivac’) must match the Socket call in your JavaScript code:

var socket = new Socket('ws://localhost:8000/multivac');

Running the Application

Open a command window and type the following to launch the WebSocket server process and register our application:


Here’s what I entered in my Windows DOS prompt:

C:\Program Files\wamp\bin\php\php5.3.8>php.exe "C:\Program Files\wamp\www\phpwebsocket\server\server.php"

If all went well, you should see a confirmation message that says “Server created”.

Start up your web server and make sure that PHP is enabled and working.

Launch your web browser and enter the URL of the multivacClient.html page:


Look for the green online indicator in the top-right corner to confirm that you are connected to the WebSocket server.

Try some commands, then click the Disconnect button when you’re done.

Image 2


There’s a lot that can go wrong when a technology is made up of so many interconnected parts, but hopefully you’ve learned enough here today to avoid the most common pitfalls. WebSockets is definitely something to watch to see where it leads. I for one can’t wait!

Make HTML5 mobile appS

It’s actually not hard. There are a number of companies that offer the ability to create your own app for a minimal fee, which is great for small businesses looking to stay relevant in this increasingly mobile world. Or if you just have a lot of time on your hands.

Take Conduit. The company made its money creating branded toolbars found on your browser. But over the past few months, it has been expanding into the mobile world with a free servicethat allows you to build an app and mobile Web site in minutes. It’s part of a planned shift by the company to build its consumer awareness after spending years serving other businesses in a white label capacity.

“We’re trying to give companies a tool to really go mobile,” said Ori Lavie, vice president of product strategy at Conduit Mobile. “It’s sometimes a difficult struggle.”


You can select how many categories, or tabs, you want on your app.

(Credit: Conduit)


I’ve tried the service, and it’s pretty simple to use. The best part: it’s completely free. Conduit has a team set up that will take you through the submission process and it will even pay your fee to get the app up in the various mobile app stores. As with everything in life, there are some catches, and Conduit’s offer is a limited-time promotion.

For the purposes of testing, I decided to build a mobile application out of my personal Tumblr blog,Annoying PR. Conduit’s browser-based tool allowed me to select from a set template for how the app would look–including different appearances for each platform.

To add content to the app, I typed in the address for my blog, which drew in the feed. I also added my Twitter and Facebook accounts.

In terms of the look, I was able to change up the color scheme. I also chose a background, splash page, screenshots, and a logo for the app. You can pick images from a provided library of upload your own images.

There’s also an option to run mobile ads on the app, in which Conduit and the customer would split any potential revenue. I opted not to run ads on my app.


Potentially get your app on multiple devices.

(Credit: Conduit)


The tool worked very much like WordPress, Tumblr, or any other Web site or blog creation service, and is fairly intuitive.

Within minutes I had an HTML5 mobile Web site built. The site worked a lot like an app, especially after I chose to put it on my iPhone‘s home screen. The address, which uses a Conduit-hosted URL, isn’t exactly the catchiest.

(Point your mobile browser here to check out the HTML5 site.)

Of course, I care more about getting it into app form, which is where there are complications. Yes, Conduit will offer to take your app through the submission process–all while covering your fees–but only after its compliance team deems the app ready. It can kick back the app if it lacks content or uses copyrighted or offensive material.

Once the app is ready, an option comes up that allows you to take advantage of this promotion.

In my case, the app wasn’t ready for primetime. I got a message from a Conduit team member saying my app had insufficient content and suggested I add more categories and images. I added more content from CNET’s YouTube page and a contact tab and resubmitted it. I’m hoping for more luck the next time around.

Lavie said the review process by Conduit may take a few days and getting approval from iTunes and Samsung’s Bada may take a few weeks. Beyond iOS, Android, and Bada, a separate Nokia app is created as well. It also creates a Web app for Microsoft’s Windows Phone and BlackBerry, although the site says native apps were coming soon.

Its simple format means this is a better option for businesses without a lot of technical resources to pursue their own app. Large companies and major brands with money behind them are better off building an app from scratch, since it’ll likely be able to take more advantage of the device. There’s a reason why major companies are pouring money into building apps–they want to be a permanent fixture on a device you stare at dozens of times a day.

It’s not just businesses; ambitious individuals are also getting into the app game. Lavie said opera singer Andrea Bocelli will have a personal app up through Conduit, as well as two NFL players who haven’t yet launched their programs yet. He added he expects bands and DJs to be interested in the capability.

It doesn’t have to be small business or celebrities. Conduit’s offer removes any barriers and complications, meaning anyone with something meaningful to share could conceivably build an app. So this is my challenge to readers: use Conduit to build your own app. If I get enough responses, I’ll highlight them in an upcoming Inside Apps column.

10 Media Players(console) for Linux

This is one of the best, feature-rich players for console. Build using ncurses and thus offering a text user interface, CMus has several view modes, organizes your music by artist/album, provides playlists and a library view, a filebrowser, it allows searching, scrobbling via this script, and it uses Vi-like keyboard shortcuts. A complete review can be found here and a guide to using it here.

CMus is a powerful, feature-rich music player for the terminal which uses the ncurses library

mp3blaster is one of the most popular music players for the terminal out there. It uses the ncurses toolkit, and has features like grouping of tracks, playlists, shuffle and repeat modes.

MOC stands for Music on Console and it is a twin-panel music player with the file browser to the left and the playlist to the right. MOC is built upon ncurses and allows shuffle, repeat, volume control.

MOC running in Ubuntu 11.10

Another ncurses-based music player for the terminal, Herrie is a minimalistic player that comes with playlists, support for various audio files, including Ogg and MP3, jump to next/previous song.

This is mplayer, the famous video/audio player and converter. However MPlayer can also be used as a command-line audio player, and it supports all the formats out there, including Ogg, FLAC, MP3 or WAV.

Self-described as “Sound eXchange, the Swiss Army Knife of audio manipulation”, SoX is actually a powerful command-line audio manipulation tool which can also be used as a music player, using the command play music_file.

Written in Python, PyTone is yet another command-line audio player. Simple and clean, it supports formats like MP3 or Ogg.

Another program written in Python, PyRadio is able to play Internet radio inside the terminal. To use it, download it from here, unzip the archive and then run the ./pyradio script.

With preselected stations, PyRadio is able to play Internet radio inside a terminal

This little command-line tool is included in the vorbis-tools package and is able to reproduce Ogg and FLAC. It’s very basic, yet very fast and useful for quickly listening to songs which are encoded in a free format.

Just as ogg123, only that mpg123 plays the MP3 format.

Android antivirus freeware useless

According to a study released last Thursday, German security institute AV-Test said out of the seven popular free antivirus it tested–namely Zoner AntiVirus Free, Bluepoint Antivirus Free, Kinetoo Malware Scan, Privateer Lite, Antivirus Free by Creative Apps, GuardX Antivirus and LabMSF Antivirus betat–only Zoner AntiVirus Free achieved a “respectable result” in detecting 8 of 10 malware samples.

Another three–BluePoint, Kinetoo and Privateer Lite–managed to catch one malicious app while the rest failed completely, the report noted.

By comparision, the two paid antivirus apps tested–F-Secure Mobile Security and Kaspersky Mobile Security–spotted at least 50 percent of all malware samples, it added.

The malware samples were used because they were the most frequently identified virus picked up by the institute’s analysis system, which uses 30 scanners to analyze the installation packages, AV-Test stated. The apps were run on a Samsung Galaxy Tab running Android 2.2.1 for the test. Quoting figures from Google, the report stated that 45.3 percent of total devices run on Android Froyo 2.2 as of Oct. 3, 2011.

“The number of installations, which is given on the Android Market Web site, shows that many users trust these free apps, although they do not offer a reliable protection,” said the report’s co-authors Hendrik Pilz and Steffen Schindler.

Among the free antivirus tested, Antivirus Free had the most installed base, which stands at between 1,000,000 and 5,000,000, and was rated 4.5 out of 5 based on 41,375 ratings by users. Even the two with the least installed base of between 1,000 and 5,000–LabMSF and Privateer Lite–were rated 4.3 out of 16 ratings and 4.5 out of 28 ratings, respectively.

Both Pilx and Schindler spoke out against downloading these freeware however, saying it endangers users.

“The circulation of obviously near to useless security apps endangers those who trust them and install [these] apps from third-party app markets without further suspicion,” they stressed.

One Android user ZDNet Asia spoke to, Max Yam, admitted he had not installed any antivirus on his Android handset, adding that the awareness of antivirus for mobile phones is still low.

The Singapore-based designer also said while he is not sure if free Android antivirus are less secure, he would purchase an antivirus software if it costs less than US$5.

HTML5 and Mobile Web

By forcing Web developers, and ultimately Adobe, out of the Flash business, Apple made HTML5 apps better. That’s good for Safari users, but it’s also good for users on other Web platforms, like Android. If there’s a truly good universal platform for online apps, it stands to reason that the smart developer will build apps for it, since this way the app will be available to the largest number of users. Right?

Furthermore, now that Adobe has HTML5 religion, the company is releasing high-quality HTML5 developer tools, migrating its Flash developers over to the new platform. So we should be about to see a flood of new Web-based mobile apps.

All this appears to be just as Apple intended: Steve Jobs’ campaign to rid the world of Flash is succeeding. The Web is getting better apps and the Web-browsing experience on Apple’s mobile devices is getting better.

But this could be bad news for Apple’s lucrative App Store business. While Apple takes a 30 percent cut of all app sales through its store (still the only way for consumers to get apps), Apple gets 0 percent of “Web apps” loaded up through the browser. The better HTML5 gets, the less developers will write apps, less money Apple will make, and the less unique the iPhone and iPad will be.

I talked with the CEO of a Web company who is excited about the advances in HTML5 because he sees a future in which the devices and operating systems are on the same level. It’s a world where new products, like Microsoft Windows phones, can come along and be instantly competitive. And where companies like his can have a shot at dominance in their market niche after building only one app, the HTML5 version.

In other words, Apple, in pushing the world toward HTML5, is killing its own golden goose.

Or is it?

The counter argument comes from another CEO, one who’s built a successful business around both Web services, and software for mobiles and traditional computers. He says that apps are here to stay, because the “lowest common denominator” strategy (using the Web) doesn’t cut it for developers ultimately, nor for consumers, and most importantly not for the tech megaliths behind mobile operating systems: Apple, Google, and Microsoft.

The challenge for apps developers, my source explains, is getting their apps seen for more than a fleeting moment. For those making Web apps, there’s just no good way. Even a good review of a Web app on a popular site has only a temporary impact. The way to get your app in front of potential customers, time and again, is to get it featured in an app store.

You do that by building an app that highlights its unique hardware capabilities–the features that the hardware company is using to sell the product. These will likely be features that you can’t access today, or in the foreseeable future, with a Web app. This isn’t because HTML5 won’t advance, but because the device and OS manufacturers will always do their best to keep their products somewhat ahead of the lower-common-denominator Web platform. It is how they sell products.

So if you make a mobile app, you want to feed into that trend, because it will feed you.

And what about HTML5? It’s good for apps that don’t depend on the app stores for sales. The means enterprise apps, essentially. HTML5 has its place in consumer apps, too, including inside many successful mobile apps. But not for the core features or the main UI.

Relying on HTML5 to quickly get to broad compatibility across the mobile landscape is a trap, my guy says. To succeed, you need to tackle each platform separately. In fact, he says, you might want to build apps that only work on the latest and greatest version of a phone, and intentionally not on previous models. Yes, fewer people will be able to use it. But everyone who buys the new toy will. The more your app makes the hot new hardware look good, the more it’ll get promoted by the hardware or OS manufacturer. That can give your app presence it could not otherwise get. Once your product is succeeding on the brand-new hardware, you can start adapting it to other platforms.

Try to conquer the entire mobile world at once and you’ll have no marketing partners. Or, put more starkly: It’s hard to win when nobody loses.

jQuery for Mobile arrives for mobile Web

In recent years, a software project called jQuery has spread far and wide across the Web, bringing sophisticated user interface features and easing the difficulties of working with multiple browsers.

Now the first version of the software has arrived for the mobile Web, with the release of jQuery Mobile 1.0. The software is prebuilt code to help programmers create Web sites–and even packaged Web apps–using standards such as HTML, JavaScript, and CSS.

The software, whose premier sponsor is Adobe Systems, smooths over differences among many mobile browsers it supports, including those of iOS, Android, Windows Phone, and BlackBerry, as well as standalone mobile versions of Opera and Firefox.

“We’ve been working hard at bringing jQuery support to all mobile browsers that are sufficiently capable and have at least a nominal amount of market share. In this way, we’re treating mobile Web browsers exactly how we treat desktop Web browsers,” the jQuery Mobile documentation states.

Also released is the ThemeRoller for jQuery Mobile that lets developers visually design a specific look to user-interface elements such as menus, buttons, title bars, and Web links.

How facebook works?

Facebook is social networking. People have been “facebooking” each other for about 6 years now, making Facebook the most used social network with over 350 million users worldwide. But how does Facebook work?

In this article, I will discuss Facebook’s inner workings, covering its architecture and frontend/backend infrastructure””the nuts and bolts that hold Facebook together.

How Does Facebook Work?””The Front End

Facebook uses a variety of services, tools, and programming languages to make up its core infrastructure. At the front end, their servers run a LAMP (Linux, Apache, MySQL, and PHP) stack with Memcache. Not a computer science expert? Let’s take a look at exactly what that means.

Linux & Apache

how does facebook work

This part is pretty self-explanatory. Linux is a Unix-like computer operating system kernel. It’s open source, very customizable, and good for security. Facebook runs the Linux operating system on Apache HTTP Servers. Apache is also free and is the most popular open source web server in use.


how does facebook work

For the database, Facebook utilizes MySQL because of its speed and reliability. MySQL is used primarily as a key-value store as data is randomly distributed amongst a large set of logical instances. These logical instances are spread out across physical nodes and load balancing is done at the physical node level.

As far as customizations are concerned, Facebook has developed a custom partitioning scheme in which a global ID is assigned to all data. They also have a custom archiving scheme that is based on how frequent and recent data is on a per-user basis. Most data is distributed randomly.


how does facebook work

Facebook uses PHP because it is a good web programming language with extensive support and an active developer community and it is good for rapid iteration. PHP is a dynamically typed/interpreted scripting language.


how facebook works

Memcache is a memory caching system that is used to speed up dynamic database-driven websites (like Facebook) by caching data and objects in RAM to reduce reading time. Memcache is Facebook’s primary form of caching and helps alleviate the database load.

Having a caching system allows Facebook to be as fast as it is at recalling your data. If it doesn’t have to go to the database it will just fetch your data from the cache based on your user ID.

Downsides to Using LAMP

Facebook has realized that there are downsides to using the LAMP stack. Notably, PHP is not necessarily optimized for large websites and therefore hard to scale. Also, it is not the fastest executing language and the extension framework is difficult to use.

how facebook works

Mike Schroepfer, Facebook’s Vice President of Engineering, recently did an interview at EmTech@MIT concerning this. “Scaling any website is a challenge,” Schroepfer said, “but scaling a social network has unique challenges.”

He went on to say that unlike other websites, you can’t just add more servers to solve the problem because of Facebook’s “huge interconnected dataset.” New connections are created all the time due to user activity.

Facebook has grown so quickly that they are often faced with issues regarding database queries, caching, and storage of data. Their database is huge and largely complex. To account for this, Facebook has started a lot of open source projects and backend services.

How Does Facebook Work?””The Back End

Facebook’s backend services are written in a variety of different programming languages including C++, Java, Python, and Erlang. Their philosophy for the creation of services is as follows:

1. Create a service if needed

2. Create a framework/toolset for easier creation of services

3. Use the right programming language for the task

A list of all of Facebook’s open source developments can be found here. I will discuss a few of the essential tools that Facebook has developed.

Thrift (protocol)

Thrift is a lightweight remote procedure call framework for scalable cross-language services development. Thrift supports C++, PHP, Python, Perl, Java, Ruby, Erlang, and others. It’s quick, saves development time, and provides a division of labor of work on high-performance servers and applications.

Scribe (log server)

Scribe is a server for aggregating log data streamed in real-time from many other servers. It is a scalable framework useful for logging a wide array of data. It is built on top of Thrift.

Cassandra (database)

how facebook works

Cassandra is a database management system designed to handle large amounts of data spread out across many servers. It powers Facebook’s Inbox Search feature and provides a structured key-value store with eventual consistency.

HipHop for PHP

HipHop for PHP is a source code transformer for PHP script code and was created to save server resources. HipHop transforms PHP source code into optimized C++. After doing this, it uses g++ to compile it to machine code.

Testing web applications – Selenium WebDriver

Mobile testing has come a long way since the days when testing mobile web applications was mostly manual and took days to complete. Selenium WebDriver is a browser automation tool that provides an elegant way of testing web applications. WebDriver makes it easy to write automated tests that ensure your site works correctly when viewed from an Android or iOS browser.

For those of you new to WebDriver, here are a few basics about how it helps you test your web application. WebDriver tests are end-to-end tests that exercise a web application just like a real user would. There is a comprehensive user guide on the Selenium site that covers the core APIs.

Now let’s talk about mobile! WebDriver provides a touch API that allows the test to interact with the web page through finger taps, flicks, finger scrolls, and long presses. It can rotate the display and provides a friendly API to interact with HTML5 features such as local storage, session storage and application cache. Mobile WebDrivers use the remote WebDriver server, following a client/server architecture. The client piece consists of the test code, while the server piece is the application that is installed on the device.

Get Started

WebDriver for Android and iPhone can be installed following these instructions. Once you’ve done that, you will be ready to write tests. Let’s start with a basic example using to give you a taste of what’s possible.

The test below opens on Android and issues a query for “weather in san francisco”. The test will verify that Google returns search results and that the first result returned is giving the weather in San Francisco.

 public void testGoogleCanGiveWeatherResults() { 
 // Create a WebDriver instance with the activity in which we want the test to run. 
 WebDriver driver = new AndroidDriver(getActivity()); 
 // Let’s open a web page 
 // Lookup for the search box by its name 
 WebElement searchBox = driver.findElement("q")); 
 // Enter a search query and submit 
 searchBox.sendKeys("weather in san francisco"); 
 // Making sure that Google shows 11 results 
 WebElement resultSection = driver.findElement("ires")); 
 List<WebElement> searchResults = resultSection.findElements(By.tagName("li")); 
 assertEquals(11, searchResults.size()); 
 // Let’s ensure that the first result shown is the weather widget 
 WebElement weatherWidget = searchResults.get(0); 
 assertTrue(weatherWidget.getText().contains("Weather for San Francisco, CA")); 

Now let’s see our test in action! When you launch your test through your favorite IDE or using the command line, WebDriver will bring up a WebView in the foreground allowing you to see your web application as the test code is executing. You will see loading, and the search query being typed in the search box.

We mentioned above that the WebDriver supports creating advanced gestures to interact with the device. Let’s use WebDriver to throw an image across the screen by flicking horizontally, and ensure that the next image in the gallery is displayed.

 WebElement toFlick = driver.findElement("image")); 
// 400 pixels left at normal speed 
Action flick = getBuilder(driver).flick(toFlick, 0, -400, FlickAction.SPEED_NORMAL) 
WebElement secondImage = driver.findElement(“secondImage”); 

Next, let’s rotate the screen and ensure that the image displayed on screen is resized.

 assertEquals(landscapeSize, secondImage.getSize()) 
((Rotatable) driver).rotate(ScreenOrientation.PORTRAIT); 
assertEquals(portraitSize, secondImage.getSize()); 

Let’s take a look at the local storage on the device, and ensure that the web application has set some key/value pairs.

 // Get a handle on the local storage object 
LocalStorage local = ((WebStorage) driver).getLocalStorage(); 
// Ensure that the key “name” is mapped 
assertEquals(“testUser”, local.getItem(“name”)); 

What if your test reveals a bug? You can easily take a screenshot for help in future debugging:

 File tempFile = ((TakesScreenshot) driver).getScreenshotAs(OutputType.FILE); 

High Level Architecture

WebDriver has two main components: the server and the tests themselves. The server is an application that runs on the phone, tablet, emulator, or simulator and listens for incoming requests. It runs the tests against a WebView (the rendering component of mobile Android and iOS) configured like the browsers. Your tests run on the client side, and can be written in any languages supported by WebDriver, including Java and Python. The WebDriver tests communicate with the server by sending RESTful JSON requests over HTTP. The tests and server pieces don’t have to be on the same physical machine, although they can be. For Android you can also run the tests using the Android test frameworkinstead of the remote WebDriver server.

Infrastructure Setup

At Google, we have wired WebDriver tests to our cloud infrastructure allowing those tests to run at scale and making it possible to have them run in our continuous integration system. External developers can run their mobile tests either on emulators/simulators or real devices for Android and iOS phones and tablets.
Android emulators can run on most OSes because they are virtualized, so we run them on our generic cloud setup. Though there are many advantages to using Android emulators because they emulate a complete virtual device (including the virtual CPU, MMU, and hardware devices), it makes the test environment slower. You can speed up the tests by disabling animations, audio, skins, or even by running in the emulator headless mode. To do so, start the emulator with the options –no-boot-anim, –no-audio, –noskin, and –no-window. If you would like your tests to run even faster, start the emulator from a previously created snapshot image. That reduces the emulator startup time from 2 minutes to less than 2 seconds!
iOS simulators can’t be virtualized and hence need to run on Mac machines. However, because iOS simulators don’t try to emulate the virtual device or CPU at all, they can run as applications at “full speed,” this allows the test to run much faster.
Stay tuned for more mobile feature in Selenium WebDriver, and updates on the Selenium blog. For questions and feedback not only of the Android WebDriver but also its desktop brethren, please join the community.

jQuery and Ajax Error Handling

Website development duties were once assigned to different individuals with two distinct roles: A designer focused on the all matters related to the front-end HTML and CSS, and a developer was responsible for the server-side code. JavaScript’s meteoric rise to first-class citizen status has blurred these traditional lines, forcing developers into what was once considered taboo territory. The results have been spectacular, with frameworks such as jQuery significantly streamlining JavaScript’s often unwieldy native syntax, and programming techniques such as Ajax bringing highly responsive user interfaces to the browser. The marrying of jQuery and Ajax has been particularly impactful, providing developers with a powerful solution to the problem of asynchronously interacting with and updating parts of a web page.

Despite all of jQuery’s strengths, incorporating Ajax-driven features into web applications can be a frustrating endeavor, due in large part to the challenges of determining where exactly in the process things go awry. Did an error occur in the browser? What about during the transmission of data between client and server? Or perhaps within the server-side code? These are all possibilities developers need to consider when problems arise.

If you struggle with diagnosing and resolving Ajax errors, try these error detection and resolution techniques and technologies.

Native jQuery Error Detection

The vast majority of Ajax-related errors will come as a result of malformed JSON or server-side issues that generate a 404 (not found) or 500 (internal server error) response code. Despite this fact, you’ll often encounter code like this:

$(document).ready(function () {

    url: 'http://localhost/api/products/list',
    type: 'GET',
    dataType: 'json',
    success: function() {
      // Receive and format data


This snippet performs a straightforward Ajax GET request, contacting a URL and expecting the returned data to be formatted using JSON. Yet upon execution, suppose the returned data isn’t output to the browser as dictated by the success callback, leaving one wondering what caused the problem. A glance at Firefox’s error console doesn’t indicate any JavaScript syntax errors, and you’ve already thoroughly tested the server-side script’s JSON output. So what’s the problem?

As it turns out, the problem could be that the script is simply pointing to a nonexistent server resource, producing a 404 error rather than the desired output. Fortunately, error detection is easy to integrate thanks to the statusCode setting:

  url: 'http://localhost/api/products/list.php',
  type: 'GET',
  dataType: 'json',
  statusCode: {
    404: function() {
      $("#response").html('Could not contact server.');
  success: function() {
    // Receive and format data

You can detect and handle additional server status codes as well simply by following the same pattern:

statusCode: {
  404: function() {
    $("#response").html('Could not contact server.');
  500: function() {
    $("#response").html('A server-side error has occurred.');

Detecting Data Errors

With commonplace 404 and 500 errors handled, it makes sense to next account for errors that occur due to malformed JSON formatting. Suppose the aforementioned http://localhost/api/products/list.php URL does indeed exist, and is intended to return a list of products formatted using JSON. A properly functioning PHP script (although simplified for the purposes of this tutorial) might look like this:


  $products[] = array (
    array (
      "name"         => "Stylish Wallet",
      "price"        => "12.99",
      "manufacturer" => "European Limited"
    array (
      "name"         => "Pleather Shoes",
      "price"        => "37.99",
      "manufacturer" => "Hungarian Imports"

  echo json_encode($products);


But suppose that in the API developer’s haste he accidentally erased the <?php delimiter, causing the entire PHP script to be returned to the client rather than just the desired JSON payload. As with the previous example, lack of proper error handling logic would make this problem difficult to detect, particularly if you aren’t privy to the inner workings of the server-side API. One easy way to account for such unexpected errors is through the error callback:

  url: 'http://localhost/openlogic/list.php',
  type: 'GET',
  dataType: 'json',
  statusCode: {
    404: function() {
      $("#response").html('Could not contact server.');
    500: function() {
      $("#response").html('A server-side error has occurred.');
  error: function() {
    $("#response").html('A problem has occurred.');
  success: function() {

Reviewing Network Traffic and JSON with the Firebug Console

In addition to these programming techniques, a useful tool that can provide developers with keen insight into the HTML, CSS, JavaScript, and network activity associated with a web page is the Firebug Firefox extension. One particularly useful feature is its ability to monitor both outbound and inbound requests, including the request and response headers and payload. This capability can be indispensable for providing quick answers to the questions we posed earlier in this article, because you can peer right into the behavior and characteristics of each leg of the Ajax request/response process.

After installing Firebug, you have access to a new console window that allows you to examine all the requests that occurred in the process of loading a web page, as depicted in Figure 1.

Viewing all requests associated with a web page

Clicking on the Headers tab provides information about the nature of the request, as shown in Figure 2.

Learning more about the nature of the Ajax request

Clicking on the Response tab provides more information about the associated response, including the JSON payload, as depicted in Figure 3.

Peering into a JSON-based response payload

This ability to examine each component of the request without having to resort to littering the code with debugging statements is invaluable, and something you’ll use on a regular basis when developing Ajax-based features.