Programming the Wireless Web

Learn how easy it is to make Web content accessible to wireless devices using WAP and WML.

Wireless Opener

The wheel, fire, sliced bread, peanut butter and jelly in the same jar… Each of these technological advancements changed the course of mankind. In recent years, the Internet has earned a place in that list. It has resulted in profound changes to the way many of us live and how companies do business.

However, the fact that all of the maps in the world are readily accessible via the World Wide Web isn’t of much help to the person who happens to be lost on some New York City street corner. Nor are mountains of real-time financial information of much use to the securities analyst who happens to be stuck in traffic. This is because the conventional Web is inaccessible to anyone who is not sitting at a computer with an Internet connection.

What’s the solution for these mobile information seekers? The Wireless Web, of course.

Armed with a modern cell phone, Personal Digital Assistant (PDA), or any “wireless-enabled” device, it’s now relatively easy to retrieve information from almost anywhere. This has largely been made possible through the collaborative efforts of a number of organizations worldwide, resulting in a new communications protocol known as the Wireless Application Protocol, or WAP.

In this article, we’ll explore WAP and the primary languages that WAP devices understand — WML and WMLScript. Along the way, we’ll look at the development tools necessary to produce content for WAP devices.

The Wireless Application Protocol

Simply put, WAP is a communications protocol that makes it possible for users to interact with information services via a wireless device such as a mobile phone, PDA, or pager. But why do we need yet another communication protocol?

The devices for which WAP was designed present several challenges that HTTP simply wasn’t designed to handle. They typically have very small screens, little CPU power, and limited amounts of memory. Furthermore, they are often connected to networks that suffer from frequent outages, high latency, and low bandwidth.

In addition to dealing with these constraints, WAP was designed as an open standard (like HTTP), which significantly reduces compatibility problems across different vendor’s implementations. Not only is it operating-system-independent, it is network-independent. WAP is capable of operating seamlessly on top of any wireless transmission protocol.

These features, coupled with the fact that WAP was created through the collaborative efforts of several industry behemoths (including Motorola, Nokia, and Ericsson), have led to the adoption of the protocol by 95 percent of the handset manufacturers.

The Mechanics of WAP

Wireless Figure 1
Figure One: Wireless Application Protocol browsing overview.

The WAP communications process is illustrated in Figure One. As you can see, the process doesn’t look all that different from a PC running a Web browser. From the Web server’s point of view, the WAP device has an IP address and sends requests for information via HTTP requests — just like a traditional browser. The difference, however, is that all traffic between the WAP device and the Web server actually flows through a WAP gateway hosted by your wireless service provider.

As Figure One illustrates, the steps involved in browsing with a WAP device are:

  1. When a WAP device makes a request for a given URL, the device first checks to see whether or not it already has an open connection to the service provider. If not, the device will dial into the modem located at the service provider, establishing a connection with the dial-in server.
  2. Once connected, all subsequent requests will pass through the WAP gateway, which converts the request from whatever transport protocol is employed by the wireless network to HTTP.
  3. The request then travels, just as any other HTTP request would, to the destination server.
  4. Upon receiving the request, the server processes it and sends the response back to the WAP device’s IP address.

This response is received by the WAP gateway, which compresses the data (into a binary format) and converts it for transmission over the wireless network to the WAP device.

The process continues until the wireless device disconnects from the provider’s modem.

An important element of this architecture is that the Web server doesn’t know it’s talking to a WAP enabled device. In fact, the Web server doesn’t have to know a single thing about WAP. That is all handled by the WAP gateway.

Now armed with a basic understanding of the WAP communication process, let’s turn our attention to some of the tools we need to build, test, and deploy applications targeted at WAP devices. First we’ll look at the Web server (Apache) and then at WAP emulators.

Apache Configuration

In order to correctly serve WML files from a Web server, the server must be configured to recognize requests for such files and label the responses appropriately. This is simply a matter of adding a few MIME types.

While adding a MIME type is relatively easy, the method you choose will depend on the degree of control you have over the Web server. If you are the sysadmin, you will probably want to add the MIME types to the Apache httpd.conf file. If you’re hosted on a full-service ISP that retains control over the server, you will want to create a .htaccess file and add the necessary information there. This file is essentially a per-directory configuration file that makes it possible to specify custom options without having to modify the system-wide configuration.

