Android and iPhone browser wars, Part 1: WebKit to the rescue

Build a network monitoring application for the browser

Mobile devices play an ever-increasing role in our lives today. We use them to communicate. We use them to navigate. We even use them as a handy flashlight. While custom applications are extremely popular for the iPhone and the Android platforms, there is an opportunity in mobile Web applications. This article is the first in a two-part "Android and iPhone browser wars" series on developing browser-based applications for iPhone and Android. Along the way, we will build a simple network monitoring application that runs within the confines of the desktop and both mobile browsers.


Frank Ableson, Software designer

After his college basketball career came to an end without a multiyear contract to play for the L.A. Lakers, Frank Ableson shifted his focus to computer software design. He enjoys solving complex problems, particularly in the areas of communications and hardware interfacing. When not working, he can be found spending time with his wife Nikki and their children. Frank can be reached at

08 December 2009

Also available in Russian Japanese Vietnamese Portuguese


Combined, the iPhone and Android platforms have more than 100,000 application titles available for download across their respective app stores. Native applications are those created with a platform's SDK, then compiled and installed to a device. These native applications provide thorough access to a device's inherent capabilities, including features like wireless networking, Bluetooth, data storage, accelerometer, compass, and other on-device wizardry that make the devices so attractive. While native, or custom, applications are extremely popular for the iPhone and Android platforms, there is a tremendous opportunity for mobile Web applications. Mobile has come of age — and with it: the Mobile Web.

This article is the first in a two-part series on developing browser-based applications for iPhone and Android, the aim being to assist you with moving toward developing your own mobile Web applications. Mobile Web applications can be more than rendering a Web site on a mobile device. We will look at some of the core technologies and techniques that make mobile Web development a compelling discipline.

The Web has become the platform of choice because it solves so many of the problems that traditionally plague application developers and system administrators. Some of these solutions:

  • Web applications are easy to deploy — Just install or copy them to the server, and have your clients point their browsers to the correct URL.
  • Web applications scale well with server farms in high-performance data centers and are serviced by readily available Web-site management tools.
  • Web applications centralize data storage and thereby simplify disaster recovery plans.
  • The combination of HTML, Cascading Style Sheets (CSS) , JavaScript, and graphic images provides for a stunning user interface experience that far exceeds the capabilities of native SDKs (short of an all-out, immersive gaming experience) and most application experiences do not warrant gaming or kiosk experience.
  • The majority of applications require easy-to-use UI elements to guide the user through a series of day-to-day operations.

The most appealing aspect of the Web application distribution model is the ability to turn software into a subscription-oriented service, which is a true win-win proposition. "How?" you ask. Let's take a quick look.

Web deployment models empower customers to try before they buy with minimal risk and cost. If the customer likes the trial, continuing on with the service is just a credit card (or PayPal) transaction away. Software vendors benefit because system upgrades are simplified, reducing the support costs and ultimately minimizing the costs transferred to the customer. What's more, the software as a service (SaaS) model permits customers to gain the benefit of the software without a large up-front investment — bringing financial ROI in month one, rather than sometime in the nebulous future.

Sounds great. What works for the Web works for mobile, right? Well, until the iPhone came along, the answer was largely no. Why is that?

The truth is that the mobile Web browser experience has been sorely lacking. But all of that has changed, thanks to a technology known as WebKit, which made its mark upon the mass mobile via the iPhone.

iPhone has gone from a standing-start to the No. 1 mobile Web client in the world in a very short couple of years. Why? Because WebKit, along with reliable Internet connectivity, makes the Web work for mobile — much more so than any other browser options to date. The rest of the mobile marketplace has taken notice and is using WebKit, contemplating it, or making excuses.

So, what is WebKit?

WebKit and HTML5

WebKit is the browser engine powering the Mobile Safari browser found in the iPhone, as well as the technology behind the browser in Android. WebKit is also finding its way into other mobile settings, though we'll keep our discussion to just the iPhone and Android platforms.

