SolutionsTools & SDKSupport  



Quick Links
 
Introducing WALL: the Wireless Abstraction Library
 
 
 This article was written by Luca Passani, Openwave's Developer Support Engineer located in Italy.

The Wireless Abstraction Library (called WALL) is a Java tag-library that gives you a universal mark-up for wireless devices. While WALL is high-level enough that you don't need to know about WURFL and XML to deploy and use it, I recommend that you read my article on WURFL to get the big picture.

To use WALL successfully, there's one technology you need to be familiar with: JSP tag-libraries. Please refer to the links in the reference section below for more info about tag-libraries.

For the purpose of this article, JSP tag-libraries are a technology that let you encapsulate complex server-side behavior into tags. This greatly increases the readability of JSP pages and ultimately lets you create more compelling and usable applications at a fraction of the time and money.

Before I get down to the code, allow me to take you on a short trip down "memory lane" to tell those of you who were not doing WAP in 2000, what it was like in those days and why there was a need for tools like WURFL and WALL.

Acronym Soup: WML, another WML, more WML, XHTML and CHTML
 
WAP started with the promise of a universal mark-up language for all wireless devices. Things started to go bad from the day the second WAP devices showed up on the market.

The WML browser shipping with the Siemens C35 (UP.Browser/4) was very different from the browser in the first device (Nokia browser in the 7110 model). At that point, Openwave started to recommend developers build two versions of each application.

At the same, we were creating OUI (the Openwave Usability Interface) hoping to offer an elegant solution to content providers. Developers were skeptical about building multiple applications and they were right. The Openwave V5 browser created yet another WML variant. To add to that, in September 2001, the WAP Forum decided to kill WML to move to XHTML, regardless of the fact that there were half-a-billion WML browsers around.

At that point, with three mark-up languages to support and a fourth one on the horizon, developers thought that the situation couldn't get any worse. We were wrong. iMode's CHTML was becoming popular in Japan - giving us five mark-ups for developers to address.

Why was everything going so wrong when it came to wireless? The truth eventually dawned on me: there were too many players in the wireless arena.

Carriers, device manufacturers, content providers, Nokia, Openwave, Microsoft...everyone was trying to differentiate and gain the advantage. In this situation, getting any kind of convergence was going to be hard. It would be safe to say that the poor wireless developers were literally being left to their own devices, the burden of dealing with this mess being on their shoulders alone.

That's when I figured out that a helping hand for developers would never come from the industry as a whole. The best chance for developers was cooperation: creating a framework that was totally in their domain with no critical dependencies on what the industry was doing. Since my job at Openwave is to be a friend to developers and facilitate their work, I took the initiative to organize a cooperative effort. That initiative eventually delivered WURFL and WALL.
 
One Truly Universal Markup
 
While WURFL is a great framework for a lot of applications, WALL is the place where all of that power shines through even to non-experts. Because of the situation depicted above, the idea of a universal mark-up language for wireless could seem like a vision. Well, that's exactly what WALL delivers with a little help from a Java application server of your choice.

The idea behind WALL is to identify the common structure between different mark-ups and create tags that turn into each of those structures dynamically. This effectively creates an abstraction layer which turns up to be handy to deliver compelling content on high-end devices, while degrading gracefully on legacy devices.

WALL relies on WURFL to figure out which mark-up should be used for each device. 'preferred_markup' is the capability name that tells WALL what kind of creature is asking for its services. Once again, this is happening behind the scenes, so you don't need to understand XML, Java or even WURFL to create and deploy a WALL application that will render on all devices.
 
One JSP Page is Worth 1000 Words
 
I could spend a long time abstractly describing what the library does, but I'll do better than that and show you a WALL ?Hello World? application. To run the example, you'll need Java J2SE (1.4 or 1.5), the Tomcat Application Server (Version 4.1.X, 5.0.X or 5.5.X) and the WURFL and WALL package. Links to all of these are available in the reference section at the end of this article. I created a file called helloworld.jsp in the 'TOMCAT/webapps/wurfl/' directory, on a perfectly standard installation of WALL on tomcat:
 
------------------------------------------------------------------------------
1  <%@ taglib uri="/WEB-INF/tld/wall.tld" prefix="wall" %>
2  <wall:document>
3  <wall:xmlpidtd />
4  <wall:load_capabilities />
5  <wall:head>
6    <wall:title>Hello World</wall:title>
7  </wall:head>
8
9  <wall:body>
10  <wall:block>
11    <wall:img src="logo.wbmp" alt="Openwave">
12      <wall:alternate_img src="logo.gif" test="${capabilities.gif}" />
13    </wall:img>
14    <wall:br/>
15  <wall:h1>Hello World</wall:h1>
16  Just wanted to say hello
17  </wall:block>
18 </wall:body>
19 </wall:document>
------------------------------------------------------------------------------
Listing 1: helloworld.jsp

