There's a growing buzz around the world of wireless Web applications, that is, Web sites accessible to phones and other wireless devices. You may have read that in ColdFusion 4.5 Allaire added support for something called WAP (Wireless Access Protocol).

It's the core of a powerful (and surprisingly easy) approach to creating applications for phones, pagers, two-way radios and more.

Perhaps you're wondering how all that works and whether you should jump on the bandwagon. How do you get started? How do you make it work in ColdFusion? What version of CF do you need? Are all wireless phones alike? What are the programming challenges of things such as browser detection, error handling, security and session management?

In this series of articles I hope to lay a foundation of principles and understanding to determine if and how you should go about developing wireless applications in ColdFusion. It's easy to do, but there are quite a few sources of confusion, so don't be surprised if your first attempts to look into it leave you wondering.

Much of the information in these articles is excerpted from my chapter on developing dynamic WAP applications using CF from the upcoming book, Professional WAP Programming (Wrox Press), which will already be out by the time you read this.

In this article, however, I'll lay some groundwork that I didn't get to address in that chapter (since mine was a later chapter in the book, and other writers addressed general WAP issues prior to it). I'll also share some of my own take on the state of affairs revolving around WAP application development.

First I want to address the question of if and how you should get started with WAP programming. I'll also introduce the challenges of converting an existing site to be supported on wireless devices.

More important, I'll show you how to create and begin testing WAP applications even if you don't have a wireless phone so you can at least get started.

I'll also identify some resources for learning more on your own.

In the remaining articles in this series, I'll address the specifics of doing WAP development in ColdFusion and those challenging programming issues I mentioned above.

Building on Previous Articles
This article builds on two previous ones that appeared in ColdFusion Developer's Journal.

In the December issue (Vol. 1, issue 6) the illustrious Ben Forta wrote "No Strings Attached," a great introductory article on WAP and WAP programming. He laid out some of the foundation principles of WAP and showed some basic WML (Wireless Markup Language) code. You can find it online at www1.sys-con.com/coldfusion/archives/0106/forta/index.html.

In the April issue (Vol. 2, issue 4) Paul Elisii wrote an excellent article entitled "ColdFusion in the Palm of Your Hand" ( www.sys-con.com/coldfusion/archives/0204/elisii/index.html). His focus was developing wireless applications for the Palm computing platform (PalmPilots and related devices). As he indicated, the "Web clipping" approach he described is limited to those devices, and he mentioned WAP as a competing standard typically found in wireless phones.

I recommend that you read both as a precursor to this article to get a taste of the WML language and to tide you over until next month when I'll begin showing some substantial examples and solutions.

Wireless Application Protocol
WAP-enabled phones are increasingly common; many if not most newly manufactured mobile phones now support the protocol.

The "wireless Web," as many phone companies call it, will open a whole new world for accessing information on the Web in a timely and succinct manner (and, again, on more than just phones).

The best news of all (for readers of this magazine) is that you can use ColdFusion to create and drive such wireless Web sites, so it also opens up huge opportunities for those willing to invest a little time in learning about WAP and the WML language.

Created as an open protocol managed by the independent WAP Forum ( www.wapforum.org), WAP is similar to - and in fact works in conjunction with - HTTP. The WML language is similar to HTML, but different enough so you really need to learn more than just the differences in syntax.

Developing for wireless devices really requires a new conception of what (and how much) to present to users and how to enable them to traverse the "site" you're offering. Of course, the limited display interface is the most obvious challenge, but data entry is also extremely challenging on those simple keypads (see Figure 1).

Don't let the minimal screen and features of the phone scare you away. With clever design, many powerful applications can leverage the ubiquity and flexibility - and indeed the minimalist interfaces - of these phones.

WML is easy to learn and should help wireless application development take off, much like Web page development did with the ease of learning and developing in HTML.

Slow Uptake of WAP Phones
Still, there will inevitably be those who will point to articles and press releases foretelling the doom of WML, and to the slow uptake of WAP phones, especially in the U.S. They're actually quite popular in Europe, Australia and Asia (in Japan there's also another wireless protocol growing in popularity, called iMode).

WAP phones and wireless Web services aren't yet taking the world by storm for a few reasons. I think it's just a matter of time, but these problems are indeed a stumbling block to broader reception in the near term. Should you wait? I don't think so. As I'll explain here, much of the consternation comes from simple confusion about the new technology. However, it won't take long for these problems to be overcome.

First, most phone service providers charge extra to access the wireless Web, but, fortunately, many are now letting it simply count against your talk-time minutes.

A considerable source of confusion (for users and information providers debating whether to "go wireless") is the limited number of sites listed on the front of the phones by default (as shown in Figure 1). If you're not listed there, how are people going to know about your site, let alone visit?

This is similar to the default portals that show up for users who install new copies of IE or Netscape. Novice users think "the Web" is only what's listed on Microsoft's MSN or Netscape's NetCenter sites. But we know those sites are simply ones that have established relationships with Microsoft or Netscape, enabling them to be listed there.

While most users know (or soon learn) they can type in any Web address (URL) on their browsers, many wireless phone users face a greater challenge when doing so. First, they need to know they can type in any address (it's usually buried in a menu system). Then they need to type it in laboriously using the phone's limited keyboard (shortened domain name aliases are becoming popular for many well-known sites).

More important, users need to know that the sites they're interested in (from broadly popular ones to those focused on some specific interest, or even an intranet) are available for wireless browsing. Many of the more popular sites are now creating wireless versions of their sites (often using the same URL but detecting and redirecting wireless visitors to a separate, WML-enabled section, as we'll discuss later). Like the introduction of a new "traditional" Web site, promotion and marketing of a "wireless" site is critical.

