Taking Internet Applications to the Mobile Phone

Internet applications are about to take a new direction, away from the familiar browser to a new generation of Internet appliances. It’s not going to be difficult to find the first of these Internet appliances – it’ll be in your pocket, your digital mobile phone. The millions of dollars that have formed the massive investment made in GSM mobile telephony networks are going to give Europe is going to have a head start over the rest of the world. Soon, web applications are going to have to deal with a whole new way of interacting with the world, a way that most definitely isn’t the traditional web browser.

The key to producing these applications is in understanding what WAP means to your Internet developments. WAP, the Wireless Applications Protocol is an important step on the route to an always-accessible Internet applications framework, allowing mobile phones to access simple text and form based web applications. Using a WAP-enabled mobile phone, you can send information to and from a web server – including information typed in by a user.

Working with a WAP architecture is very similar to working with traditional web applications architectures. A WAP gateway acts as an interface between the TCP/IP world and the mobile phone, translating information into a wireless protocol, and passing it to and from the phone. One thing to remember is that you don’t use HTML; instead WAP uses a mark up language of its own, WML. WML is defined as an XML DTD, so requires more care in implementation than a piece of HTML code. You will need to be sure that the tags you’re using are correctly terminated; otherwise a WML browser will fail to parse and display your page.

As WML browsers in WAP phones are what are currently termed as “micro browsers”, you’ll need to be careful how you design content that will be delivered by WAP. A phone’s display can only show 3 or 4 lines of text at a time, and this needs to be taken into account when design WML pages. A WML page is divided into “cards”, each of which is displayed as a separate entity by the WML browser. This deck of cards approach requires you to explicitly add navigation instructions to your cards, so that users will be able to access the information you’re delivering to their phones.

There’s a big problem here for WML developers: mobile phones from different manufacturers have very different operational metaphors. I recently switched from using a Nokia phone to a Motorola, and found that it took quite some time to move from the Nokia way of working to Motorola’s user interface. The same is true of WAP and WML. Phones from different manufacturers will implement their micro browser interfaces differently – so WML implements a very abstract navigation metaphor. If you’ve been used to using hyperlinks and navigation buttons in your HTML pages, you’ll need to take a good look at what WML requires you to do.

A DO block, with the associated GO command, handles navigation in WML. This allows you to navigate between cards or between pages on a server. Here a label displayed on the phone menu as “Next” will allow a user to move from one card to another in a deck.

You’ll notice that this needs to be a valid WML document, so don’t forget to terminate your GO statements with a trailing “/”, as in this case it’s a singleton XML element. The DO statement will be interpreted by the phone, and added to its own menu system as a navigation option for the current card. You can have several DO statements in one card, so that you can use a single page as an entry point for a selection of different WAP applications.

In order to call another page, you can call a specific page from a server. Here we’re sending values to a remote server by appending them to a page request. The WAP gateway will reformat this information into a standard HTTP POST request when calling the remote page.

You can use a WML page to capture information from a phone and transfer it to a user. One option is to use selection screens, which can be navigated with a phone’s normal user interface tools. The syntax for these is similar to standard HTML form elements:

This will display a pick list on the phone’s screen. It is also possible to use the phone’s keypad to input alphanumeric data.

This line of code is for an input screen that will allow a user to input 9 numeric characters into a concealed password screen, for use as a PIN to allow access to services – perhaps services that will be charged to the user’s credit card, or even to their phone bill…

Once input, a value is available to the rest of the cards in a deck, and can also be used by scripts written in the WMLS scripting language, which is designed to allow applications to be written that will only run on a mobile phone. It can also be passed back to the WAP gateway via a DO block.

The following section of code is designed to deliver a deck of cards that will be used as the introduction to a larger WAP application. An introductory card leads into a second card, which allows a user to select a service. This captures information, and then launches a third card. This takes a PIN, which is then transmitted (along with the service request) to a WAP gateway and then a web server,

So how can you move your Internet applications to take advantage of this next stage in its development?

