WAPWMLWMLScript

WAP/WML/WMLScript

The most common standard of data transfer and presentation for a handheld device involves the combination of Wireless Application Protocol (WAP) with Wireless Markup Language (WML). Although WAP can be used with other forms of presentation, its coders primarily designed it to be used with WML.

WAP

Because of the small size of PCS devices, and because they operate with much less bandwidth or speed, than the rest of the Internet, a special protocol was necessary to redefine how they handle data transmission. This protocol needed to take into consideration that the average user views information on a screen with as little as five lines. When compared to a computer screen, this is a colossal difference. In addition to size, the typical PCS device does not support the same type of navigation that a desktop browser uses. Typically, you perform all PCS navigation with a list of options, or by pushing a button on the PCS device. To illustrate , compare CNN's top news page viewed on a cell phone (Figure 3.1) to the same page viewed with Internet Explorer on a desktop machine (Figure 3.2).

Figure 3.1. PCS browsing.

Figure 3.2. Desktop browsing.

The difference is dramatic. Color, layout, format, and fonts are severely restricted in most PCS devices. This is where WAP becomes important.

When a device connects to the Internet, several actions occur to bring the Web site to the requesting device. The device actually connects through a series of devices that incorporate different parts of the WAP application stack. The following outlines what happens when you request a Web page using WAP:

1. The device is turned on and accesses the Internet application via the minibrowser , a program that simply interprets the downloaded information and enables the user to interact with the presented data.

2. The device searches for and connects to service.

3. A Web site is selected.

4. A request is sent to gateway server using WAP.

5. The gateway server retrieves information as HTML, and converts it to the appropriate language.

6. The converted data is sent to the PCS device.

In other words, the process of fetching Internet content to a Web-enabled PCS device is handled in two parts. The first part requires the gateway server to connect to the Web server and retrieve the actual content of the Web page. The second part converts this content to a format compatible with the PCS device, and then transfers this content to the device. This is where WAP becomes an important part of the process.

The WAP application stack is made up of six different parts, as illustrated in Figure 3.3. Each part has its specific function, and it is important that you understand each part. The following will break down these parts so that you can get a better insight into PCS.

Figure 3.3. WAP application stack.

• Wireless Application Environment (WAE) This part of the stack defines the programming and scripting used for wireless applications. One of the most common of languages is WMLScript, which is discussed later in this chapter.

• Wireless Session Protocol (WSP) This part is responsible for the type of communication established with the PCS device. It defines whether the session is connection-oriented or connectionless. For example, because of the low impact its lost data will have on the resulting communication, a transfer of music would be connectionless. However, for more critical uses, guaranteed two-way communication is required. (This is similar to UDP versus TCP in traditional networking.)

• Wireless Transaction Session Protocol (WTSP) This part of WAP is used to classify data flow as reliable one-way, reliable two-way, or unreliable one-way.

• Wireless Transport Layer Security (WTLS) This layer is the security part of WAP. It provides encryption, authentication, data integrity checks, and more.

• Wireless Datagram Protocol (WDP) This part of WAP is where the data is broken down for the actual carrier. Because of the many different types of data transfer methods , the WDP ensures standardization, so any carrier can be used to transfer wireless data as long as it is compatible with WAP.

• Network carriers This is the carrier method (also called a bearer ) responsible for delivering the data to the PCS device. There are numerous carriers, but any will work as long as it can link to the WDP layer.

Once the data maneuvers through this stack, The PCS device processes it and presents it on the screen with a minibrowser . This can be as basic as maneuvering through a menu, or it can be as complex as playing an interactive game.

WML

Now that you have a basic understanding of WAP's purpose, let's examine the actual data and how it is presented. As mentioned before, WML is a markup language based on XML. It is not a programming language such as COBOL, Java, or even VBScript. It is only a formatting language that defines text and object placement and appearance. For example, if you wanted to define a word as bold, you would use the following:

<b>Hi!</b>.

This would result in " Hi! ".

However, WML also defines how navigation is performed, and how information is linked. The Internet most of us are familiar with uses Web pages to present data. These pages are actually files that sit on a remote host, and are downloaded to your client computer to be viewed in a browser. PCS devices use the same concept, but instead of viewing Web pages, you view "cards."

The following code is a sample card that forms the screen shot in Figure 3.4.

Figure 3.4. Display of a PCS card.

 <?xml version="1.0"?>  <!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.2//ED"  http://www.wapforum.org/DTD/wml12.dtd>  <wml>       <card>            <p>                 -Top Stories-<br/>                 <a accesskey = "1" href=http://mobile.cnn.com/sharon.wml  title="sharon">Sharon announces</a><br/>                 <a accesskey = "2" href=http://mobile.cnn.com/bush.wml  title="bush">Bush presses Congress</a><br/>                 <a accesksey = "3" href=http://mobile.cnn.com/colombia.wml  title="colombia">Colombia targets</a><br/>                 <a accesskey = "4" href=http://mobile.cnn.com/ex-priest.wml  title="ex-priest">Ex-priest gives</a><br/>            </p>       </card>  </wml> 

