Differences in WML Implementations

This chapter touched earlier on some code that uses the USER_AGENT HTTP header to identify the client. The code used that header because, although WML is a specification, there is still a significant amount of room left for interpretation in the specifications. Different software providers implement the specification in slightly different ways. As a result, it is possible to write valid WML that works well on one device, but is essentially unusable on other devices. This means that no matter which platform or WAP SDK you choose to develop with, if you expect your application to work on multiple devices, you must test on other SDKs and simulators. Let's look at the large and small differences.

Major Differences

Two elements in the WML specification have been interpreted with significant differences: the <select> element and the <input> element.

The <select> element is slightly problematic due to the fact that it is overloaded in terms of functionality. It can be used as a means for value selection, akin to a drop-down list in HTML, and also to present a list of links. The different functionality is invoked by how the <option> elements are defined. If you use a statement such as <option value="myval">MyVal</option> you expect drop-down list type behavior, and if you use <option onpick="mydest">MyDest</option> you expect a list of links. The Phone.com implementation of the <select> element favors the "list of links" type implementation and displays all the <option> statements inline on the card on which they are defined. The Nokia and Ericsson devices favor the drop-down list and only display the currently selected (or default) option on the card, requiring the user to select the option element and then display a new presentation of all options. When the user selects one (or more) options, these values are then displayed back on the originating card. If the onpick attribute is defined, the user ends up navigating to a new deck or card from the window that presents the options, rather than the originating card.

The following code demonstrates how you would implement a drop-down list:

<card id="next">
 <do type="accept" label="show">
  <go href="#card2"/>
 </do>
 <p>
  Pick A Color
 <select name="color" ivalue="0">
  <option value="blue">blue</option>
  <option value="red">red</option>
  <option value="green">green</option>
  <option value="yellow">yellow</option>
 </select>
 </p>
</card>

<card id="card2">
 <do type="prev">
  <prev/>
</do>
 <p>
You picked $color
 </p>
</card>

Figures 14.7 through 14.10 show the sequence that the user will go through in choosing a value from your <select> element on the Nokia 7110.

Choosing a value from a <select> element on the Nokia device is a four-step process: navigate to and select the element, choose a value, return to the first card, and then navigate on. If the onpick action were defined in the <select> element, the user would not return to the card that defined the <select> but instead move straight on to the destination defined in the onpick attribute.

Figures 14.11 and 14.12 show the sequence that the user will go through in choosing a value from your <select> element on the UP.Browser.

Choosing a value from a <select> element on the UP.Browser is a two-step process that takes place on only one card. Select the element and navigate on.

You can see how the Nokia and Ericsson devices render the select statement in a manner that is unfavorable to the onpick attribute.

The other major implementation difference lies in how devices handle a card with multiple <input> elements. By default, the Phone.com UP.Browser will render each input element on a card of its own, whereas the Nokia and Ericsson browsers will render each input element on the same card. A user must then select an input element, which will drop them into a device-generated data entry card, allow them to enter data, and return them back to the main card. The user must take this action for each input element she wants to fill out. The end result is that it is simple for end users to overlook inputs, especially if those inputs are rendered below the initial viewable area on the card. Consider the following code and how it will render in the images displayed:

<card  id="inputit" title="myname">
     <do type="accept">
      <go href="#display"/>
     </do>
    <p>
    Input a name
    <input title="Name?" name="myname" format="M*m"/>
    Input a number
    <input title="Number?" name="mynumber" format="N*N" />
    Input a word
    <input title="Word?" name="myword"/>
    </p>
    </card>

Figures 14.13 through 14.16 show the sequence that the user goes through when filling in the three input elements defined in this card with the UP.Browser.

Notice how each <input> element ends up on a card of its own that the user can enter data into. The title attribute of the <input> element is never rendered.

Figures 14.17 through 14.19 show the sequence that the user will go through when filling in the three input elements defined in the card with the Ericsson device.

All three <input> elements are rendered with the title attribute showing as a link. When the user selects the link, he is presented with a text entry overlay where he can enter data. He returns back to the card with the data he just entered displaying.

