A Summary of the Wireless Web

Recently, there has been a huge surge of interest in wireless Internet access, and indeed in mobile computing in general. As everyone has become increasingly dependent on the World Wide Web, there is a desire to access it from anywhere . The technology now exists to enable you to do this, although the exact nature of this access is quite different from 'traditional' Internet access.

This difference has caused many problems, both for device manufacturers and consumers, as it has frequently been overlooked. Often, consumers have expected to get an all- singing , all- dancing , Web-surfing gadget, and have been disappointed with what they ended up with. However, the underlying potential of such devices is unquestionable. In order to make sense of this you need to look at features inherent in the devices that can be used for mobile Internet access. The most obvious of these features is that the device will be small. It follows on from this that:

• Display area is limited, being far smaller than a PC monitor. Color capability is becoming standard (due to improved display technologies, power consumption, and battery life), but display legibility is still partly reliant on viewing angle and lighting conditions.

• Processing power and memory is unlikely to compete with PCs.

• Multimedia capabilities will be severely challenged.

Already it's obvious that you cannot expect the sort of Web experience you are accustomed to using Web browsers on your PC. To further illustrate this, consider Figure 21-1, which shows the Wrox web site displayed on the screen of an Internet capable mobile phone:

Figure 21-1:

You'd have a hard time navigating through this site “ if you could even read it!

Of course, larger screened devices are available, such as the (significantly more expensive) Personal Digital Assistant (PDA) type devices out there. Some of the cutting edge ones support resolutions up to 640x480 pixels, so perhaps there is hope for viewing complex HTML pages. Most standard PDAs with smaller screens are also capable of viewing HTML, although the experience can be quite different from using a traditional Web browser.

There are also concerns when you consider the 'wireless' aspect of mobile Internet access. Put plainly, you can never expect the sort of bandwidth that is possible in hardwired systems. Not only that, but the signal quality is likely to be variable “ you might temporarily lose communications; while driving through a tunnel, for example.

Most current (second generation, or 2G) systems allow a data transfer rate of around 9.6Kbps (9600 bits per second), which is comparable to the modems of yesteryear, and about six times slower than you might expect on a standard modem line (and orders of magnitude slower than more professional systems). Although many mobile networks are now implementing systems allowing for faster access in the future, speeds are for the most part slower than you can achieve on a PC. GPRS (a so-called 2.5G technology), for example, is capable of speeds up to 115Kbps by using several channels simultaneously , although in practice you are more likely to achieve data transfer rates of 14.4-56Kbps, comparable to modem speeds. Third generation (3G) services are starting to become available, which while expensive, boast bandwidths of up to 2Mbps (2000Kbps), but at the time of writing are not universally available, and are having commercial teething troubles. When this is taken into account you can hardly expect streaming multimedia Web sites on mobile devices just yet, unless there is some interesting paint drying nearby that you can watch while things download.

These were the bad points. After reading them you may well be asking yourself how mobile Internet access will ever got off the ground. However, there are many things that are possible with mobile devices that aren't with PCs. It is only when you consider these possibilities that the true power becomes clear. The key point to remember is that mobile Internet access is mobile . It is available anywhere and anytime , without having to lug much hardware around with you. In addition, the fact that you carry it with you means that you are likely to be interested in information that pertains to your current situation and position (such as "Where's the closest Indian restaurant?"). In theory this kind of 'location- dependent' information should be accessible without actually entering information about where you are. After all, the network operator knows more or less where you are from the network cell you are in. Unfortunately, this kind of application has been slow to get going. It seems that network operators aren't too keen on handing out this information, although developments are occurring regularly, and I wouldn't be surprised if this capability was far more prevalent by the time you read this.

Even though mobile Internet access is a good idea, in the face of all the problems mentioned earlier, how do you make it work? Luckily, this isn't something you have to work out for yourselves. A lot of serious thought has been expended to come up with standards to get things moving. One solution that has taken off in Japan and is starting to spread into the rest of the world is i-Mode. This technology uses a cut-down version of HTML known as i-Mode cHTML (similar but not identical to the W3C cHTML standard). The standard that has the greatest prominence in Europe and the United States is the Wireless Application Protocol (WAP).