After looking at the sample code, do you see any similarity between it and XHTML? You should. In fact, WML is a brother to XHTML, and as such, has inherited all its rules. Note that each tag has a matching closing tag, or in the case of <br/> , is closed by the trailing backslash ( / ). Also, note the lowercase lettering and use of quotes. These are all requirements of XHTML that have been integrated into WML.

At this point, you might be wondering why PCS devices do not use XHTML instead of creating a new standard. The answer is that XHTML is too bloated for most PCS devices. Because of the number of properties and settings that XHTML can support, a browser that is XHTML-compatible takes up more memory than the relatively basic WML browser. Because a PCS device is limited in memory and size, it cannot support XHTML.

WMLScript

A developer can incorporate any number of programming or scripting languages into a Web page. These languages can be classified as either server-side scripting or client-side scripting. Server-side scripting typically handles complex issues or processes that must remain secure because of database connectivity. Client-side scripting, on the other hand, is typically used for simple programming needs, which often includes form validation and presentation enhancements, like trailing mouse images. However, client-side applications can also consist of complex programming.

Because of the rich variety of client-side programming, browsers that support programming languages like JavaScript must know how to handle all possible programming functions. This requirement means a browser that supports JavaScript must be large and cumbersome, which becomes an issue for space-starved PCS devices. In addition to the bloated browser software, an advanced client-side application must be downloaded to the browser every time it is used. Although the typical desktop computer can handle a 60K file with no problem, a file this size can be expensive to the PCS end user because of the limited bandwidth. This is why WMLScript has become the primary tool for PCS client-side programming.

WMLScript is very similar to JavaScript. It includes many of the same logical functions and syntax. However, WMLScript (WMLS) is less complex, and is optimized for PCS devices. For example, in the desktop world that uses JavaScript, if a programmer wants to alert a user that an action was invalid, she would use an alert('Stop') command. This would cause a message similar to Figure 3.5 to pop up on the screen.

Figure 3.5. JavaScript alert.

This type of immediate alert is not possible using current PCS devices. Whereas a desktop browser supports dynamic screens that appear on top of another screen, the PCS environment does not. To alert a user to an invalid entry, the value must be sent to a script file. The file must then detect the error and call another file, which in turn sends the alert to the screen of the PCS device. Finally, the acknowledgement will bounce back to the originating card, where the invalid entry was made. As you can see, the process is not complex, just lengthy.

To illustrate how WML works with WMLS, let's examine a sample application. The following is the WML and WMLS page used to create a sample addition program.

 Add.wml  _______________________________________________________________________  <?xml version="1.0"?>  <!DOCTYPE wml PUBLIC "-//PHONE.COM//DTD WML 1.3//EN"  "http://www.phone.com/dtd/wml13.dtd">  <!-- WML file created by Openwave SDK -->  <wml>       <card id="first" >             <onevent type="onenterforward">                     <refresh>                           <setvar name="firstVal" value=""/>                           <setvar name="secondVal" value=""/>                     </refresh>               </onevent>              <p>                    <do type="accept" label="Plus">                          <go href="#second"/>                   </do>                     Add two numbers...                 First #:                      <input type="text" name="firstVal" format="*N"/>              </p>        </card>        <card id="second">              <onevent type="onenterforward">                    <refresh>                      <setvar name="ans" value=""/>                   </refresh>            </onevent>              <p>                   <do type="accept" label="Add">                         <go href="addit.wmls#addNum()"/>                   </do>                   Second number                    <input type="text" name="secondVal" format="*N"/>                 $firstVal + ______ =             </p>       </card>       <card id="answer" title="answer">            <p>                   $firstVal + $secondVal = $ans             </p>       </card>  </wml>  _______________________________________________________________________  addIt.wmls  _______________________________________________________________________  extern function addNum(){       //grab incoming values       var fv = WMLBrowser.getVar("firstVal");       var sv = WMLBrowser.getVar("secondVal");       var val = WMLBrowser.getVar("ans");       //convert values to integers       var fvNum= Lang.parseInt(fv);       var svNum = Lang.parseInt(sv);       //add values       var valNum = fvNum + svNum;       //set answer and return to answer card in deck       WMLBrowser.setVar("ans", valNum);       WMLBrowser.go("#answer");  } 

Figure 3.6 shows screenshots of what this would look like using Openwave's SDK WAP 5.

Figure 3.6. WAP samples.

Note

These are three different screens, using four different files. This same application on a desktop browser such as Internet Explorer could be accomplished with one file and on one screen.

WML differs from any other formatting language. As you can see in the code sample, the WML file is actually a series of cards. Each card represents a possible screen, but is linked to the other cards in the deck , or group of cards. You can also see the proper implementation of XHTML and XML rules. Quotes, closed tags, and lowercase attributes are all used consistently within this file.