To add the MIME types to the httpd. conf file, simply open it in your favorite text editor and insert the following:

AddType text/vnd.wap.wml .wml
AddType text/vnd.wap.wmlscript .wmls
AddType image/vnd.wap.wbmp .wbmp

near the other AddType lines in your httpd.conf file.

Similarly, find the line that looks something like this:

DirectoryIndex index.html

and append index.wml to the list of filenames (your configuration may already have more than index.html there). The resulting line ought to look something like this:

DirectoryIndex index.html index.wml

This directive tells Apache that a file named index.wml in a directory will automatically be returned to a browser that makes a request without asking for a specific filename.

Next, save and close the file and restart Apache:

shell$ apachectl graceful

If, on the other hand, you must use a .htaccess file, create a file named .htaccess and insert the following lines:

AddType text/vnd.wap.wml wml
AddType text/vnd.wap.wmlscript wmls
AddType image/vnd.wap.wbmp wbmp
DirectoryIndex index.wml

Save this file to the directory in which you will store your WML/WMLScript files. Keep in mind that any configuration directives specified within a .htaccess file will be inherited by all subdirectories unless otherwise specified.

Having completed one of these processes, Apache is now ready to serve WML content. But what if you don’t have a WAP device or don’t want to use up your monthly airtime debugging your WAP content?

WML Emulators

Although you should always test applications on a number of “real” WAP devices before deploying them, it can be impractical and costly to do so during the development process. Therefore, a number of emulators have been developed. These emulators allow you to quickly test WAP applications without ever touching a WAP device. While a majority of the emulators only run on Windows, there are several emulators available for Linux.

