Setting the Stage for Wireless Development
Wireless application development began as a niche field but grew rapidly when the second generation of the Wireless Application Protocol (WAP) appeared. The WAP 2.0 specification introduced improvements that made it easier to build and run mobile sites on a wide range of handsets, feature phones, and even early smartphones. The technology relies on a lightweight markup language called Wireless Markup Language (WML) and a client‑side scripting language named WMLScript. Understanding the relationship between these two components, as well as the underlying transport mechanisms, is essential for anyone who wants to create a true WAP‑ready web presence.
WML is a simplified markup language that resembles HTML but is tailored to the limited bandwidth and processing power of early mobile devices. It contains a set of elements such as <card>, <text>, and <display> that allow developers to craft interactive menus, form inputs, and display blocks. WMLScript, on the other hand, is executed entirely on the client side, much like JavaScript, but its syntax is distinct and includes constructs such as function, var, and if statements. Together, WML and WMLScript provide the framework for responsive, data‑driven interactions over limited radio channels.
The primary benefit of WAP is that it enables mobile handsets to communicate through a gateway that translates between the wireless protocols used by the device and the HTTP protocols used by the server. For this translation to work correctly, the device’s gateway must recognize the content type of the payload it receives. That means the server must send an HTTP header that tells the gateway the message is WML. If the header is missing or mis‑specified, the gateway may drop the message or render it incorrectly.
In addition to the content header, WML documents often contain embedded images, form controls, or dynamic data such as dates and prices. Because the gateway acts as a proxy, all requests from a device must first reach the gateway and then be forwarded to the web server. The gateway itself can also generate a WML response when it receives an HTTP request. The gateway therefore expects a Content-Type header like text/vnd.wap.wml so it can process the response and deliver it to the handset. Missing or wrong headers break the communication chain, so developers must pay careful attention to these details from the very first line of a script.
To experiment with WAP early on, the OpenWave SDK provides a local emulator that mimics the behavior of real handsets. The emulator can load WML pages from a local directory or request them over a network, thereby allowing developers to see how the page renders without needing physical devices. The SDK also offers a command‑line tool that can send WML requests to a test gateway. These tools were essential during the WAP 2.0 rollout because they let developers debug formatting issues, test navigation between cards, and observe how a WMLScript runs on the client side.
Because WMLScript is executed on the device, developers often use it for simple calculations such as currency conversions or for formatting phone‑number fields. It can also perform lightweight validation before sending data back to the server. The scripts run in a sandboxed environment, meaning that they cannot access server‑side resources directly. This limitation, while restrictive, encourages a clear separation between presentation and data logic. Developers typically handle data retrieval and business logic on the server using languages like PHP or ASP, then emit pure WML to the client. The server script can embed PHP code that fetches the current date, retrieves the latest news headline, or queries a database. The resulting WML is then wrapped in a <wml> root element and served with the correct content type header.
Because WML documents are tiny and rely heavily on the gateway, developers can build lightweight services that provide quick responses over slow links. Examples include mobile banking menus, weather alerts, or simple shopping cart views. These services run with minimal server overhead, and the gateway’s compression algorithms reduce bandwidth usage further. When a developer first sets up a WAP project, the learning curve is steep, but once the fundamentals are mastered, the ability to deliver content to the handset becomes straightforward.
To get started, create a new directory on your workstation and place an empty text file named index.wml inside. Write a few lines of WML that define a card and a go element that points to a placeholder URL. Next, open the OpenWave SDK, configure it to watch the directory, and let the emulator load the file. The first time you run the emulator you’ll see the basic skeleton of a WAP page, confirming that the server has sent the correct headers and that the gateway has processed them. From there, you can incrementally add WMLScript functions, embed dynamic PHP or ASP code, and extend the application to interact with a database or a remote API. This incremental approach keeps the learning curve manageable while giving you tangible results early on.
Throughout this process, keep in mind that the ultimate goal is to serve WML content that devices can render. Whether the server is Apache, IIS, or any other HTTP daemon, it must return a Content-Type header that matches the MIME type for WML. The gateway will then transform the payload as needed before it reaches the handset. Once you have the basics in place - a working WML file, a correctly configured server, and a functioning emulator - the stage is set for building richer, data‑driven WAP applications that can leverage PHP or ASP for server‑side logic.
Preparing Your Web Server for WAP Traffic
Before a mobile handset can request a WML page from a web server, the server must recognize the request and deliver the correct MIME type. Both Apache and IIS expose configuration files that can be edited to add or modify MIME types for specific file extensions. If the server does not recognize .wml as a valid content type, the gateway will reject the response, and the handset will show a blank screen or an error. That’s why many developers start by creating a dedicated MIME entry that maps .wml to text/vnd.wap.wml. The procedure for adding the entry differs slightly between the two platforms, but the concept is the same.
On Apache, the httpd.conf file holds global server settings. To add a new MIME type, open the file and locate the AddType directives. Append a line that reads AddType text/vnd.wap.wml .wml. When Apache starts, it reads this directive and associates the extension with the MIME type. In some installations, the MIME type may already be defined, but confirming its presence is a good habit. After saving the file, restart the server to apply the changes. You can test the new mapping by issuing a simple HTTP request to a *.wml file and inspecting the response headers. A correctly configured server will include the Content-Type line in the header.
In IIS, the MIME type configuration lives in the web.config file or can be set via the graphical interface. The easiest way to ensure that WML files are served with the right type is to use the MIME map feature. Navigate to the site’s root, open web.config, and locate the MimeMap elements inside the system.webServer/staticContent section. Add a new MimeMap entry that sets the fileExtension to .wml and the mimeType to text/vnd.wap.wml. IIS then applies this mapping for all outgoing responses that match the extension. Because IIS can host multiple sites, it’s possible to set a global MIME type in the applicationHost.config file, ensuring that every site on the server honors the same mapping.
Once the MIME type is registered, you must also consider the gateway’s ability to handle requests from the handset. Many developers use the same OpenWave SDK to emulate a gateway, but if you want to test against a live network gateway, configure the device’s WAP profile to point to the test server. Handsets typically support two WAP modes: classic WAP and WAP 2.0. In classic mode, the gateway expects a Content-Type header that contains text/vnd.wap.wml and may also require a Transfer-Encoding: binary header. WAP 2.0 gateways are more tolerant but still expect the same content type. When you send a request to the server, the gateway checks the header, performs any necessary protocol translation, and forwards the result to the handset. If the header is absent, the gateway refuses to deliver the page.
With the MIME type in place, the next step is to create a server side script that can emit WML. Developers often choose PHP or ASP because both provide robust database connectivity and easy embedding of dynamic data. In the simplest scenario, the script just prints static WML to the output stream. However, you can extend the script to generate a Content-Type header on the fly. For example, a PHP file that begins with header('Content-Type: text/vnd.wap.wml'); will explicitly set the MIME type for that request. That approach is handy when you want to serve WML from a script that doesn’t use a file extension, such as index.php that outputs WML content based on user input or query parameters.
When you embed PHP or ASP code inside a WML document, the server evaluates the code at request time, producing a final WML string. The resulting output must not contain any stray characters or HTML tags that would confuse the handset’s renderer. Because the OpenWave emulator reads files directly from the file system, it also serves as a quick debugging tool for the markup. If you upload a new version of index.wml to the server and refresh the emulator, the page re‑loads automatically, allowing you to inspect any changes immediately. If you notice that navigation between cards is broken, you can revisit the go element’s href attribute and confirm that the target is a valid URL or a relative path that the gateway can handle.
In addition to the MIME type, developers must consider other HTTP headers that can affect the handset’s ability to render the page. The Cache-Control header, for instance, tells the gateway whether it should cache the response. Handsets that operate on limited radio resources benefit from caching frequently accessed pages, reducing the number of round‑trips to the server. A simple header line such as Cache-Control: no-cache instructs the gateway to fetch a fresh copy on each request. Conversely, Cache-Control: max-age=3600 allows the gateway to keep the response cached for one hour.
Because WAP servers are often deployed on the same machines that host regular web sites, maintaining a clear separation of concerns is valuable. For instance, one sub‑domain could serve the WAP pages, while another hosts the full HTML site. By directing all WML traffic to the dedicated sub‑domain, developers can avoid accidental content leakage or header mismatches. When setting up that sub‑domain, copy the AddType or MimeMap directive into its web.config or httpd.conf file, then reload the server. After that, any *.wml file requested through that sub‑domain will automatically receive the correct content type, and the gateway will interpret it without manual intervention.
Once the server is configured to recognize WML, the next phase is to populate it with actual content. Developers typically create a directory that holds a set of WML files, each representing a screen or menu on the handset. The OpenWave emulator can point to this directory, allowing you to view the pages locally. From there, you can add WMLScript blocks, integrate PHP or ASP code to fetch data, and test each change through the emulator. Because the gateway compresses and translates the data, the pages are small enough to load quickly even on slow radio links. As a result, developers can iterate rapidly, adding new screens or menus with minimal effort.
In short, a properly configured web server is the backbone of any WAP application. By ensuring that .wml files are mapped to text/vnd.wap.wml, setting correct cache headers, and providing clean, well‑formatted responses, you remove a large number of obstacles that could otherwise hinder handset connectivity. This foundation frees the developer to focus on business logic - whether that logic lives in PHP, ASP, or a RESTful service - and on designing an intuitive user experience for mobile users.
Creating and Testing WML Applications
Once the server is ready to deliver WML content, the next step is to write a minimal page and test it through the OpenWave emulator. The most common starting point is a file named index.wml that contains a <wml> root, a <card> element, and a simple menu item. Below is an example of a very small WML file that presents a single card and a link to another page. The link uses the go element, which is the mechanism for navigation in WML. Because the href attribute must reference a valid URL, you can point it at http://localhost/news.wml as a placeholder that will later be replaced by an actual file or a dynamic script.
<?xml version="1.0" encoding="UTF-8"?><wml xmlns="http://www.wapforum.org/2001/wml">
<card id="home">
<title>Home</title>
<text>Welcome to the demo page. Select an option:</text>
<p>
<go href="http://localhost/news.wml" value="News"></go>
</p>
</card>
</wml>
To see how this page looks on a handset, place it in the server’s document root, then start the OpenWave emulator. The emulator will request the file from the server, which in turn will respond with the Content-Type header. The gateway reads this header, verifies that it is a WML document, and then passes the content to the handset’s browser. If the page loads correctly, you’ll see the card title and the “News” link rendered on the screen. This step confirms that the server and gateway are communicating properly.
Once the basic page is working, the next logical step is to add client‑side logic using WMLScript. You can embed a script tag inside the card element to define functions that run when the handset processes the page. For example, you might want to display the current time or perform simple validation on an input field. Below is a script that defines a function to format the current date. The function uses the display tag to render the formatted date in the next card. When the user taps the “Show Time” link, the script will execute on the handset and update the screen.
<wml><card id="dateCard">
<title>Current Time</title>
<script>
function showDate() {
var d = new Date();
var s = d.getHours() + ":" + d.getMinutes();
return s;
}
</script>
<p>
<go href="#" onclick="showDate()"/>
<text>Tap to show the time</text>
</p>
</card>
</wml>
Testing this script in the emulator requires the handset to support WMLScript execution. If the emulator’s WMLScript engine is not enabled, the function will not run, and the output will simply be a static string. In that case, you can test the same logic on a real handset or a more advanced emulator that mimics WAP 2.0 capabilities.
When you need to incorporate dynamic server‑side data, PHP or ASP can be used to generate WML at runtime. For instance, a PHP script that pulls news headlines from a database can generate a card for each headline and display it in the handset’s menu. Below is an example of a PHP script that uses the header function to set the content type, then prints a WML document containing a list of headlines. The script assumes that you have a MySQL table named news with columns title and url. The script loops through the results and creates a go element for each headline.
<?phpheader('Content-Type: text/vnd.wap.wml');
$mysqli = new mysqli('localhost', 'user', 'pass', 'demo');
$results = $mysqli->query("SELECT title, url FROM news");
echo '<wml xmlns="http://www.wapforum.org/2001/wml">';
echo '<card id="news">';
echo '<title>News Headlines</title>';
while ($row = $results->fetch_assoc()) {
echo '<p><go href="' . htmlspecialchars($row["url"]) . '" value="' . htmlspecialchars($row["title"]) . '"/></p>';
}
echo '</card>';
echo '</wml>';
When this PHP script is executed on the server, it will output a WML document that the gateway sends to the handset. The emulator can display this page just like any static .wml file. By navigating to the news.php script, you’ll see a card that contains a list of news links pulled from the database. Because the data is generated on the fly, any change in the database is reflected immediately when the handset requests the page.
Finally, you can combine server‑side logic, client‑side WMLScript, and the OpenWave emulator to create a fully functional WAP application. Each new screen can be added by creating a new card in a separate WML file or by extending the existing PHP script to output a new card. Because the emulator reads the files directly from the file system, you can test changes in real time. If you find that the navigation between cards fails, verify that the go href attribute points to a valid URL or a relative path that the gateway can resolve. Also, check that the onclick attribute references a defined function. If you’re using WAP 2.0, the emulator’s settings may need to be adjusted to allow binary data transfer or to enable WMLScript execution.
In this way, the OpenWave emulator acts as a complete test harness for WML applications. By iterating through the steps of writing static markup, adding client‑side scripts, and incorporating server‑side PHP or ASP logic, developers can produce a mobile experience that is both responsive and functional. The combination of a correctly configured web server, accurate HTTP headers, and an efficient emulator ensures that the handset can load and display the WML content as intended, even over slow radio links.
No comments yet. Be the first to comment!