Understanding WAP Wireless Applications, Devices, and Services phần 2 potx

Page 13 Forum strengthen relations with organizations with which it already has an established liaison (e.g., W3C, ETSI, IETF, TIA, ECMA, etc.) as well as continue to meet with other relevant organizations. 1.8 Conclusions WAP enables network operators and content providers to reach a mass market. Although WAP-enabled phones are just in the process of being launched, there are today approximately 200 million GSM subscribers using wireless devices. Looking less than five years ahead, forecasts by major handset manufacturers predict this figure will probably rise to 700 or 800 million, and we have good reason to believe that the majority of handsets in use will support WAP. Without a doubt, WAP will add a new dimension to the use of mobile phones. References [1] vCard— The Electronic Business Card, Version 2.1, The Internet Mail Consortium (IMC), Sept. 18, 1996, http://www.imc.org/pdi/vcard-21.doc. [2] vCalendar— The Electronic Calendaring and Scheduling Format, Version 1.0, The Internet Mail Consortium (IMC), Sept. 18, 1996, http://www.imc. org/pdi/vcal-10.doc. [3] St. Laurent, S., and E. Cerami, Building XML Applications, New York: McGraw-Hill, 1999. Page 15 The Wireless Application Environment for Creating WAP Services and Applications Marcel van der Heijden and Martin Frost 2.1 Introduction In recent years, we have witnessed the incredible growth of the Internet: By now, almost all sources of information and many applications and services are available through this medium. Moreover, a whole new industry has arisen that offers networked applications and services that differ radically from traditional business models. CHAPTER 2 Contents 2.1 Introduction 2.2 The wireless markup language 2.3 Wireless markup language script 2.4 Byte- encoded WML and compiled WMLScript 2.5 Overview of the wireless telephony application interface 2.6 Migrating from WWW to WAP 2.7 Markup languages and XML 2.8 User agent capabilities and content negotiation 2.9 Miscellaneous elements of WAP of interest to developers 2.10 Available software tools 2.11 WML language reference While the growth of the Internet has been phenomenal, with e-mail often mentioned as one of the “killer applications,” there is one communications channel that has seen growth even more staggering. That channel currently has more than twice as many users as the Internet. We are talking about wireless personal communications. Page 16 While the Internet offers a relatively rich user experience and provides an enormous amount of information, its use is still largely limited to the computer at home or in the office. Wireless communication allows people to communicate regardless of where they may be, but unfortunately suffers some drawbacks when it comes to accessing information or delivering data services, an important one being the typically rather limited user interface capabilities of the wireless devices and low data rates of the wireless channel. Bringing together the two technologies while at the same time maintaining the strong points of each can create a new revolution all over again. Handset manufacturers, network equipment providers, wireless operators (see Chapter 8), value-added service providers, content providers, e-commerce operators and banks (see Chapter 10), newspapers, the transportation industry, corporate IT departments, and many, many more understand that the combination of the Internet and the wireless world will have far-reaching implications for them. The result of this synergy is WAP. WAP encompasses the specifications of a whole range of protocols and systems (see [1] and Chapter 1 for an overview). The part of WAP that developers will use to develop their wireless applications and services is the wireless application environment (WAE, see [2]). The WAE consists of three main parts: l The wireless markup language (WML); l The wireless markup language script (WMLScript); l The wireless telephony application interface (WTAI). The WAP architecture [1] was designed with a few objectives in mind: first, the limitations of the wireless communication channel needed to be addressed. These include low bandwidth by the standards of the modern Internet world, long delays, and frequently unreliable connections. For the most part, these concerns are addressed in the WAP communication protocol layers and do not usually affect WAP application developers. One exception is the low bandwidth. This is addressed by allowing WAP content, whether page layout in WML or client-side scripting in WMLScript, to be encoded into a compact binary format. This achieves a certain degree of compression over the textual form. Compiling WMLScript [3 ] into bytecode form also has as an advantage in that parsing of the script does not have to be performed on the TEAMFLY Team-Fly ® Page 17 client (mobile terminals are usually limited in terms of memory and processor speed). To ease the introduction of WAP, both for the developers providing applications and services and for the users, who must actually use them, WAP mimics to a large extent the Internet programming model. Throughout the WAP specifications, one can recognize analogies with the Internet and its technologies (see [4] for details): l HTML vs. WML; l JavaScript vs. WMLScript; l HTTP vs. WSP (wireless session protocol); l SSL/TLS vs. WTLS (wireless transaction layer security). WAP also supports a number of content formats, such as vCard and vCalendar, that are also in use on the Internet, MIME types, and URLs. These are only a few of the more obvious ones. This will enable developers with Internet experience to become familiar with the WAP technology relatively fast and leverage their existing experience and work. In this chapter we will introduce components of the WAE and discuss their most important elements. In that sense this chapter can be used as a brief (though not complete) reference. We will provide background information for those who will not be involved with WAP on the actual application development level but still need a good understanding of WAP application development. We will also provide practical tips from the field that may be of use to developers that need to start developing WAP applications. The aim is to provide a brief but informative introduction. 2.2 The wireless markup language One of the most important elements of the WAE is WML [5]. WML is described using the extensible markup language (XML) [6] as defined by the WML document type definition (DTD) that describes the format of a specific XML document. Documents that are marked up following the XML specifications are called well formed. When they also comply with their DTD, they are called valid. Some parts of WML were also based on the (now obsolete) HDML [7]. The definition of WML 1.1 deprecated Page 18 many of these features in favor of more familiar constructs drawn from HTML. Developers familiar with HTML will find that WML 1.1 shares many features with HTML and should find it relatively easy to start developing with WML. While pages on the Internet are arranged in pages (possibly compiled in a collection of frames), WML content is organized in decks consisting of one or more cards. This feature is particularly useful when WML content is viewed on devices with limited graphical capabilities and a small amount of screen area. It can also be useful in reducing the number of network transactions required to get the content into the device. Figure 2.1 graphically displays how an HTML page may be related to a WML deck of cards. The user agent (UA) is really the browser that renders the WML content. In contrast to Web browsers, which generally provide full graphical capabilities aimed at large displays, how a UA renders WML is very much dependent on the type of device that is used. It should be clear that WML content would be rendered very differently on a text-only mobile phone than on a PDA or smart-phone type of device with graphical capabilities (supporting the wireless bitmap— WBMP) and a significantly larger screen area. This is analogous to the way Internet developers often need to think about how their content will appear on each of the popular Web browsers. WML contains features intended to ensure that all content is readable and, more importantly, usable on all compliant devices. The distinction between readability and usability is an important one: there is little use in being able to read the text on a card if the interactive elements of the card Figure 2.1 HTML page (left) compared to a WML deck of cards (right). Page 19 are unavailable on the device. To understand this, consider the use of image maps in the Web world and the problems that a text-only Web browser would have. Chapter 3 discusses the usability aspects of WAP-enabled mobile services and applications in detail. A WML deck consists of text, with structure provided by elements (also called tags). Each element may have attributes that further specify its behavior and features. These attributes may be either required or optional (the exact requirements are given in the DTD for WML). All WML elements (tags) and attributes are case sensitive. Attributes are often used by WML to provide hints to the browser as to how the content should be rendered. It is considered good practice to make use of these hints wherever possible, as they help to ensure that the content is rendered well across a wide range of WAP devices. 2.2.1 Decks of cards As mentioned, the markup part of WML consists of tags (the markup) with attributes conveying additional information. All WML tags may have two standard optional attributes: id , which can be used to uniquely reference a particular element within the deck, and class , which is intended for use by the server side. A WML file must be enclosed within <wml> and </wml> tags. Within this pair, cards are created by the <card> and </card> tags. As well as the two standard attributes ( id and class ), the card element can have a title attribute that can be used by the UA in rendering the WML content. The id attribute for cards can be used to reference the card directly from a URL (e.g.,www.wap.net/index.wml#welcome). In WML it is also possible to define a template for all cards within a deck, in which certain WML event bindings can be predefined so that they need not be repeated later in every card. This is called shadowing in WAP parlance. These event bindings will have to be marked up between the template opening and closing tags. For instance, the next example specifies a ‘‘back” control for every card in the deck: <template> <do type="prev" name="back" label="Back"> <prev/> </do> </template> Page 20 It is possible to override the WML elements specified in the template by defining an event binding for the same event. In the next example we override (in a single deck) the do element in the template by redefining one with an identical name : <do type="prev" name="back" label="Return"> <go href="start.wmlc"/> </do> Note how this allows us to change the task bound to the do element. The do element will still be present in this card, but its behavior will differ from the default case set in the template. WML files can contain a head element that specifies information relevant to the entire deck of cards. This provides a mechanism for including various types of meta-information related to the deck, such as access control information, details of the character set, and a variety of other data. 2.2.2 User input WML provides a set of elements for receiving input from the user. These elements are similar to those found in HTML forms, but the details of the implementation are very different: instead of merely being able to send the information to a remote server, it is stored on the user agent in “browser variables.” More information on variables can be found in Section 2.2.5. There is an input element supporting the entry of numeric or alphanumeric input data. Attributes on the element can indicate what type of input is to be accepted: numeric, alphanumeric, or both, and even specify the exact format of the user input that is to be accepted (for example, a date entered as YYYY-MM-DD), whether empty input is acceptable as well, and the maximum length of the input. Another form of input is provided by the select element, which presents the user with a set of options from which to choose. For example: <select name="animal" title="Select Animal"> <option value="w">Wombat</option> <option value="b">Badger</option> </select> The input as well as the select and option elements can be tailored to the exact requirements using a relatively large number of attributes. Page 21 When developing WAP applications, user input is often a major consideration, and knowledge of the options available for tuning the various interface constructs is very important, especially given the wide range of WAP devices that will become available. Intelligent use of the attributes available will maximize usability across the full range of devices. 2.2.3 Task invocation One of the differences between WML and HTML is WML's concept of a task. In HTML, the range of controls available for user interaction is either hyperlinked text or images, which when activated will send the browser to a different URL or form button elements. WML generalizes this behavior by adding the concept of a task, which can be bound to a given hyperlink or other interface widget, and can perform various actions upon the browser. The HTML behavior, where activated hyperlinks will simply send the browser to a new URL, is provided by the go task in WML. When this task is executed, the browser will attempt to fetch and display the URL given by the task's href attribute. The following gives an example of how a behavior similar to that of HTML forms could be achieved, using the POST functionality of the go task. Note that the structuring of the data in the POST is not implicit in the structure of the input fields, as it is in HTML, but must be specified explicitly with a number of postfietd elements, each specifying a name and a value . Parameter1: <input key="parl"/><br/> Parameter2: <input key="par2"/><br/> <do type="accept" label="Call Script"> <go href="/cgi-bin/script.jsp" method="post"> <postfield name="x" value="$(parl)"/> <postfield name="y" value="$(par2)"/> </go> </do> The other available WML tasks are prev, which sends the browser to the last card in its history stack; refresh, which forces the browser to redraw its display with the latest values of all the browser variables (more on variables in Section 2.2.5); and noop , which does nothing (no operation). Calls to WMLScript are handled as a special case of the go task. Tasks may be invoked at many points in the WML browser: by events (Section 2.2.4), such as when a selection is made on a select element, Page 22 as the result of a script action, or as the result of a timer expiration (see Section 2.2.4), and directly by an element called do. The do element provides a user interface element that can be activated by the user, and which invokes a task when activated. These elements may be rendered in many different ways: as graphical buttons, soft keys, or voice commands. Figure 2.2 shows how different browsers may render the same piece of WML code. To assist the user agent in selecting the most appropriate form, the do element provides an attribute type, which offers a hint as to the function that it will perform. For example, a do element whose type is accept could be bound to the “yes” button on a mobile phone. Other types include prev , help , reset , etc., all of which may be used by the UA in the rendering of the do element. An optional label may be supplied as an attribute to provide a suitable text for the element. In addition to the use of do elements as a means of invoking tasks, the hyperlink concept can also be used to initiate actions, using WML anchors represented by the a or anchor WML elements. In fact, the a element simply allows for a shortened notation of anchor tag. The following WML constructs all have exactly the same functionality, each displaying the text “hyperlink” as a hyperlink, which will send the browser to the card with the name “card2’’ when activated. <anchor>hyperlink<go href="#card2"/></anchor> <anchor><go href="#card2"/>hyperlink</anchor> <a href="#card2">hyperlink</a> 2.2.4 Events Tasks can be invoked by certain events that represent state transitions within the UA. This is specified in WML using the onevent element. A number of event types are defined: onpick (an option element is selected by the user), onenterforward (a card is entered via a go task or through direct user intervention), onenterbackward (a card is entered using the prev task), and ontimer (a timer defined with the timer element expires). Typical usage of the onevent tag may be as follows: <onevent type="onpick"> <go href="choice.wml"/> </onevent> [...]... and push and is included in the capability negotiation described in Section 2. 8 Chapter 6 will describe in greater detail push services implemented in WAP 2. 9 .2 Wireless session protocol and HTTP headers WSP [13 ] contains certain elements that may be of direct interest to WAP application developers The WSP is a communications protocol that is based on, and in many ways similar to, the Internet standard... issues surrounding offering WAP services, such as user provisioning and billing, and we refer to Chapter 5, where the role and functionality of WAP gateways is described, albeit more from the network operator's point of view 2. 7 Markup languages and XML We have briefly outlined the possibilities in migrating Web applications to WAP and suggested that one of the reasons that WAP has enjoyed such great... WMLScript 2. 6.3 Using CGI and WAP gateways Currently, there are at least two ways in which WAP services can be deployed In one scenario, there is the situation where applications based on conventional Web servers are configured such that they provide content in WML and WMLScript format rather than HTML and JavaScript Using this model, a WAP gateway provides protocol conversion services (from HTTP to WSP) and. .. the Web, where services are created with HTML and JavaScript, to a WAP- based model, where WML and WMLScript are the available technologies Arguably, such developers will want to create WAP services that are very similar in terms of usability to the existing Web-based ones Thus, it may be of interest to briefly discuss the differences between both HTML and WML, and between JavaScript and WMLScript The... potential of WAP This chapter contains information on how to develop applications for a number of different types of mobile WAP devices For a WAP developer, it may be a good idea to use more than one WAP software package Experience has shown that some packages may contain bugs and vary in their implementation of certain WAP features Trying WAP applications on a number of WAP software tools and evaluating... and setting variables, changing the displayed URL; Dialogs: simple dialogs to alert or prompt the user As the WAP specifications evolve, it is likely that other WMLScript libraries will be defined An example may be the WMLScript crypto library that gives the WAP developer access to cryptographic functions and provides security functionality on the application level in WAP 1 .2 2.4 Byte-encoded WML and. .. For example: use url verify http://www .wap. net/libs/sec/ verify.wmlsc function process (params) { var ver=verify#test(params); … } WMLScript also provides a set of standard libraries (see Section 2. 3.5 and [9]) that are called as follows: LibName.functionName (params) 2. 3.3 Differences between ECMAScript and WMLScript ECMAScript is a standardized scripting language and a superset of JavaScript In this... differences between WMLScript and ECMAScript are briefly summarized in Table 2. 1 2. 3.4 WMLScript statements WMLScript provides a number of statements that should be familiar to anyone with knowledge of JavaScript: Page 28 Table 2. 1 A Summary of the Differences Between ECMAScript and WMLScript WMLScript ECMAScript Statements always followed by semicolon Comments between/* and */ Local variables only Compulsory... convergence of WML and HTML towards XHTML Special characters, such as angle brackets, nonbreaking space, and the like, are encoded in WML in a special way similar to HTML (for example, both   and &#×A0; represent a nonbreaking space) Comments may be included in WML decks between and > The use of images is also possible in WML WAP images are in a format called WBMP and one bit deep (black and white)... especially from the providers of content and services and from the developer communities, may be the relative ease of migration However, the multitude of available channels for providers to deliver their applications and services still raises many issues related to how these channels should be dealt with, while simultaneously minimizing development and maintenance costs and maintaining a high degree of flexibility . applications and services that differ radically from traditional business models. CHAPTER 2 Contents 2. 1 Introduction 2. 2 The wireless markup language 2. 3 Wireless markup language script 2. 4 Byte- encoded. WML and compiled WMLScript 2. 5 Overview of the wireless telephony application interface 2. 6 Migrating from WWW to WAP 2. 7 Markup languages and XML 2. 8 User agent capabilities and content. S., and E. Cerami, Building XML Applications, New York: McGraw-Hill, 1999. Page 15 The Wireless Application Environment for Creating WAP Services and Applications Marcel van der Heijden and