WebKit is an open source project that traces its roots back to the K Desktop Environment (KDE). The WebKit project has brought to life the modern Web application for mobile devices. While device capabilities and form factors are hugely important, mobile users thrive on content. If the only content available to a mobile user is a small subset of the overall content available on the Internet, the experience will be second-rate at best.

Most of us prefer to live integrated lives — if we use a Web site at home on our laptop, the same content should be accessible to us when sitting on the train. Content is the killer application. Regardless of where we are and what we are doing, we want access to our data. WebKit enables rich content on the iPhone and Android platforms.

It is worth noting that WebKit is also used on the desktop in the Safari browser, which is the default browser on the Mac OS X platform. Whether we are discussing the desktop version or the browser engine on the iPhone or Android, WebKit is on the forefront of HTML and CSS feature support. In fact, WebKit supports CSS styles that are as yet not adopted by other browsers — the features being considered by the HTML5 specification.

The HTML5 specification is a collection of technical drafts covering a variety of browser-based technologies, including client-side SQL-capable storage, transitions, transformation, translation, and much more. HTML5 has been in the works for some time, and, although not complete, when its feature set firms up with major browser platform support, the humble beginnings of Web applications will be but a distant memory. Web application development will dominate — and not just in the traditional desktop browser footprint but also in the mobile space. Mobile will be a day-one thought, rather than an afterthought.

Mobile Web application considerations

In order to access Web development technologies, today's application developer has a few choices available. First, the application can be written strictly as HTML, CSS, and JavaScript files on a server. Of course, the HTML content may originate as static HTML files or be generated dynamically from any of a number of server-side technologies, such as PHP, ASP.NET, Java Servlets, etc. All of these technologies can be boiled down to the term HTML for simplicity — it really is not relevant for this discussion — and most importantly, the WebKit-powered browser interprets and renders the HTML on the mobile device.

The user accesses the Web application on the mobile device (i.e., iPhone or Android) by opening the browser application and entering the URL for the desired server:

A particular mobile Web application will fit somewhere on a continuum, ranging from a generic Web site to a highly platform-specific mobile Web application.

Generic site rendering

The rendering engine in WebKit, coupled with the highly intuitive UI found on the iPhone and Android platforms, allows virtually any HTML-based Web site to be viewed on the device. Web pages are rendered correctly, unlike the historic mobile browser experience where content wraps or just doesn't show at all. When the page loads, the content will often be zoomed all the way out such that the entire page is visible, albeit very small and potentially at an unreadable scale, as shown in Figure 1. However the page can be readily scrolled, panned, pinched, and zoomed, providing access to the entire content. By default, the browser uses a viewport, or logical dimension, of 980 pixels wide.

Figure 1. Web page zoomed all the way out on loading
The content will often be zoomed all the way out such that the entire page is visible, albeit very small

While this provides access to the entire page and is a great improvement over the historic mobile Web experience, more can be done to improve the mobile experience.


To move down the continuum from generic Web page toward mobile-friendly, the Web application can be modified in a few areas.

While the page will render properly in WebKit, there are some differences between a mouse-centric device, such as a laptop or desktop computer, vs. a touch-centric device, such as an iPhone or Android smartphone. The primary areas of divergence include the physical size of "clickable" areas, the lack of "hover styles" and an altogether different event sequence. Here is a quick summary of things to bear in mind when designing a Web site that will be viewed by mobile users:

  • The iPhone/Android browser will render the screen very readable — much better than typical mobile browsers — so don't rush to make a watered-down mobile version of your site.
  • Fingers are larger than mouse pointers. Keep this in mind when designing clickable navigation — don't put links too close together because the user will not be able to hit one link without hitting its neighbor.
  • Hover styles don't work because you don't "hover" with your finger in the same manner that you would with a mouse pointer.
  • Events such as mouse-down, mouse-move, etc. are simply different on touch-based devices. Some of these events will fire, but don't rely on having the same sequence you see on desktop browsers.

The details of this are put forth in detail in iPhone in Action (see Resources). For our purposes, we will focus more on what WebKit can do, rather than what it cannot.