One of the most useful tools around for experimenting with WML and WAP is Nokia’s WAP toolkit. This is a free download from the Nokia website. All you need to do is sign up to the development forum, which you’ll actually find quite useful. The documentation indicates that you need a 1.2 or better JDK to run the toolkit, which is implemented as a Java application. I had problems running the toolkit under the latest JDK from Sun, with it freezing in the splash screen every time I started it up. Luckily, my registration allowed me to access the site’s discussion forums, which quickly revealed that the version of the WAP toolkit that I’d downloaded was only actually compatible with a specific JDK – the 1.2.1 release. There’s a lot of useful information in the forums, which will help you get started developing WAP applications, and exchanging ideas with your peers.

What the WAP toolkit provides is a set of tools to simulate both a WAP gateway and a WAP-enabled phone. Nokia provides models of two sample phones, both in the 6100 series, the 6110 and the 6150. Whilst the phones are ostensibly part of the same family, they offer very different user interfaces to your WML applications. It’s possible to switch between phones whilst testing out an application, so that you can see how a card is displayed in each phone. It’s a pity that the WAP toolkit doesn’t demonstrate the functions of the forthcoming 7100 series phones, which is Nokia’s next generation WAP platform.

So what sort of application can you develop with these tools? I’ve been experimenting with using a common application server environment – Microsoft’s IIS 4.0 and Active Server Pages - to deliver a dynamic WAP application to the Nokia toolkit. By using this to access and modify the information in a simple database, this application can be used to demonstrate a simple WML interface to a wide range of applications. With a component-based application server environment delivering dynamic WML to a WAP phone, you can give mobile phone users the same types of applications that can be delivered to PC-based web browsers.

One problem with using an environment like the WAP toolkit with a web application technology like ASP is in debugging your applications. By default all the error messages produced by IIS 4.0 are HL, so can’t be compiled or displayed by the WAP toolkit, which only expects to receive WML. As most of the errors in my test application were simple syntax errors, or problems with an ODBC connection, it was easy enough to track them down by attempting to open the specific ASP pages in a XML-aware web browser like IE 5.0. Correctly generated WML pages would be listed, whilst errors would be displayed in HTML format.

Generating WML from ASP pages isn’t particularly difficult. It’s possible to force the HTTP headers for a page using the response server object. By setting a Response.ContentType so that the server delivers a MIME document type that will be recognised as WML to the WAP gateway is a matter of a single line of code:

Just follow it up with the DTD definition, and you’re ready to start delivering WML from your ASP pages. Using a text editor, or even Visual InterDev, you can then start to create a dynamic WML page, using the same techniques as you’d use with HTML. One useful tip is to use Allaire’s HomeSite 4.0 as your editor, as not only does it contain a set of rules for verifying ASP syntax, but it also includes a WML verification tool.

The following section of ASP code is designed to handle the input from a WML page, processing it, and then delivering an appropriate response. A PIN and a service request have been delivered by the calling WML page using an embedded HTTP POST, which is interpreted by the ASP server as a form submission. This is used to control the flow through the page, allowing access to separate functions – here a tool for adding services to a mobile account or to add units to a pre-pay service.

Using these techniques it’s possible to take advantage of any feature of ASP that doesn’t directly generate HTML content. You can use existing COM objects in your WML applications, including ADO database access. If you’re working with something more complex you can create your own server components using Visual Basic or Visual C++. The same rules apply to any web application server environment, from JavaBeans to Cold Fusion. If a server can parse the embedded code or use the servlets you’ve written, it can deliver WML to a WAP gateway and your applications to a mobile phone.

So how can we extend this to being just another interface to our web applications? By extending the use of application servers and dynamically generated content, we can start designing our applications to be “channel independent”. This concept allows us to develop web applications that are closer in concept to the familiar distributed applications. By defining APIs or document formats, we can allow different types of device access to our services, purely by adding filters or output processors to our data streams or dynamic documents. Not only can these techniques allow us to create HTML and WML applications, but also interactive TV and any future delivery channels that may appear suddenly…

Summary

• WAP and WML will allow us to deliver web applications to mobile phones
• WML is an XML document format, so has a very strict syntax
• Nokia have produced a useful tool for developing and testing WML applications and pages
• You can deliver WML from familiar application server environments, including ASP
• We can use this as the basis for developing channel independent applications that can deliver to web browsers, mobile phones and interactive TV.