Finally, many users (and, again, potential information providers) are under the false impression that the wireless Web is merely about presenting mini versions of existing Web sites. While it's conceptually true, the wireless Web is actually about creating an entirely new class of applications suited to the smaller screen and, more important, leveraging the "always on, always at hand" nature of the phone.

Creating wireless apps is about rethinking what your users need, and either building modified versions of your existing applications to serve their unique needs or seeing the opportunity to create an entirely new application for wireless visitors.

In many ways this is like the early days of the Web - a lot of confusion, some hemming and hawing, and plenty of opportunity for early movers. Early adopters often get a bit bloodied, but in this case the significant similarity to HTML makes an investment of time and energy in WML seem very worthwhile, yet relatively inexpensive. It's really easy to get started. So let's do it.

Visiting (or Creating) a WML Site
Wireless Web sites (developed with WML) can't be viewed (yet) in normal HTML browsers. To do wireless development - or simply to visit some sites to get an idea of how things work - you don't need to have access to a wireless phone. If you do have access, great (though not all phones are created equal - more on that in a moment).

If you don't have a wireless phone, don't despair. Just head over to www.phone.com (the makers of the UP.browser, which is at the heart of many WAP-enabled phones). They have a simulator you can install on your workstation that presents a life-like replica of a phone (see Figure 1, taken from the simulator) that allows you to enter the URL of any site, whether on your local workstation or on any site on the network (Internet or intranet).

To get the free simulator (what they call the UP.SDK or software developer kit) you'll need to register (again free) on their developer site. It's painless (and doesn't seem to lead to a lot of junk mail, etc.) and a link is clearly offered on their Web site.

The term SDK is a bit of a misnomer. It conjures up the notion of APIs you need to learn, installable libraries you need to compile and "distributions" you need to keep up with. In this case it's a simple, single-installation program that loads the simulator and a couple of related programs onto your workstation.

The SDK also installs some excellent documentation, including getting started, tutorial and reference guides for both WML and the phone (as well as WMLScript, discussed later).

The phone.com developer site has additional resources for learning more, including a technical library, a training program and even alternative "skins" to make the simulator look like your favorite phone.

Once you install and start the simulator, it'll load the page shown in Figure 1 (if you're connected to the Internet). From there you can browse the sites offered (which include some interesting how-to's, examples and links to real WAP-enabled sites).

You can also visit sites of your own choosing. On a real phone you'd have to find the menu command that allows you to enter the URL using the keypad (did I say how annoying that is?). Fortunately, in the simulator you can simply type in a URL with your keyboard using the top GO line of the simulator window (not shown in Figure 1, but obvious in the simulator). Again, you can enter any valid URL to open a WAP-enabled Web site, whether local or on the Internet. (I should add that users of real phones can usually bookmark a site address that they've "typed" in, saving them from frustration in future visits.)

Other WAP Phones and Simulators
While the phone.com simulator and the UP.Phone browser included in many (if not most) wireless phones are very popular, they're not the only game in town. Sadly, like the challenges of different browsers in the early days of the Web (which still haunt us today), multiple WAP-enabled browsers are used to power phones and alternative simulators for those WAP browsers.

Nokia, a prominent wireless phone manufacturer, has their own embedded phone browser and simulator. While also based on WAP, it may process a page differently than a phone.com driven phone or simulator. Part of the problem is that the phone.com browser (in the phones and the simulator) allows for extensions to the WML language, just as Netscape extended HTML early on.

The formal specification (or DTD, Document Type Definition) for WML is laid out by the WAP Forum. If you rely solely on the phone.com simulator or a phone.com-driven phone for your testing and development, you run the risk of creating code that won't run in all phones. This is a reality. Many phones do embed the phone.com browser. However, it's up to you to decide what level of effort you want to expend on avoiding browser-specific WML and testing on multiple phones and simulators.

For early testing (rather than full-blown production rollout), it may be safe to let this issue slide while the industry sorts out these challenges. (Phone.com offers a 16-page white paper addressing this very issue of compatibility and standards integration. See www.phone.com/pub/IOTWP_0400.pdf.)

Next Issue, and Learning More in the Meantime
We're out of time and space. In the next issue I'll show you how to create WML applications in ColdFusion. It's really very easy. Remember that Ben Forta's December article shows the basics: the CFCONTENT tag and the special value needed for its "type" attribute, some simple WML code, issues such as case sensitivity of WML and more.

To learn more about WML and WAP, see the phone.com (or Nokia) documentation. Links to both are offered at a new developer area "reference desk" on the subject of WAP, available on the Allaire site at www.allaire.com/developer/TechnologyReference/wap.cfm.

Ben Forta recently took part in an interesting Q&A session on WAP and CF directions, available at www.allaire.com/handlers/index.cfm?id=15970&method=full.

In future articles I'll provide more substantial examples of WML development in ColdFusion. I'll also share information on some important items that will inevitably arise as you begin developing WML applications. I'll continue the discussion by identifying several tricks and traps to be aware of as you pursue this technology.

It's ever evolving, as is Allaire's support for it. It's an exciting time, and I hope you enjoy the ride!