Let's look at the most obvious challenge in making a Web site friendly to an iPhone or Android visitor: the screen size. The de-facto mobile screen size in use today is 320x480. Note that this can also be 480x320 as users may choose to view Web content in the landscape orientation. As we witnessed in Figure 1, WebKit will render desktop-oriented Web pages just fine, though the text just might be a bit too small to effectively read the content without a bunch of pinching and zooming. So what are we to do about this?

The most straight-forward and unobtrusive-to-the-desktop manner of accommodating the mobile user is through the use of a special metatag: viewport.

A metatag is an HTML tag placed within the head element of an HTML document. Here is a simple example use of the viewport tag: <meta name="viewport" content="width=device-width" />. When this metatag is added to an HTML page, we see that the page is scaled more appropriately for the mobile device, as shown in Figure 2. The tag is simply ignored by browsers that do not support it.

Figure 2. Page scaled more appropriately for mobile devices
When this metatag is added to an HTML page, we see that the page is scaled more appropriately for the mobile device

In some cases, it may be desirable to pre-scale the window to a particular value, as shown in Figure 3.

Figure 3. Pre-scaling the window
It may be desirable to pre-scale the window to a particular value

To set a specific scale, the content attribute of the viewport metatag is set to an explicit value: <meta name="viewport" content="width=device-width, initial-scale=1.0 user-scalable=yes" />. By changing the initial-scale value, the screen may be zoomed in or out as desired. Setting the value to somewhere between 1.0 and 1.3 is appropriate for the iPhone and Android platforms, respectively. The viewport metatag also supports minimum scale and maximum scale, which can be used to constrain just how much control a user has over the rendering of the page.

While the iPhone form factor has not changed since it debuted with the 320x480 layout, Android promises to have more varied physical characteristics as more devices hit the market, each from multiple manufacturers, targeted at different user populations. This potential variability in screen size, form factor, and resolution is something to keep in mind as you develop your applications and target mobile devices like Android.

Beyond the physical differences from one Android device to the next, experience has shown that Android's software has exerted more control over the rendering of pages by way of on-device browser settings. While stable, the Android platform is also very fluid. The settings on a particular device likely differ from your development environment, depending on the SDK level and the manufacturer. Figure 4 shows a screenshot of the settings page from the browser application taken from V1.6 of the Android Emulator. The settings screen permits the user to configure a device to a pre-defined zoom level (far, near, medium) or to request the device to auto-fit pages.

Figure 4. Settings page from the Android Emulator
Image shows a screenshot of the settings page from the browser application taken from V1.6 of the Android Emulator

In the mobile world, the biggest constant is change, so this promises to be a bit of a shifting landscape. For example, the settings for the browser Sprint Hero have an entirely different set of options with respect to page rendering. The Hero is built upon Android V1.5 plus a bunch of HTC-supplied enhancements. Fortunately, these settings will be overridden by the viewport metatag, if present in your Web page.

Thus far, we have seen WebKit render a normal Web page quite well, albeit a bit small and hard to read without some zooming. Next, we exerted control over the user's experience by controlling how the page is seen on the device through the use of the viewport metatag. This made the page easier to read and navigate. But what if we want to go further and make the site look and feel like a mobile application?

Made for mobile

Now let's have a look at a design strategy when targeting a mobile audience. As a quick case study, let's consider the login page from Google's GMail email service.

First, have a look at the desktop browser experience in Figure 5.

Figure 5. Desktop browser
Image shows the desktop browser experience

The desktop home screen has informational content to the left and a sign-in area to the right. Contrast the desktop view with the mobile-specific view in Figure 6, taken from the iPhone.

Figure 6. Mobile-specific view from the iPhone
Screenshot shows the mobile-specific view from the iPhone

The screen shown in Figure 6 is certainly targeted to a mobile user. The user is directly prompted for just what is necessary to move forward with the application — no pinching, zooming, or scrolling required.