Before we examine what this JSP page sends back when it receives an HTTP request, let's take a look at the role played by each tag:
  • Line 1 is a JSP directive to include the WALL tag-lib. Just put it at the beginning of each file.
  • The 'document' tag (line 2) can contain some directives, which influence the rendering (not in this example). The tag also contains the logic to perform some magic behind the scenes. Make sure that it's always there.
  • 'xmlpidtd' (line 3) is mnemonic for XML Processing Instruction and DTD. WML and XHTML expect to find an XML Processing Instruction and a DTD at the top of the document. Put the tag there and WALL will fix this for you. Of course, for CHTML this will simply turn into an empty string (no DTD nor XML PI is expected).
  • Line 4 (load_capabilities) is a directive to retrieve all of the WURFL capability values for the device, which is requesting the page (this is necessary for accessing the WURFL 'gif' capability later on in line 12).
  • Lines 5 through 8 are plain HTML. Same goes for line 9.
  • The 'block' tag (line 10) is made necessary by the need to guarantee that the mark-up remains valid (in the XML sense) for WML devices and also for some very strict XHTML-MP devices.
  • The 'img' tag (lines 11-13) may seem familiar. It is our good old image tag. It just happens to be on steroids. You can give extra "sources" to it and make it multiserve pictures depending on capability values defined in WURFL for the device requesting the page. In this particular case, the code reads, "serve a WBMP bitmap, unless the device supports GIF. In that case, here is the gif picture".
  • Even something as banal as a 'br' can give troubles if you want to make it work universally. Use the WALL version (line 14) and your problems are gone.
  • Line 15 is nothing special, apart from the fact that WML devices do not support the HTML 'h1',..,'h6' tags, so WALL will need to kick in and figure something out for you. You'll see what shortly.
At this point, I hit my page with different devices and SDKs. Using the power of WURFL, WALL can recognize which mark-up should be sent to each device (once more, using the 'preferred_markup' capability). Siemens S35, for example, will receive the following WML code: 

------------------------------------------------------------------------------
<?xml version="1.0"?>
<!DOCTYPE wml PUBLIC
    "-//WAPFORUM//DTD WML 1.1//EN"
    "http://www.wapforum.org/DTD/wml_1.1.xml">

<wml>
<head>
   <meta name="taglib" content="WALL" />
</head>
<card id="w" title="Hello World">
 <p>
   <img src="logo.wbmp" alt="Openwave" /> 
   <br/>
<br/><b>Hello World</b><br/>
Just wanted to say hello
 </p>
</card>
</wml>
------------------------------------------------------------------------------
Listing 2: helloworld.jsp renders WML

The S35 is an old WML device with a small screen. The page is rendered as of Picture 1 and 2.



WAP 2 devices support XHTML Mobile Profile and, typically, larger screens. For example, the Sharp GX10, will get this mark-up: 

------------------------------------------------------------------------------
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC 
    "-//WAPFORUM//DTD XHTML Mobile 1.0//EN"
    "http://www.wapforum.org/DTD/xhtml-mobile10.dtd">

<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
   <title>Hello World</title>
</head>

<body>
 <p>
   <img src="logo.gif" alt="Openwave" />
   <br/>
<h1>Hello World</h1>
Just wanted to say hello
 </p>
</body>
</html>
------------------------------------------------------------------------------
Listing 3: helloworld.jsp renders XHTML-MP

See Picture 3 to see how the device renders this.
Observe how this device gets the Openwave logo as a GIF image. That's the power of WURFL. The alternate_img tag lets you grab the value of a capability for the current device with the easiest syntax possible:

<wall:alternate_img src="logo.gif" test="${capabilities.gif}" />

As far as CHTML goes, I could have used an iMode SDK. What has always fascinated me about iMode, though, is the possibility it offers for people to use Microsoft Internet Explorer (or any browser for that matter) to create content for the wireless web. For this reason, I made sure that web browsers are served CHTML. This way, you'll be able to preview your applications in a web browser. Here is what the CHTML code generated by WALL looks like: 

------------------------------------------------------------------------------
<html>
<head>
   <title>Hello World</title>
</head>
<body>
   <img src="logo.gif" alt="Openwave">
   <br>
<h1>Hello World</h1>
Just wanted to say hallo 
</body>
</html>
------------------------------------------------------------------------------
Listing 4: helloworld.jsp renders CHTML

And Figure 4 shows how a web browser renders this code.



So What Does This All Mean?
 
This is just the first part of this tutorial exploring the creation of WALL and a simple example that illustrates the basic WALL concepts. What you should take away from this article is that WALL gives you a universal mark-up whose primary goal is to render on any wireless device no matter what. Good usability of the wireless applications produced comes as an immediate second. Third, still pretty high in the list of requirements, is the simplicity of the WALL abstraction and deployment on Java Application Servers. Future parts of this tutorial will focus on forms and navigation menus.

References Install WALL:
 
 
Copyright © 2000-2008 Openwave Systems Inc.    Openwave  |  Terms & Conditions  |  Privacy Policy