This highlights the reason for using the wizard entry mode when working with data entry as described in the preceding section of this chapter.

Although Figures 14.13 through 14.16 show the default rendering for the UP.Browser from Phone.com, it is possible to write code that will display in a manner similar to the Ericsson and Nokia devices as you can see in Listing 14.2.

Listing 14.2 Presenting Non-Wizard Data Entry Through the UP.Browser from Phone.com

<?xml version="1.0"?>
<!DOCTYPE wml PUBLIC "-//PHONE.COM//DTD WML 1.1//EN"
  "http://www.phone.com/dtd/wml11.dtd" >
<wml>
  <card id="start">
   <do type="options" label="find">
    <go href="srchrslt.wml"/>
   </do>
   <p mode="nowrap">
    <select>
     <option title="edit">
     <onevent type="onpick">
      <spawn href="#fin">
       <setvar name="f" value="$(f:noesc)"/>
       <setvar name="label" value="Enter your Name"/>
       <receive name="f"/>
       <catch/>
      </spawn>
     </onevent>
      Name: $f
     </option>
     <option title="edit">
     <onevent type="onpick">
      <spawn href="#fin">
       <setvar name="f" value="$(l:noesc)"/>
       <setvar name="label" value="Enter a Word"/>
       <receive name="l"/>
       <catch/>
      </spawn>
     </onevent>
      Word: $l
     </option>
     <option title="edit">
     <onevent type=
							
							
							
							
							"onpick">
      <spawn href="#ph">
       <setvar name="p" value="$(p:noesc)"/>
       <receive name="p"/>
       <catch/>
      </spawn>
     </onevent>
      Number: $p
     </option>
    </select>
   </p>
  </card>

  <card id="fin">
   <do type="prev">
    <prev/>
   </do>
   <do type="accept">
    <exit>
     <send value="$(f:noesc)"/>
    </exit>
   </do>
   <p>
   Enter $label:
   <input name="f" value="$(f:noesc)"/>
   </p>
   </card>

 <card id="ph" title="number">
   <do type="accept">
    <exit>
     <send value="$(p:noesc)"/>
    </exit>
    </do>
   <p>
   Enter Number:
   <input name="p" format="*N"/>
   </p>
   </card>
 </wml>

Figures 14.20 through 14.22 show the sequence that the user will go through when filling in the three input elements defined in the card with the UP.Browser.

The <spawn>, <send>, and <exit> elements in Listing 14.2 are used to pass variables from the main card in the deck down into the entry cards, and then receive the values back. By doing this, the cards that contain the <input> elements are dropped off of the history stack as soon as they are exited. These elements are part of the Phone.com extensions to WML. For further detail on how to use these elements, please refer to the Phone.com UP.SDK Developer's Guide at http://developer.phone.com/dev/ts/htmldoc/40/devguide.

The presentation effect is similar to that of the Nokia 7110 and the Ericsson device (refer to Figures 14.17 through 14.19). The user chooses one of the options, enters data, and is returned back to the same card with the data she just entered now displaying. The title attribute of the <input> element is still never rendered.

Minor Differences

Several minor differences between the way different browsers handle WML elements have only minimal impact on the functionality of your application:

• The Nokia 7110 only displays images on a line of their own, centered.

• If there is more than <do type="options"> defined for a card, the UP.Browser from Phone.com lists them in the order they are defined under a key labeled Menu.

• The Nokia 7110 ignores all formatting tags such as <I>, <em>, <u>, <b>, <strong>, and so on.

• The UP.Browser from Phone.com never renders a title attribute for a card.

• The Nokia 7110 accepts escaped extra characters in the format attribute of an <input> element—for example,

  <input name="date" title="eneter date" format="NN-NN-NNNN"/>
  

• If there is an <anchor> or <a> element defined after an <input> or <select> element, the UP.Browser from Phone.com renders it on a card of its own.

For more of these minor implementation differences, refer to the vendors of the WAP browser you are working with.