Yospace (http://www.yospace.com) offers their Java-based SmartPhone Emulator for Linux. However, the free download is only a trial version. You can use it for up to five minutes at a time. A single-user license can be purchased from their Web site for $99.

In order to use the emulator, you’ll also need a Java runtime environment (JRE). The Sun JRE for Linux is available at http://java.sun.com/j2se/1.3/jre/download-linux.html/.

The installation process is pretty straightforward:

  1. Install the JRE as described in its documentation.
  2. Add the JRE bin directory to your path:

    shell$ export PATH=/{JRE-Install-Path}

  3. Install the SmartPhone emulator as described in its documentation.
  4. Add the SmartPhone resources directory to your path:

    shell$ export PATH=/{SmartPhone-Install-

  5. Run the emulator:

    shell$ SmartPhone_Emulator_1.2

Wireless Figure 2
Figure Two: The Yospace Smartphone Emulator.

A running Yospace SmartPhone emulator is pictured in Figure Two.

If you’re not willing to fork over the $99 for the license, there are a number of other Web-based alternatives available to the Linux user. Web-based emulators are particularly handy because you don’t need to install any extra software to use them.

Of all of the Web-based emulators available today, the Wapalizer (available at http://www.gelon.net) is arguably the most useful. It has a number of different phone “skins” that let you see how your content will look on a variety of popular mobile phones. Testing your WAP application is as simple as choosing a particular phone skin and entering the URL you’d like to test. The Gelon site also hosts a comprehensive directory of useful WAP resources.

If you have a computer that runs Windows, you might like to try out some of the Windows-based Emulators. See the Emulators on Windows sidebar for a list.

Emulators on Windows

The Openwave UP.SDK


One of the founders of the Wapforum (http://www.wapforum.org), Openwave (comprised in part of the company formally known as Phone.com) offers a rather impressive
developer’s toolkit for the Windows platform.

The Nokia SDK


The wireless communications giant Nokia offers a useful developers toolkit.


With Apache configured properly and a WAP emulator in hand, it’s time to create content. To do this, you need to learn a bit of the Wireless Markup Language (WML).

WML is the XML-based markup language used by WAP devices. Like HTML, it not only conveys content but also tells the WAP browser how the content should be rendered. Unlike HTML, however, WML is compiled into a binary format before it is delivered to the WAP device. This greatly reduces the size of the WML content, resulting in significantly lower transmission times.

To ensure correct compilation, the compiler requires that the WML code follow rigorous syntactical guidelines. You can’t get away with forgetting a closing tag like you can with most traditional Web browsers. Developers used to taking advantage of HTML’s rather flexible coding rules might initially find working with WML a bit of a chore.

Though WML is based on XML, it is very similar to HTML. If you already know HTML fairly well, the learning curve for WML will be rather small. WML has fewer tags than HTML, but most of them have identical (or nearly identical) counterparts in HTML.

Like other XML documents, WML documents begin with a prolog containing a pointer to the Document Type Definition (DTD) along with an XML declaration. In this case, of course, we’re using the WAP DTD:

<?xml version=”1.0″?>

Following the prolog is the document body. The document body is composed of a “deck,” which contains one or more “cards.” Since this terminology is obviously derived from playing cards, we’ll continue that analogy as a vehicle for explanation.

Imagine a deck of playing cards where each card is neatly stacked upon another. Looking down on this deck, you only see one card; but they are all readily available by simply using some means to cycle through the deck. The same concept applies to a WML deck.

Wireless Figure 3aWireless Figure 3b Wireless Figure 4aWireless Figure 4b
Figure Three: Listing One as seen in the Yospace Smartphone Emulator. Figure Four: SmartPhone Emulator display of Listing Two.

In order to reduce latency due to repeated requests for separate pages (cards), a WML file often consists of several cards, logically grouped together into a single deck. When the browser loads a WML file, the user is able to quickly navigate through several cards before needing to send another request to the server.

A deck is simply everything between the <wml> and </wml> tags. Each card located within that deck is delimited by <card> and </card> tags.

The example shown in Listing One and pictured in Figure Three makes use of the <go> and <do> tags to navigate between cards. The <do> tag associates an action (moving to a different card in this case) with a particular object in the user interface. The <do> tag found in this example is of the “accept” type. This binds to the device’s ACCEPT key, which is the button typically found directly below the screen on most mobile devices. The <go> tag found within the <do>..</do> tagset tells the device what to do when the user pushes the ACCEPT key. In this case, the user will be taken to Card2.

Listing One: A Simple Deck Containing Two Cards

<?xml version=”1.0″?>

<card id=”Card1″ title=”Card1″>
<do type=”accept” label=”go”>
<go href=”#Card2″/>
This is Card 1. Proceed to Card 2.

<card id=”Card2″ title=”Card2″>
<do type=”accept” label=”go”>
<go href=”#Card1″/>
This is Card 2. Why don’t you go back to Card 1, hmm…?


Of course <do> and <go> aren’t the only forms of navigation. Table One contains a summary of several other navigation tags and their respective purposes.

Table One: WML’s Other Navigation Tags

<a>hrefLink to another card.
<anchor>titleFunctions just like the HTML<anchor> tag, linking to another region of text within the same page (card).
<option>name, onpickFunctions like the HTML <option>
tag set,allowing the user to choose between various options.
<select>default, ikey, idefaultDenotes a list of options tags, just like in HTML.

Listing Two illustrates how the option tag can be used to make a selection.

Listing Two: The option Tag in Action

<?xml version=”1.0″?>

<card id=”Card1″ title=”Card1″>
What’s your favorite pizza topping?
<option onpick=”#pepperoni”>Pepperoni</option>
<option onpick=”#mushrooms”>Mushrooms</option>
<option onpick=”#cheese”>Extra cheese</option>

<card id=”pepperoni” title=”Pepperoni”>
Pepperoni it is then! Order the pizza!

<card id=”mushrooms” title=”Mushrooms”>
Make sure they’re not poisonous!

<card id=”cheese” title=”Cheese”>
Mmmmm, I love cheese!


WML Script

Just as JavaScript is useful for improving the interactivity of HTML documents, WMLScript brings similar capabilities to WML documents. Although a complete introduction to WMLScript syntax is beyond the scope of this article, a general overview of the underlying concepts is in order. So, let’s begin with several of WMLScript’s basic characteristics.

> WMLScript is a case-sensitive language.

This means that all function names, keywords, and variables must follow proper casing conventions. For example, the following variable names will all be considered unique: username, userName, UserNAME.

> Comments are delimited using C/C++ style syntax.

Single-line comments begin with //, and multiple-line comments begin with /* and end with */.

> WMLScript scripts are recognized by the file extension: .wmls

You saw this file extension earlier in the “Apache Configuration” section.

Data Types and Variables

WMLScript has five data types: Boolean, floating-point, integer, Invalid, and string. When necessary, WMLScript automatically converts between data types. Furthermore, WMLScript is a weakly typed language; that is, the data types of variables are not specified as part of their declaration. Instead, a variable’s type is interpreted according to the context in which it is used.

WMLScript variables must be declared before they are used. This simply means that you need to preface the intended variable name with the var keyword. The following are all examples of valid variable declaration:

var carColor;
var seatColor = “blue”;
var numberWheels = 4;

Once it has been declared, a variable can be accessed simply by using its name. In the following example, we first declare the variable named carMake and then assign the value “Nissan” to it:

var carMake;
carMake = “Nissan”;

The Standard Library

Like almost every mainstream language, WMLScript comes with a pre-built library of functions. This standard library contains those functions that are used to perform many of the most fundamental and common programming tasks. This would include such tasks as string manipulation and interface interaction.

Library functions are called using syntax similar to JavaScript’s LibraryFileName.FunctionName(). WMLScript’s pre-compiled libraries are automatically loaded into the browser memory, so that there is no need (as there is in some other languages) to explicitly load or import them at the top of the file.

The following libraries have been included in WMLScript: Lang, Float, String, URL, WMLBrowser, Console, and Dialog. A complete reference for WMLScript’s libraries can be found at http://developer.openwave.com/htmldoc/41/wmlscript/libraries.html.

User Defined Functions

User-created WMLScript libraries are referenced from within a WML document. The following example shows the correct syntax:


To illustrate this, consider Listing Three, which contains the code found in a library that we’ll call verifyRegInput.wmls. The purpose of the function verifyInput() is to verify the length of the user’s password.

Listing Three: verifyRegInput.wmls

// Verify the length and format of entered password. ‘extern’ refers to
// the fact that this function will be used outside of this file,
// namely within Listing Four.

extern function verifyInput(userPassword) {

if (String.length(password) < 7) {
WMLBrowser.SetVar(“password”, The password must be longer than 8 characters!);

We can then call the function verifyInput() from a WML document, as we have shown in Listing Four.

Listing Four: Calling WMLScript From an WML Document

<?xml version=”1.0″?>

<card id=”Password” title=”Password:”>
<do type=”accept” label=”verify”>
<go href=”verifyRegInput.wmls#verifyInput(‘$(password)’)”/>
<p> Password:
<input type=”text” name=”password”/>

Figure Five shows how Listing Four would be viewed through the Openwave emulator.

Wireless Figure 5aWireless Figure 5b
Figure Five: Openwave Emulator display of verifyInput().

Give It a Try

As you can see, building content and applications for WAP devices isn’t terribly difficult. If you’re already familiar with HTML and JavaScript and have access to a Web server, you’re most of the way there. You only need to find a WAP emulator and spend some time learning WML and WMLScript’s standard library. By browsing some of the Web sites listed in Resources and using your newfound knowledge, you should have little trouble.

You might also consider using PHP to produce dynamic content for your wireless users. In fact, you might write a library of PHP code to serve content to both traditional (HTML) and Wireless (WAP/WML) users. See Scripting the Web with PHP, pg. 24, for an introduction to PHP.


There are a number of great online resources devoted in whole or in part to the Wireless Application Protocol. You’ll find a wealth of WAP related information on these:

http://www.wapforum.org The recommended starting point for the Wireless Application Protocol.

http://www.anywhereyougo.com Provides information valuable to both the developer and IT manager. In addition to WAP, it discusses i-Mode, Bluetooth, PDAs/Handhelds, SMS, and the wireless industry in general.

http://www.allnetdevices.com Here you’ll find a number of resources pertinent to wireless development, perhaps most notably the “Wireless FAQ”

http://www.wap.com An extensive directory of WAP related sites as well as other high-level WAP information.

http://www.unstrung.com Over 500 articles devoted to the wireless industry, in addition to a directory of over 1200 wireless companies.

W.J. Gilmore is the author of A Programmer’s Introduction to PHP 4.0. He can be reached at wj@wjgilmore.com.

Comments are closed.