Next, let's look at the mobile GMail application's functionality when reading a message. Due to the limited real estate available to the application, the message-reading window has precious little opportunity to present buttons or navigation. Any space dedicated to navigation takes away from reading content. Also, we don't want to fall into the trap of having multiple frames or scrolling div elements if we can avoid it. Mobile GMail solves this problem by providing a simple floating menu that appears whenever the page stops scrolling. The menu has three buttons: Archive, Delete, and More. Selecting the More button displays additional menu items, as shown in Figure 7.

Figure 7. Floating menu
Selecting the More button displays additional menu items

This is an application that is made for mobile.

The other thing to bear in mind is that we don't want to water down the mobile experience for visitors running very capable browsers, such as those found on the iPhone or Android platforms. To that end, see what GMail shows at the bottom of the page in Figure 8.

Figure 8. Letting the user decide
Image showing the the user decides

If your user prefers the greater functionality of the desktop version, let him use it. Wherever possible, let the user decide.

Now, let's say you want to build an application that uses Web technologies, but actually looks like a native application.

Platform-specific content

The next step is toward creating platform-specific targeted content by formatting a page to look closer to the native look and feel for the target platform, rather than a generic Web site. What do we mean by native?

Before diving into the specifics of how to make a Web page look and feel like a native application for a particular platform, let's take a brief sojourn into the visual differences between iPhone and Android as platforms — putting aside for the moment their strong browser-based relations.

iPhone has a distinct look and feel to it. Show someone a screenshot from an iPhone and unless they have been living under a rock, there is a decent chance that the image will be identified as coming from an iPhone. Show the same person a screenshot from an Android device and the result will likely be different. Why is that? There are a couple of likely reasons for this. The primary reason is that it has been on the market longer, and it has no small share of a cult-like following. Remember those people lining up for hours to pay top dollar for a limited feature V1 iPhone? Whether you own an iPhone or not, Apple's brain-child is an icon in today's marketplace. What about Android?

Android is relatively new and is, in many respects, the anti-iPhone, as it embraces the open source community, more or less. Android will be used on multiple devices (phones and other appliance-type devices). For now, let's hold our discussion to mobile phones to keep things as simple as possible.

Over time, the number of devices for Android will likely surpass iPhone worldwide. This is because Android-powered devices are being produced by multiple manufacturers and will be available on multiple carrier networks worldwide. With the greater number of players participating in the Android market, there is sure to be fragmentation in terms of look and feel. We see this already with the SenseUI interface from HTC. This attractive look and feel is not available in the core Android SDK and is not compatible with all devices. Motorola, Google, and Verizon have teamed to create a new Android device: DROID. It is the first commercial Android device running the 2.0 platform.

Contrast Android's diversity with the consistent look of iPhone. iPhone is the prized possession of Apple. The iPhone's look may evolve over time, but it is very unlikely to suffer from fragmentation as Android is already showing while still in its infancy.

So where do we go for a native look and feel?

In the days prior to Web 2.0, this would be a real challenge. Early attempts at supporting multiple client browsers (mobile and non-mobile) included a bunch of different techniques, such as:

  • Entirely parallel sites
  • Dynamically generated content based on userAgent
  • Proxy servers that would distill content down to the device; RIM has made extensive and successful use of this approach for on-device e-mail rendering

These approaches are perhaps acceptable for large well-funded teams, but what about the rest of the world? We don't have the time, talent, or treasure to exchange for this kind of capability. And, as we have already contemplated, the mobile Web of yesterday was insufficient, so we don't want to go there anyway.

And fortunately, we don't have to. In the age of WebKit and CSS, these differences can be readily accommodated through the use of stylesheets and media queries. As introduced earlier, a media query is a technique to obtain information about the client. Traditionally, browsers have sent a userAgent string, which identified the browser, and the server did the work of figuring out what content to send to the device (per the discussion above). With a media query, the browser makes the decision based on its capabilities. Here is an example for obtaining a stylesheet targeted toward a smartphone: <link rel="stylesheet" type="text/css" href="smartphone.css" media="only screen and (max-device-width: 480px)" />. And here is a media query targeted toward a desktop computer: <link rel="stylesheet" type="text/css" href="smartphone.css" media="only screen and (min-device-width: 481px)" />.

