Chapter 10. Wireless Applications
Cellular phones, personal digital assistants (PDAs), and various other forms of wireless devices are taking the world by storm, opening new avenues for development as well as a whole host of challenges for developers. These devices are tiny compared to PCs, both in terms of physical size and processing power. This means that traditional HTML web pages are unacceptable, opening the door for new markup languages based on XML to take center stage.
This chapter introduces key concepts behind wireless technologies with particular emphasis on Wireless Markup Language (WML), a concise alternative to HTML that is custom made for wireless devices. The role of XSLT and servlets will also be explored though an example application that allows wireless users to browse movie theaters and showtimes.
10.1. Wireless Technologies
The family of technologies used by wireless devices is in its infancy, just a few years old. Because of this, there are a few competing markup languages in use today. In Japan, the i-mode protocol is the market leader. i-mode is defined by a company named NTT DoCoMo, utilizing a subset of HTML known as Compact HTML (cHTML). This markup language shares much of the same syntax as HTML but is essentially proprietary and is not based on XML.
In Europe and the United States, Wireless Access Protocol (WAP) is more popular. WAP currently utilizes WML, which is quite different from HTML and cHTML. In coming years, it is likely that most vendors will consolidate around XHTML Basic, although existing markup languages will need to be supported for quite some time. WML and cHTML will be seen as transitional technologies that allowed us to start experimenting with wireless services. At any rate, XSLT offers an excellent way to minimize risk as vendors work through their differences and technology progresses.
10.1.1. Why Not HTML?
HTML is used by nearly every web site and can theoretically be used by wireless devices as well. All that is needed is a web browser, a big display, lots of processing power, and sufficient bandwidth. Maybe not!
10.1.1.1. Problems with HTML
Consider this web page:
<boDY> <h1 align=center>Welcome to our home page!</h1 <ul> <LI>first item <LI>second item <Li>third item
Believe it or not, Netscape 4.x, Netscape 6, and IE 5.5 all display this page perfectly, without a single warning or error. Browsers are incredibly forgiving of errors in HTML, because vendors and end users want these browsers to display all web pages properly. Since only a tiny fraction of web sites are written using well-formed HTML, browsers must be written to silently recover from a wide range of errors. A browser that fails to display poorly written HTML is not acceptable in the marketplace because it fails on so many pages.
Nonprogrammers may view this as a benefit, because it allows them to create web sites without too much concern for capitalization, quotes, or properly nested tags. What they do not realize is that browsers are much more complex than they really need to be. Writing HTML parsers to handle every conceivable form of poorly written HTML results in huge, complex browsers that require far too many resources to execute on a handheld device.
Until all web pages are written using well-formed HTML or XHTML, browsers must support poorly written HTML. Until browsers are more stringent, however, web authors will continue writing sloppy code.
10.1.1.2. Limitations of current devices
Another blow against HTML is the simple fact that current wireless devices have tiny displays, small amounts of memory, and very slow network connections. Devices with five line displays simply cannot display HTML tables, framesets, and large fonts. Instead, these devices demand entirely new markup languages that are far smaller and make more efficient use of available resources.
Copyright © 2002 O'Reilly & Associates. All rights reserved.