Simon Bisson takes WML a step further, and begins to add scripts to his WML decks – running applications in a WAP phone.

The mobile Internet is growing faster than the original web. Cellnet have predicted over 500,000 users of their Wireless Application Protocol services by September 2000, and are working with the Halifax’s Internet bank IF to provide 150,000 WAP phones to the banks subscribers. Even the normally staid Financial Times has given away Motorola WAP phones to subscribers to the FT.com web site…

Last month we looked at how you could add simple WAP-ready pages to your web site, and created a simple WAP deck with a variant of the good old “hello world” script. The Wireless Markup Language (WML) used by WAP is very similar to HTML, and it shouldn’t be any surprise to find that it comes with a simple scripting language based on the ECMA-262 standard – the same root as our old friend JavaScript. WMLScript is a very important feature of any WAP browser implementation, as it means that you can run simple applications directly on the phone – and there’s not much new to learn if you’ve already worked with JavaScript.

So what can you use WMLScript for? Most large WAP sites will use it to take the load off a web server – and off WAP’s slow 9600 bps connections. If you can validate a user input on the phone without having to go from the handset to the WAP gateway to the web server to the application server (and all the way back again!) your WAP services will not only be faster, they’ll also be a lot cheaper to use – especially with WAP calls in the UK charged at between 5p and 20p a minute. But this isn’t the only use for WMLScript, and we’ve seen everything from simple games to currency converters that don’t need complex web applications behind them – just a few lines of WMLScript running on a phone.

The basic functions of WMLScript are found in six libraries:

• Lang: This library contains the core functions of WMLScript.
• Float: This library contains a set of typical arithmetical floating-point functions that are frequently used by applications.
• String: This library contains a set of string functions.
• URL: This library contains a set of functions for handling absolute URLs and relative URLs.
• WMLBrowser: This library contains functions that WMLScript uses to access the associated WML context.
• Dialogs: This library contains a set of typical user interface functions.

Using these it is possible to add extra functions to your WML pages. If you want to understand these in more detail, download the Nokia WAP Toolkit and spend some time with the WML Script reference manual. It’s 146 A4 pages of concentrated reference materials!

So how do you include WMLScript in your WML decks? As a quick example we’ll create a WML deck that will roll a die, and give you a result from 1 to 6.

First the cards that run the application:

This is a simple two-card deck. The first calls an external WMLScript document when the “Roll” soft key in the phone is pressed, whilst the second returns a result and displays it on your phone’s screen. Save the file as “dieroll.wml”.

The <do> block used to call the script is very much like the card navigation blocks we used last month. However, it doesn’t actually call a new card – this function is left to the WMLScript. The structure of the <go> statement is very important:

Here we’re calling a specific function – rollDie() – in a script, dieroll.wmls. The “#” in the href link allows you to target a specific function in a script, so a single script can contain multiple functions, saving you from having to connect to the server every time you need a script in your application.

The script we’re using to roll the die is simple enough, and uses two of the core WMLScript libraries:

This is a simple piece of code, but it shows the syntax of a WMLScript application.

First we initialise a function, in this case “rollDie()”. This is the function we called from the WML deck. This function doesn’t return any values, as it controls the content of the card it calls – if you want to return specific values or give your function inputs you’ll need to include them in your call. We could turn this into a generic multi-sided die by having a function rollDie(s), called as rollDie(20) if you wanted a 20-sided die rolled…

We then declare two variables for use in our application. WMLScript requires that all the variables are declared – but doesn’t mind what type they are! If you’re used to more complex languages like Java you’ll find this a little undisciplined, but then again, WMLScripts will be rather short!

A core mathematical function is then called. Lang.random(var) returns a number between 0 and your chosen value. As we’re writing a WAP application to throw a die we set this to roll a number between 0 and 6. This will return any of 0, 1, 2, 3, 4 and 5. We’ll need to convert this result into a number between 1 and 6. We could just add 1, but to make our application a little more complex we’ll use an “if…else if” block to turn the value into text. WMLScript comes with plenty of comparison operators to create logical statements.