Internet Explorer V6

At the time of this writing, Internet Explorer V6 holds about a 20-30 percent marketshare, but accommodating IE V6 is beyond the scope this article.

To learn more about media queries, please see the draft specification (see Resources).

Let's have a look at an example using this approach in the context of a sample application that displays network status.

Networking monitoring application

The purpose of the application is to monitor multiple servers. Independent software developers often find themselves supporting multiple applications across multiple servers. And if you've been in the game for any noticeable amount of time, it is likely that the types of servers and the types of applications will vary. All this is just to say that there may not be a single tool that can readily monitor every aspect of every application you need to monitor. This is where the Network Monitor (netmon) mobile application comes in. It is not designed to be exhaustive, but rather flexible and convenient on your mobile device.

The netmon application contains a list of servers of interest. Each entry displays key performance indicators (KPIs). KPIs have long been the staple of MBA students for measuring key aspects of the health of a business. In the land of Web application hosting, some important KPIs might include:

  • Number of transactions within a recent time period:
    • Orders
    • Catalog requests
    • E-mail messages
    • Page views
  • Time period since the last transaction:
    • Order
    • EDI document
    • Business partner message
    • FTP file from vendor
  • Is the database available?
  • Date of last known backup
  • Average dollar amount per order
  • Disk space remaining
  • Bandwidth transferred within the past hour, day, month

These items and any number of other pieces of operational data serve to paint a picture of the health of a particular system or application. During the holiday season, we actually look at the number of orders placed on some of our sites. If the number is not steadily increasing hour over hour, we take a closer look.

As each application's needs and required resources vary, the netmon application needs to be flexible to accommodate the particulars of each application. To accommodate this requirement of flexibility, we start with a most basic data structure to represent the health of a particular system; in Part 2, we will concern ourselves with where this data comes from and how it gets updated. For now, we are interested in the following pieces of information:

  • Name of site
  • Site URL (home page)
  • URL for getting updates
  • Status: OK or not?
  • Summary: Brief description of the condition; this will be either OK or a textual string describing the highest-priority problem
  • Items: This is a collection of name/value pairs used to convey the current operational statistics or KPIs for the site

Our application will list these items in an easy-to-navigate fashion, leveraging CSS, jQuery, and WebKit capabilities to make the entries stand out. As mentioned, the goal is for this application to run on iPhone, Android, and also on a desktop version of Safari.

Building the application

Today, Web pages should be created in a declarative fashion, providing organization and content only. All positioning and formatting is accomplished via Cascading Style Sheets and often with the assistance of JavaScript. In fact, JavaScript libraries have become so popular that they are becoming the norm, rather than the exception. In this article's sample application, we leverage the popular jQuery JavaScript framework. This sample application will render on iPhone, Android, and also on the desktop. The HTML content is exactly the same. The differences come in the selected stylesheets. To warn you: Not a tremendous amount of focus was put on making the application's appearance sizzle. In fact, the background colors are grossly exaggerated to make a point about the stylesheet organization of the application. We'll clean the application's visual appeal a bit in Part 2. The HTML is shown in Listing 1.

Listing 1. HTML for the application
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" 
<html xmlns="" xml:lang="en">
<meta name="viewport" content="width=device-width" />
<link rel="stylesheet" href="netmon.css" type="text/css" />
<script type="text/javascript" src="jquery.js"></script>
<script type="text/javascript" src="netmon.js"></script>

