Is WAP Right for Your Mobile Needs?

Wireless Application Protocol (WAP) is one of three primary types of mobile and wireless applications. (The others are voice Internet applications and PDA embedded applications.) In this edition of Mobile & Wireless UPDATE, I'll look more closely at WAP applications, discuss important considerations for selecting WAP as your mobile solution, and talk about the challenges of using WAP applications.

Many people don't realize the opportunity that WAP-enabled phones provide for delivering mobile applications. A common misconception is that a mobile phone's form factor and functionality are unsuitable for custom business applications. However, my development team has deployed several line-of-business applications designed specifically for WAP-enabled phones that have been extremely successful.

Many companies want to mobilize their intranets, but such plans aren't practical or logical because mobile and wireless functionality is often quite different from the functionality of traditional desktop Web browsers. When you're planning a mobile application, the first step is to decide which functionality makes the most sense as a foundation for the mobile application. The next step is to clearly define the features you want in your WAP application. (Two examples are mobile timekeeping and expense reporting.) Then, you can start developing the application.

WAP applications present the following advantages for developing mobile applications:

Although WAP enjoys wide industry support, challenges can arise when you try to run an application across different devices and microbrowsers. Enabling support for different microbrowsers can be difficult, much like trying to support differences between Microsoft Internet Explorer (IE) and Netscape Navigator. This microbrowser challenge isn't a big problem if your system needs to support only a couple of devices; but when you want to support many devices or port your application to new devices in the future, using native Wireless Markup Language (WML) might not be the best approach. WML is problematic because techniques of delivering customized content—using style sheets with native WML, for example—can be complicated. For the past few months, I've been using the Microsoft Mobile Internet Toolkit (MIT), a Microsoft .NET technology that attempts to provide wide device support automatically. You can find a list of devices that support MIT at the following URL.
http://msdn.microsoft.com/vstudio/device/mitdevices.asp

MIT uses mobile controls within a mobile Web form for development; the runtime environment detects the capabilities of connecting mobile devices and returns appropriate content (e.g., HTML, WML, compact HTML—cHTML). Thus, you don't need to write device-specific code within your mobile application; MIT takes care of all dynamic content and customization.

In the next regular edition of Mobile & Wireless UPDATE on March 28, 2002, I'll take a closer look at the advantages and challenges of voice Internet applications.

* MY PERSONAL MOBILE SOLUTION
Many people have asked me to recommend a mobile phone or PDA. Until recently, no solution lived up to my expectations as a mobile user. Now, however, I've assembled several components that have become an effective personal mobile solution. Those components include an Ericsson R520m mobile phone (General Packet Radio Service—GPRS—enabled), a Compaq iPAQ Pocket PC H3870 PDA, and an Ericsson HBH-10 headset. I also have a VoiceStream Global System for Mobile Communication (GSM)/GPRS account for use with the R520m. The common denominator for my components is Bluetooth, which I believe is crucial in any mobile device. Bluetooth lets all these devices wirelessly transfer data in my Personal Area Network (PAN). My personal solution lets me take the following actions:

Until next time,
Steve Milroy, [email protected]