Once we’ve generated a string containing the number “rolled”, we need to display it on our phone’s screen. The WMLBrowser library controls the micro-browser in your handset, and it can set internal variables and call pages. Our script uses these functions to set the WML variable RESULT to the value of the die roll, and then calls the second card in our deck using the WMLBrowser.go function. This has already been written to display the RESULT string.

You can run these samples in a WML development tool like the Nokia WAP toolkit before you install them on your web server. It’s a good idea to do this, as there’s very little in the way of debugging tools built into a phone! Testing in a phone emulator will at the very least throw up any typing mistakes you’ve made – and as WML is an XML-base language any errors will mean that a deck won’t be parsed by a WAP Gateway, and so will never be compiled and sent to a phone.

WMLScript is a very powerful tool, and this brief overview only scratches the surface of what you can do with WMLScript in your WAP applications. The tools that allow you to interact directly with a WAP micro-browser are especially useful – and they’re not the only way you can control your phone. One of the more interesting features of WMLScript is the Wireless Telephony Application Interface (WTAI). This is a tool that allows your scripts to control the your phone directly. With WTAI you can dial calls, add numbers to the phone book – all with a few lines of WMLScript. There is one problem with WTAI, but unfortunately it’s a big one: not all phones support WTAI in the same way. Some allow scripted access to WTAI functions, whilst others use custom WML tags. So a page designed for a Nokia phone won’t work with a Motorola – making it impossible to create cross-platform pages that use complex features. It’s difficult to know what to do here, and it’s probably best to leave WTAI well alone until Phone.com, Nokia and Ericsson get their acts together…

If you want to learn more about working with WAP and WML, you can download any of the WAP toolkits from Nokia, Motorola, Ericsson or Phone.com, as they all come with copious amounts of documentation. Nokia provide an excellent guide to WMLScript amongst their files. For those of you who find WAP and WML worth exploring in detail there’s currently only one text book available: Steve Mann’s “Programming Applications With The Wireless Application Protocol: The Complete Developer’s Guide”. This is an excellent book, ready for everyone from the beginner wanting to dabble in WAP to the experience developer who wants to use Java Servlets to deliver dynamic WML pages. As WAP becomes more and more popular we’ll see more books appearing – so keep an eye on the bookshelves.

In the next workshop we’ll carry on looking at WAP, and look at how you can add graphics to your WML decks – as well as looking at how you can use timers to add interesting effects to your WAP sites. Mobile multimedia is only a few clicks away!

MExE – Java on the mobile phone

WMLScript isn’t a complete programming language, and is really only intended to enhance your WML applications. Real programs will have to wait a couple of handset generations for MExE: the Mobile Station Application Execution Environment.

MExE is intended for the next generation of mobile networks. These will be based on two new technologies: GPRS, the General Packet Radio System, and W-CDMA, Wideband Code Division Multiple Access. GPRS will turn existing GSM phone networks into high-speed packet networks, capable of speeds between 30Kbps and 300Kbps. W-CDMA is the technology behind the future 3G wireless networks that just raised £22 billion for the UK government, and can run at speeds of up to 2Mbps.

With high-speed wireless networks WAP becomes a tool for simple lookup applications, and the mobile phone turns into a pocket computer. MExE is intended to be the technology that will deliver applications to these devices. Taking advantage of Java, MExE is intended to provide phones from many different vendors with a true write-once, run-anywhere platform. By using Java, MExE will also offer as secure an application environment as possible – thanks to the Java sandbox security model.

MExE is supported by most of the main mobile hardware developers, including Nokia and Motorola, as well as network specialists Nortel. It’ll be sometime before we see powerful-enough handsets for MExE to become widely used, but to get you started you can find out more from: http://www.mobilemexe.com/ and from http://www.etsi.org/smg/smg4/mexe.htm.