WAP

If you've had any experience using mobile devices to connect to Internet services, you've more than likely used a WAP-enabled device. Not only that, but I'd say it was very likely that you've heard the term 'WAP' on TV, seen it in magazines, and heard how much people seem to hate it. However, if you analyze the problems that people have with WAP, such as "It's too slow", "There's no color", "All the WAP sites look rubbish", and so on, you may notice that these can in all cases be explained by the limitations looked at in the last section “ and we weren't even considering WAP there.

Even so, it seems perfectly reasonable to wonder why you should bother with WAP at all.

In actual fact, WAP does quite a good job of dealing with these limitations, but the end result is still not enough to satisfy the e-generation. However, WAP is ready for the next generation of mobile communication networks “ without major changes “ and is likely to start to become more accepted as bandwidth increases . Of course, many people ask whether WAP will be here at all, or whether it will be replaced with something else. In order to address this point you need to take a step back and look at exactly what WAP is, and how it works.

The objective of WAP is, logically enough, to get information from the Internet to a mobile client. This isn't exactly simple, not least due to the fact that there is no physical connection between the Internet and the wireless network. In addition, building up any communication protocol is a lengthy process (I, for one, wouldn't fancy sitting down and reading through the specifications drawn up for Internet communications, even if I did have a spare month or two). Deciding what form data should take, what security measures should be taken, how data should be compressed and transmitted, etc. is by no means simple.

This is one thing that you can relax about though; the architects of WAP (the WAP forum) have analyzed the issues involved, and the results work fine. To summarize, the gap between the Internet and the wireless network is filled by what is known as a WAP gateway, which acts primarily as a protocol converter. Resources on the Internet are accessed by this gateway in much the same way as Internet clients do “ using HTTP. The gateway does this when it receives a request from a WAP enabled device, which is transmitted using WAP protocols. Once it has fetched the resource required, the gateway may perform additional processing (such as compressing files to optimize transmission) if necessary, and then will transmit the result back to the mobile client, again using WAP protocols. This is illustrated in Figure 21-2:

Figure 21-2:

This leads to a few questions, such as "What form do WAP resources take on the Internet?" and "How is security propagated between the mobile client and the origin server?" Again, these questions have been thought of already, which is part of the reason why the WAP specification ( freely available from www.wapforum.org) is so large and consists of so many sections. The latest version of this specification released (in July 2001) was WAP 2.0, but for now most browsers use the older version, 1.1, with a few using version 1.2, last updated June 2000. Version 1.1 is the version we'll concentrate on here. Instead of listing all the documents, I'll just point out the categories to which they belong:

• General WAP technologies :A selection of documents setting out the objectives of the WAP specification, and the various enabling technologies.

• The WAP protocol stack and WAP gateways :The means by which information is exchanged with the Internet, optimized to be as efficient as possible in a low bandwidth environment.

• WAP language specifications :Specifics on the way in which applications may be created for WAP-enabled devices.

The WAP push specification “ information on server-initiated WAP exchanges (that is, how information may be transmitted to WAP enabled devices without a direct request for it).

Much of this specification is advanced, certainly more advanced than we want to get into here, but it's reassuring to know that it is there.

Consider the WAP language specification section. This is the part of the specification that details how resources should be formatted on servers (as well as how they may be compressed for wireless transmission). From the discussion in the last section, it shouldn't be too much of a surprise that HTML isn't the language used by WAP devices. HTML is a relatively heavyweight language, containing much functionality that just doesn't fit in with the idea of quick mobile Internet access. It makes far more sense to create something new for the bulk of cheap mobile devices, something relatively simple, optimized for the considerations you looked at earlier, and lightweight. Something, in fact, like WML “ the Wireless Markup Language. We'll take a look at this in the next section.