<script type="text/javascript">
   if (navigator.userAgent.indexOf('iPhone') != -1) {
      document.write('<link rel="stylesheet" href="iphone.css" 
type="text/css" />');
   } else if (navigator.userAgent.indexOf('Android') != -1) {
      document.write('<link rel="stylesheet" href="android.css" 
type="text/css" />');
   } else {
      document.write('<link rel="stylesheet" href="desktop.css" 
type="text/css" />');

function setupTestData() {
   try {
      if (netmon.resources.length > 0) {
         jQuery.each(netmon.resources,function (index, value) {
         $(".serverentry").click (function() {$(this).find(".serveritems").toggle();});
   } catch (e) {
<title>My Network Resources</title>
<body onload="setupTestData();">
<div id="mainContainer">
   <div id="header">
      <h1>My Servers</h1>
   <div id="mainContent">
   <a href="q.php">My User Agent</a>

A quick look at the HTML shows a few items of note:

  • There are two externally loaded JavaScript files: one for the jQuery library and one for helper functions for our application.
  • The use of the viewport metatag to adjust the content's rendering scale.
  • A primary stylesheet is loaded: netmon.css.
  • The userAgent is interrogated to determine which additional stylesheet to load: one for iPhone, one for Android, and one for Desktop.
  • When the page is loaded, the data is displayed through the help of jQuery and a helper function in the netmon.js file.
  • The balance of the page contains a couple of div tags.
  • Lastly, there is a link to a page to show the userAgent string. This is in place as a convenience and for demonstration purposes only. It has nothing to do with the application itself.

Before diving into the stylesheets and the netmon.js file where all of the work is done, let's look at the application in its current form. Recall that we are using three different stylesheets to target the three supported platforms. Each one is set up with a different background color to aid in the development process. Figure 9 shows the Desktop Safari browser with a blue background.

Figure 9. Application shown in the Safari browser on the desktop
Screenshot shows the Desktop Safari browser with a blue background

Figure 10 shows the application rendered on the Android browser with a red background.

Figure 10. Application in the Android browser
Screenshot shows the application rendered on the Android broswer with a red background

Figure 11 shows the application rendered on the iPhone browser with a green background.

Figure 11. Application on the iPhone browser
Screenshot shows the application rendered on the iPhone browser with a green background

The primary stylesheet is in a file named netmon.js, shown in Listing 2.

Listing 2. The primary stylesheet
body {
   color: #888888;
   font-family: Helvetica;
   margin: 0px;
   padding: 0;
.details {
   margin: 0px;
   padding: 0px;
   background-color: white;
   border: solid;
   border-width: 1px;

   -webkit-border-top-left-radius: 8px;
   -webkit-border-top-right-radius: 8px;
   -webkit-border-bottom-left-radius: 8px;
   -webkit-border-bottom-right-radius: 8px;
.OK {
   color: #000000;
.BAD {
   color: #ff0000;
.odd {
   background-image: -webkit-gradient(linear, left top, right bottom,from(#ccc) 
.even {
   background-image: -webkit-gradient(linear, left top, right bottom,from(#999) 
.serverentry a {
   float: right;
   color: #ffffff;
   color: #000;

#header h1 {
   margin: 0;
   padding: 0;
   text-align: center;
   color: #000;

The platform-specific stylesheets accomplish three primary objectives:

  1. To change the color scheme as a gross demonstration of what a stylesheet's impact is and to demonstrate how easy it is to target a specific stylesheet to a particular platform based on the userAgent.
  2. To adjust the font sizes between the desktop and mobile platforms.
  3. To exercise WebKit-specific functionality. This is important if we were targeting a non-WebKit capable browser on the desktop, such as Firefox.

By way of example, the iphone.css file is shown in Listing 3.

Listing 3. iphone.css file
body {
   background-color: #00ff00;
.serverentry {
   -webkit-border-top-left-radius: 8px;
   -webkit-border-top-right-radius: 8px;
   -webkit-border-bottom-left-radius: 8px;
   -webkit-border-bottom-right-radius: 8px;
.name {
   font-size: 2em;
   font-size: 1.5em;
.serverentry a {
   font-size: 1.5em;

In this file, we see that the background color of the body tag is set to green (#00ff00) and the tweaking of some font sizes to make the entries more easily read on the mobile device.

Last, let's have a look at netmon.js, which contains a list of entries along with a function designed to render an entry, shown in Listing 4. Some data has been omitted from this listing for brevity, though a full copy is available (see download).

Listing 4. netmon.js
var netmon = {
   initialize : function () {
   resources : 
         name : '',
         homeurl : '',
         pingurl : '',
         status : 'OK',
         summary : 'OK',
         items : 
          {name : 'DiskSpace', value : '22.13 GB'},
          {name : 'Database Up?', value : 'Yes'}
         name : 'server 2',
         homeurl : 'http://someurl',
         pingurl : 'http://someurl/netmon.jsp',
         status : 'OK',
         summary : 'OK',
         items : 
          {name : 'DiskSpace', value : '100.8 GB'},
          {name : 'Database Up?', value : 'Yes'}
// additional entries clipped for brevity

   render : function(index,itm) {
      try {
         var ret = "";
         ret += "<div class='serverentry " + itm.status + " " + (index % 2 == 0 ? 
'even' : 'odd') + "'>";
         ret += "<span class='name'>" + + 
"</span>&nbsp;&nbsp;<a target='_blank' href='" + itm.homeurl + 
"'>Show</a><br />";
         if (itm.status != "OK") {
            ret += "<span class='summary'>-" + itm.summary + 
"</span><br />";
         ret += "<div class='serveritems'>"; 
         jQuery.each(itm.items,function (j,itemdetail) {
            ret += ">>" + + "=" + itemdetail.value + 
"<br />";
         ret += "</div>";      
         ret += "</div>";
         return ret;
      } catch (e) {
            return "<div class='error'>Error rendering item [" + + "] 
" + e + "</div>";

When a server entry is not in the OK state, it is shown in red, thanks to a class definition in the CSS file. Additionally, when the status is not OK, we display the summary field to provide a quick, at-a-glance view of the problem. In figures 9-11, the problem with server 4 is low disk space. If we tap on an entry, we can see the details, as shown in Figure 12.

Figure 12. Details from server 4
Screenshot shows Server 4 details when an entry is tapped

By tapping on the show link to the right of each entry, we launch the home page of each server. This is a handy feature for two reasons. First, it is a nuisance to have to remember every server URL of interest, and second, it is an even larger nuisance to have to key in a long URL on a mobile device, no matter how good the keyboard is.

With the netmon happily running on our mobile device, supporting our servers should be an easier task.

In Part 2, we will flesh out this application such that we can request more real-time data and discuss some of the server-side considerations of building a mobile application.

Before we wrap up, let's take a quick peek at what would be necessary to make this application available for download from an application store.

Taking a Web application to the metal

Imagine that the network monitoring application is done. You show it to a friend and he encourages you to sell the application to others so that they, too, can monitor resources on their networks with your application. Can you sell a Web application? A Web application can certainly be sold via the traditional subscription or SaaS model, but what if you want to package your "Web application" and sell it via an application marketplace, such as the iTunes App Store or the Google Marketplace? In order to do that, the application must be compiled as a native application. Fortunately, there is a solution to this.

Each major mobile platform has a means to embed a browser into a view or form, or activity. Each platform has a slightly different term for this technique, but they all work in a similar fashion: A browser control is placed within the native application and the native application can interact with it. In the most simplistic model, the browser control may simply go to the Web for its content. Alternatively, the native application can intercept link requests and provide its own content, thereby leveraging the browser view only for rendering. Remember, HTML and CSS are viable alternatives to native widgets, regardless of the source of the content of the application. And some applications will be a hybrid of those two approaches. For example, an application may get most of its content from the Web, but the "native side" of the application provides access to local resources via Bluetooth.

There are a few tools available on the market for just this sort of application architecture. PhoneGap and Appcelerator are two leaders in this area (see Resources).


This article served as an introduction to iPhone and Android Web applications powered by WebKit. In Part 2, this example application is expanded to incorporate live page updates through the Web-changing technology of Ajax.


Network app source codeos-androidiphone1-browserwars1sourcecode.zip23KB



Get products and technologies



developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into Open source on developerWorks

Zone=Open source, Industries
ArticleTitle=Android and iPhone browser wars, Part 1: WebKit to the rescue