The User Agent

The user-agent is the client application that sends a web request. This information is sent with the browser request and allows the server to send different content based on the client. For example, the user-agent helps you detect the type of web browser sending the request. To understand this further, let us send a test request for a web page.

The actual URL requested during this test was, which is a local web server on my home network. Within the browser request is the host's address (; the page being requested is /, or the home page of that host machine.

Let us look at the textual representation of a browser request to understand what information is sent with the browser request. The first line displays the type of web request and the protocol used (in this instance HTTP) followed by some attributes and their values


Accept-Encoding: gzip

Accept: text/xml,application/xml,application/xhtml+xml, text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 User-Agent: Mozilla/5.0 (Linux; U; Android 1.1; en-us; dream)

AppleWebKit/525.10+ (KHTML, like Gecko) Version/3.0.4 Mobile Safari/523.12.2 Accept-Language: en-US

Of particular importance is the User-Agent: attribute that the default Android browser sends to every server it requests a page from. It's like a signature telling the server what type of browser is requesting the page; thus, it allows the server to refine how it prepares the page before sending back the requested page.

The sample PHP server script presented later in this chapter demonstrates how the Q QX server uses the User-Agent: attribute to modify an HTML text area so that it fits nicely into the small G1's screen area.

We can observe some interesting points about the user agent string Android sends to every server that it requests web pages from. The entire string is a testament to the open architecture of Android: Eight different companies and products are expressed in this unusually long user agent string! What are these, and why does the Android browser use them to describe itself?

■ Mozilla—The Mozilla Foundation is an organization that provides support for various open source projects. This organization makes the commonly used browsers Mozilla and Firefox, as well as the HTML/CSS-rendering engine Gecko.

■ Linux—This is the operating system upon which all of Android is built. Much of Android's power as a cellphone and computing platform is attributable to this small, powerful operating system.

■ Android—This name represents the entire software stack of the G1 and other cellphones like it.

■ Dream—HTC (manufacturer of the T-Mobile G1) uses this alternate name to designate the G1 cellphone.

■ AppleWebKit—This is an HTML/CSS-rendering engine similar to Gecko and KHTML. It's also known simply as WebKit. Apple Computing was a significant contributer to the development of the kit, so the company name is prepended to the name.

■ KHTML—This is the original open source rendering engine from which the WebKit was derived.

■ Gecko—This is the name of the Mozilla HTML/CSS-rendering engine. (See the first item in this list.)

■ Mobile Safari—This is Apple Computing's open-source browser designed for hand-held computers and cellphones.

So why is all this information sent to servers on the World Wide Web every time Android requests a page, a graphic, or some other WWW object type? The reason is simple: to give the server enough information to properly create or prepare the page so that it looks good on the cellphone. Webmasters analyzing their server logs can also use this information to gather statistics on the kinds of devices and browsers that are accessing their websites. You can be sure of one thing: If most users visiting websites are using tiny-screen cellphone devices, webmasters will feel market pressure to design their websites to better accommodate the handsets.

Each of these names (and the other embedded information in the user-agent string) actually represents a set of openly documented functions and features that webmasters can find on the Internet. (See the upcoming section "External Links.") Webmasters can then use these functions and features to design web content that looks good and functions well on the Android handset. Of course, webmasters can simply ignore the user-agent string; this is likely the most common practice in designing web content. Designing web content for the specific quirks of every different web browser is a time-intensive task, and good reasons should support the choice to do this. In the case of web content for cellphones, an exception should be made for at least two reasons. Whatever other reasons exist, the most important lies in the numbers: The increased usage of mobile devices indicate that, in the coming years, likely more people will use cellphone handsets to browse the Web than a large-screen PC. Also important is the fact that the media are so different: PC monitors can vary in size from 15 inches to 40 inches and beyond, with billions of pixels in thousands of colors to display web content. Cellphones, on the other hand, have significantly limited screen sizes, so a website that is specifically designed to pack as much information as possible into a page intended to be rendered on one of the large screens will be difficult to navigate on a cellphone screen.

When designing the client-side application code, keep in mind the nature of the client's connection with the server side. Because of its mobile nature, the link between the two can have spotty coverage. Therefore, the programmer of the client code must compensate for potential delays and outages in the connection, as well as find ways to preserve the data that is already being operated on: either data that the server transmitted to the cellphone or data that was generated on the cellphone itself (such as form data).

Here, the Android framework provides powerful and automatic ways of preserving session data so that if your web application is interrupted (by a phone call, for example), the form the user is filling out doesn't have to be restarted and the data that has already been entered doesn't have to be re-entered. The designers of the Android API took careful note of these process-interrupting events and prepared for most of them, saving you from having to come up with solutions to these problems yourself.

So far, we have offered some general tips on how to write client code. Now it's time to cover some specifics and install the Android software development kit (SDK) on your workstation. Again, this is too complicated of a process to describe in this chapter: We recommend that you bookmark this page, use the link "Installing the Android SDK" at the end of this chapter to see how to download and install it, and then return to this page to create a simple web application using the Eclipse IDE and the Android SDK. The web application that we create in this chapter is a simple one that enables you to do the following:

■ You can embed the WebKit browser into a custom Android application that visits a specific server-based web application.

■ When the web application runs, it presents a form enabling you to choose from a list of files to edit. Then it presents a form for actually editing a file remotely on the server.

Although this is simple in theory, computers are anything but simple in completing the task. To create the sample code for the client side of this web application, follow these steps:

1. Using the Eclipse IDE, create an empty Android Project with File, New, Project.

2. Choose the Android/Android Project Wizard option. The New Project Wizard opens (see Figure 12.1).


A new Android project starts with the Project Wizard, which walks you through setting up the new project.

3. Select Android Project and then click Next.

4. In the next window, set the following parameters, as shown in Figure 12.2.

Project name: WebApp

Contents: Create New Project in Workspace Make sure Use Default Location is checked Package name: webApp.WebApp Activity name: WebApp Application name: WebApp

5. After you've entered these parameters, click Finish to start the new project.

When the Wizard creates an Android project, it creates a subdirectory under your Eclipse workspace with the same name as the project. It also creates subdirectories under the project - res, src, etc.


Use the Project Wizard to set the parameters for your new Android project.

Within these subdirectories, the Wizard creates files that will properly build an application, but since the files are templates they have no functionality. In order for you to give your application the functionality that it requires, you need to replace these templated files with your own code. After the Wizard creates a new Android project called WebApp, you need to replace the contents of the following three files, under the WebApp directory with the provided code:


■ src\webApp.WebApp\

Tools such as the Android Market use the AndroidManifest.xml file to define what kinds of things your program will seek to do. This example needs to access the Internet, so that is why it is being modified.

The contents of AndroidManifest.xml should be as follows: <?xml version="1.0" encoding="utf-8"?>

<manifest xmlns:android="" package="webApp.WebApp" android:versionCode="1"

android:versionName="1.0.0"> <application android:icon="@drawable/icon" android:label="@string/app_name"> <activity android:name=".WebAppM android:label="@string/app_name"> <intent-filter>

<action android:name="android.intent.action.MAIN" /> <category android:name="android.intent.category.LAUNCHER" /> </intent-filter> </activity> </application>

<uses-permission android:name="android.permission.INTERNET" /> </manifest>

Our AndroidManifest.xml file differs from the Android Project Wizard's file by one line: the uses-permission line, which specifies that the application needs to be permitted to access the Internet. No surprise there!

To maintain tight control over what applications running on your handset can do, the engineers who designed Android use this file to control what functions and features of the cellphone the program is allowed to use.

Next up, the contents of the res\layout\main.xml file should be modified to define how we want the application's layout to look, as follows:

<?xml version="1.0" encoding="utf-8"?>

<LinearLayout xmlns:android="" android:layout_width="wrap_content" android:layout_height="wrap_content" android:orientation="vertical"> <WebView android:id="@+id/webview"




Here, a WebView layout is defined so that it occupies the entire area of the application's main window. This is accomplished by setting the layout width and height to fill_parent. The simple application being designed here is nothing more than a wrapper for the WebKit browser, but you can easily expand it to include its own custom menus, and perhaps other views that differ from the embedded browser.

To keep things simple, here we simply embed the browser and present a shell of an application that you can expand later as your Java skills grow and develop.

Finally, the contents of the src\webApp.WebApp\ file should be replaced with code that will properly function as a browser-like application. To do this, the template should be replaced with this code, as follows: package webApp.WebApp;

import; import android.os.Bundle; import android.view.KeyEvent; import android.webkit.WebView; import android.webkit.WebViewClient;

public class WebApp extends Activity {

WebView webview;

private class WebAppClient extends WebViewClient {

@Override public boolean shouldOverrideUrlLoading(WebView view, String url)

view.loadUrl(url); return true;

public boolean onKeyDown(int keyCode, KeyEvent event) {

if ((keyCode == KeyEvent.KEYCODE_BACK) && webview.canGoBack()) {

webview.goBack(); return true;

return super.onKeyDown(keyCode, event);

@Override public void onCreate(Bundle savedlnstanceState) {

super.onCreate(savedlnstanceState); setContentView(R.layout.main);

webview = (WebView) findViewByld(; webview.setWebViewClient(new WebAppClient()); webview.getSettings().setJavaScriptEnabled(true); webview.loadUrl(""); // Comment out

^this line,

// webview.loadUrl(""); // uncomment and ^modify the URL in this one

^server side code

This code is designed to execute the WebKit browser within our application, enabling the user to navigate a website by clicking hyperlinks and pressing the Back button. Although it does nothing more than the standard web browser application that comes with Android, it enables us to modify it any way the web application design requires in the future. We simply need to add the code that overrides the standard browser behavior with our own custom-designed methods.

After replacing the three indicated files in the WebApp project, we can build the code, test it on the emulator, and then package it up to port to the Android cellphone. In keeping with the high-level nature of this chapter, we leave the details to you—you can explore the Google documentation on building an Android application in the links provided at the end of this chapter.

0 0

Post a comment