Note that more complex devices, such as PDAs, don't suffer from quite such strict limitations when it comes to Internet content. Since they typically have larger screens than WAP enabled mobile phones they are more suited to HTML “ or at least very simple HTML to avoid the low bandwidth problem. Other options include cHTML, a variant of which is used in i-Mode as noted earlier, and the XHTML standard used in WAP version 2.0.

In case you are worried that omitting a full discussion of the new XHTML dialect is not 'future proofing' you, rest assured that enough of the key concepts and structure of WML survives. Learning WML will stand you in good stead for later XHTML devices. Also, as explained, using the mobile controls is to some extent language independent, so there's even less to worry about.

After looking at all this, I hope I can convince you that WAP is here to stay. So many technical challenges have been overcome and so much groundwork is in place, that launching a new and completely different means of wireless Internet access would be like reinventing the wheel. Of course, there are places where improvements may be made, but WAP is much more likely to evolve than to die.

WML

The Wireless Markup Language ( WML ) is the WAP forum's solution to the problem of formatting content for display on WAP browsers. It is an XML application and shares some features with HTML, although comparisons between these languages aren't that simple to draw. As mentioned earlier, a Web 'page' (taken here as the atomic unit of a Web site) isn't an obvious choice for a fragment of a WAP site. For a start, many Web pages contain far more information than would be usable on a mobile device, and the concept of separate frames containing extra information is also not easily translatable.

A single WML file is often called a deck, and contains one or more cards. Each card can be thought of as a screen-full of information, complete with text, graphics, hyperlinks , and so on. Depending on the characteristics of the browser, and the device used to display a given card, this 'screen' may fit completely into the device display area, be accessible via scrolling keys, or require other modes of user intervention to navigate through. Navigation between cards may be within a single deck, or between decks, as shown in Figure 21-3:

Figure 21-3:

Owing to the limitations detailed earlier, a size restriction has been placed on WML decks. A compiled WML deck may be no larger than 1,440 bytes. This is quite a small limit, and means that complete WML applications will rarely fit into a single deck, unless they are very simple. Also, as is apparent from the diagram in the last section, WML files may be stored on any existing Web server, such as IIS, PWS, Apache, etc. All that is required in order to do this is to configure the MIME types for WML and compiled WML files. When doing this it is worth adding the other MIME types that are used by WAP, as shown in the following table:

Description	MIME Type	Associated Extension
Plain WML file	text/vnd.wap.wml	.wml
Compiled WML file	application/vnd.wap.wmlc	.wmlc
WMLScript file	text/vnd.wap.wmlscript	.wmls
Compiled WMLScript file	application/vnd.wap.wmlscriptc	.wmlsc
Wireless Bitmap Image	image/vnd.wap.wbmp	.wbmp

WAP browsers may then access WML files using standard URL format.

Here is an example of a WML deck. This file can be found in the downloadable code for this chapter with the filename example1.wml :

  <?xml version="1.0"?>   <!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN"   "http://www.wapforum.org/DTD/wml_1.1.xml">     <wml>   <card id="first" title="First Card">   <p>   Welcome!<br/>   <a href="#second">Continue</a>   </p>   <do type="accept" label="Next">   <go href="#second"/>   </do>   </card>   <card id="second" title="Second Card">   <p>   Now into content...   </p>   <do type="prev">   <prev/>   </do>   </card>   </wml>  

Before analyzing this code let's have a quick look at the results on a WAP device simulator. For this example we'll use the Nokia WAP toolkit version 3.0 (the most recent version at the time of writing) simulating a Nokia 5100 phone. This toolkit is freely available at http://forum.nokia.com/ if you register for it, and comes with all the documentation necessary to set up and use the device simulators included (for brevity I won't cover this aspect here). Upon loading the example deck into the simulator, you see the content of the first card, shown in Figure 21-4:

Figure 21-4:

Here you have two choices “ you can follow the highlighted Continue link by pressing the default selection button on the device (on the simulator this involves clicking the mouse on it) or select Options by pressing the button beneath this text. A labeled button such as Options is called a softkey . If you follow the Continue link you'll reach the next card in the deck, as shown in Figure 21-5:

Figure 21-5:

This card has no hyperlink but contains text content and an additional softkey “ Back. This softkey will take you one place back in the history stack and return you to the first card. The code starts with the standard XML declaration necessary for any XML file:

 <?xml version="1.0"?> 

Next you have the DOCTYPE for the XML file. This resource specifies the WML 1.1 syntax and enables validation:

 <!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN"                      "http://www.wapforum.org/DTD/wml_1.1.xml"> 

Note that WML 1.2 is not used here. This is because most current devices (and emulators) don't support it. Using this version isn't a problem, as the code in this chapter is not WML 1.2 specific.

Next you have the root element, <wml> , which contains the WML deck:

 <wml>    ... </wml> 

The two cards that make up the deck are within this root element:

 <card id="first" title="First Card">    ... </card> <card id="second" title="Second Card">    ... </card> 

Each of these card elements has two attributes (there are many more possible, but these two are fine for a simple example):

• id :This identifies each card within the deck, and is essential for navigation between cards.

• title :This provides a string for the browser to use in the presentation of the card. The Nokia 5100 places this text at the top of its display area as shown in the earlier screenshots, but this is not always the case “ some browsers will display this in alternative ways; some will ignore it completely.

This kind of behavior is discussed in more detail in the section on device interoperability.

Next, look at each card in turn , starting with the one with the id attribute of first . This card contains two elements: <p> , a paragraph element that contains (among other things) text to display, and <do> , which defines a softkey:

 <p>    Welcome!<br/>    <a href="#second">Continue</a> </p> <do type="accept" label="Next">    <go href="#second"/> </do> 

The paragraph element contains the simple text Welcome! , a line break using the <br/> empty element (note that the trailing slash here is used to signify that the element is empty, unlike the similar <br> tag in HTML), and a hyperlink. WML hyperlinks use either the <anchor> element or the slightly less versatile <a> element. Here the <a> element is used, as this is enough for simple navigation. Enclosed in the element is the text that we want to display for the link, Continue , and the navigation itself is detailed by the element attributes.

The only attribute used here, href , contains the destination for the link. This link is meant to provide navigation to the other card in the deck, which has an id of second , so this is used for the attribute value. Note the use of a # symbol here, which is essentially XML fragment syntax, and points the browser at a specified card within a deck.

You could use a fully qualified URL here, such as http://www.somewhere.com/somedeck.wml#card1. If you point at a separate deck in this way, the card specifying section ( #card1 ) is optional. If omitted, the first card contained in the target deck will be navigated to.

The <do> element is a versatile one, and allows several different types of softkey to be created, the type being chosen by the type attribute. Here the type accept is used, which means this is a simple press to activate type key.

The label attribute is used when displaying the softkey. The Nokia 5100 browser requires the user to access the Options menu to activate accept type softkeys , where they are placed along with built in device options; see Figure 21-6:

Figure 21-6:

The Next softkey is shown highlighted in the preceding list.

The functionality of this softkey is determined by the content of the <do> element. In this case the element contains a <go> element that specifies navigation. This code uses the same destination for the softkey as for the #second hyperlink and so there are two ways of navigating to the other card in the deck. If there is more text contained in the <p> element, so that the Continue hyperlink doesn't appear without scrolling down, this softkey provides an alternative and possibly quicker method of getting to the second card.

The second card contains another <p> element, this time containing just some simple text, and another <do> element:

 <p>    Now into content... </p> <do type="prev">    <prev/> </do> 

This time the <do> element is of type prev and contains a simple empty element, <prev/> . This is a quick way of adding a Back link to a card, and is really worth using! The Nokia 5100 simulator shown here adds Back links by default, but this isn't always the case.

That completes the brief WML example, which although only scratches the surface of what is possible does show you the basics, and gives a general idea of the structures used.

For completeness, just remember that WML is a language similar to JavaScript (it is in fact a subset of ECMAScript) and enables simple client-side calculations. This can save round trips to the server (important in the low-bandwidth WAP world), and is useful for simple user input validation, for example.

However, this knowledge isn't essential to use the techniques found in the rest of this chapter, although it may be useful to get a wider understanding of wireless Internet access.

Device Interoperability

Before moving on to look at the ASP.NET mobile controls, it is worth considering what is probably the main problem with WML. WML was designed to specify content, not layout, meaning that different devices will often display the same WML in different ways. In itself this isn't a real problem, as in most cases the information contained in a file will be preserved. However, in certain situations usability may be severely hampered. In some cases, WML code that works fine on one device may be difficult or even impossible to make sense of when rendered on others.

In addition, many devices have certain quirks that may be exploited to enhance usability, but the syntax for these varies greatly. In particular, devices equipped with the Openwave (the new name for Phone.com) browser may use a proprietary set of WML extensions, requiring a different DTD file ( DOCTYPE ). If files using these are loaded into other browsers they will likely fail to work at all.

As a simple demonstration, look at an example from the last section on the Openwave Simulator (also available free of charge, from http://developer.phone.com/download/index.html, and comes with full instructions for use). The most recent version at the time of writing is version 6.2.2, and that is the version used for screenshots in this chapter. The first card looks like Figure 21-7:

Figure 21-7: Figure courtesy Openwave Systems Inc.

Here there is a tick softkey, which appears because the Continue link is selected, and enables you to follow this link. Note that the softkey defined by the <do> element is not displayed. Figure 21-8 shows how the screen looks when the hyperlink isn't selected:

Figure 21-8: Figure courtesy Openwave Systems Inc.

A Next softkey appears “ which is the one specified by the <do> element. accept type <do> elements on this browser are overridden by, among other things, softkeys created to follow hyperlinks.

The other card in the deck is shown in Figure 21-9:

Figure 21-9: Figure courtesy Openwave Systems Inc.

Note that no Back softkey is displayed. Devices equipped with this browser are expected to have a button for going back (an example of which can be seen in the first screenshot in this section, labeled Bck), meaning that this functionality is always available.

Before moving on, look at Figure 21-10, which shows the example1.wml file displayed on a Pocket PC 2003 device (this simulator is available as a download from MSDN):

Figure 21-10:

The first thing to realize here is that the title attribute for the <card> element isn't displayed. In fact, the WAP specification says that this attribute is optional and only intended as a suggestion to the browser to be used for display purposes if it chooses. This can cause problems, however, if you've only tested a WAP application on a browser that displays these titles, and are using them as an important source of information for the user. This is an example of a common pitfall to avoid when developing in WML “ you must test code on multiple browsers!

Another point to note here is that the Next softkey is successfully rendered as a clickable field at the bottom of the display.

Note

These browser comparisons are very basic, but they do illustrate some of the differences that often occur between browsers (although not fatal ones in this case). There are many more of these, but an in-depth discussion of the situation is beyond the scope of this chapter.

There are several solutions to this problem. The simplest, but also the hardest to maintain, is to provide different WML files for different devices. It is possible to detect the browser type by examining the HTTP_USER_AGENT header and then redirect the browser accordingly .

Slightly more advanced is the technique of generating WML dynamically, using ASP.NET or any other code generation technology. However, this can be tricky to implement, as many minor things need changing, which can make the code very confusing. This may also result in you creating more work for yourself as different decks may end up with quite different processing.

Another strategy is to make use of the fact that WML is an XML application and transform raw data with XSLT, using different stylesheets for different browsers. This can be used to good effect, although it is tricky to get started and requires a great deal of foresight to structure your stylesheets in an appropriate fashion.

Finally, you can use ASP.NET mobile controls. These may not allow as much versatility as other methods , but certainly seem to work OK and require much less effort on your part. As well as being able to generate WML they also cater for HTML and i-Mode browsers, making them suitable for sites that should work on WAP enabled devices, HTML browsers on PDAs, and i-Mode handsets. In theory this means that knowledge of WML is unnecessary, although I feel that a basic knowledge of the structure of WML pages can help you to design mobile Web forms in a better way. The rest of this chapter is dedicated to examining these controls.