A Wap Application Compatible With The “Wireless Application Protocol” (WAP-PORTAL)
CHAPTER ONE
1.0 INTRODUCTION
Just as we have managed to control the last wave of technology, namely the Internet and PC’s, we are about to be engulfed by the next wave, wireless devices. As time has evolved, electronic devices have become smaller and smaller, from the first computers that nearly filled a room, to a desktop computer, which was to be shortly followed by the laptop computer. Now with the help of modern technology we can send and receive electronic data and Internet information from small wireless devices such as mobile phones. Using the “Wireless Application Protocol” it is now possible to design services and applications, that can be run on WAP compliant handheld devices.
With this in mind, we have developed a wap-portal that can be run on wireless devices. Anyone will be able to access necessary information and services by a simple click of a button on their mobile phone. Similar to the practices used on the Internet, users will have to navigate their way through the links to locate the information they require. Nowadays many people like to live life in the fast lane, this means adapting technologies that are easier and more mobile. This application achieves both these goals and is at the forefront of modern technology.
1.1 WHAT IS WAP?
“The WAP (Wireless Application protocol) is a specification for a set of communications protocols to standardise the way that wireless devices, such as cellular telephones and radio transceivers, can be used for Internet access, including the e-mail, the World Wide Web, newsgroups, and Internet relay chat. While Internet access has been possible in the past, different manufactures have used different technologies. In the future, devices and service systems that use WAP will be able to interoperate.”
(Source:http://searchmobilecomputing.techtarget.com/sDefinition/0,,sid40_gci213337,00.html ).
WAP is a technology designed to provide users of mobile terminals with rapid and efficient access to the Internet. WAP is a protocol optimised, not only for the use on the narrow band radio channels used by second generation digital wireless systems but also for the limited display capabilities and functionality of the display systems used by today’s mobile terminals. WAP integrates telephony services with micro browsing and enables easy-to-use interactive Internet access from a wireless device. Common WAP applications, which are already available to users today, include, many forms of on-line banking, various information points and messaging.
Wireless devices such as mobile phones have become very popular in recent years. To coin a phase “mobile phones are no longer just phones”; they are communication devices capable of running applications and communicating with other devices and applications over a wireless network. WAP is developed to be the standard means of information transportation and Internet service gateway for mobile communication services. WAP is unique in that it’s hardware, software platform and network are independent. It uses a lightweight browser, a client server that can be designed to have minimal footprint and hardware requirements to fit in with a wide range of different devices.
1.2 A WIRELESS APPLICATION (wap-portal)
We have recognised that people not only value the power and usefulness of the web but also wanted to have it available while away from home or work. The hegemony or dominant ideology behind this study is simple: someone with a cell phone, pager, or PDA should be able to do limited web surfing, for example to read news’s, to check e-mail, or to searching web sites. But how can a small device with a small display render web pages that contain large amounts of text? And who wants to wait for long periods of time for a huge image to be sent over a slow wireless link? And how can a user follow links without a mouse? The answer to all these questions are answered throughout this project and the actual physical working of these problems and the fundamental technologies of WAP are evident in the application, which have been designed by me.
For the purpose of this study we have implemented an wap-portal. The theory behind this application means that it can be customised to bring any type of information to specific users. Those interested to read the latest news’s, to get emergency information, travel information, to know programs and TV schedule, to download mobile content, and those interested in checking e-mail and wap searching will be able to catch up this. With the potential that WAP offers, it is not beyond the realms of possibilities that mobile devices will be essential for us to conduct our everyday lives. If this scenario does pan out, then all types of people will use applications such as this for various purposes. My application will allow anyone with WAP compatible devices to gain access to news’s, emergency information, travel information, entertainment, mobile infotainment services, e-mail checking, wap searching and other services. By a simple click of a button on a mobile device, anyone will be able to gain information and relevant information regarding events taking place in the Country within the immediate future.
Much thought went into the type of application that was to be designed. However due to the fact that the final product would be displayed on a simulator it became apparent that in order to design such an application it would be necessary to incorporate all of the primary teachings of WAP.
– The actual setting up of a site.
– The workings of the Wireless Mark-up Language.
– The architecture of the WAP environment.
– And how to travel from page to page, or card to card as it’s called within the field of WAP.
After endless research and providing the necessary background on this topic I had to construct a “water tight” methodology. The main tool necessary for creating a WAP application is a Software Development Kit (SDK). There are many of these available to new developers from various sites. However for the purpose of this study we have decided upon Dreamweaver SDK. A more detailed description of the methodology will be discussed in chapter 3.
Chapter 4 will evaluate both the successfulness of the wap-portal as an application and the successfulness of my study within the realms of WAP.
1.3 LITERARY REVIEW
Due to the fact that WAP is in its stage of infancy, there is very little documented information and so a great deal of background knowledge was obtained from relevant web sites and companies who are involved in developing WAP applications. As a result this literary review will include the practices and teachings of the main forerunners within the field of wireless devices, this will include companies such as Nokia 1and openwave.com 2, and more importantly a group known as WAP forum3.
It is safe to say, that the development of WAP is being driven by the WAP forum, and that it is in fact the engine behind this relatively new application. The forum was initially founded by Motorola, Nokia, Ericsson and phone.com (previously unwired planet). Since it’s inception the WAP forum has grown dramatically and now comprises of over 170 full members drawn from the world’s leading telecommunications and software companies. The underlying belief of the forum is that WAP is a technology, designed to provide users of mobile terminals with rapid and efficient access to the Internet. WAP is a protocol optimised, not only for the use on the narrow band radio channels used in second generation digital wireless systems but also for the limited display systems used by today’s mobile terminals. WAP integrates telephony services with micro-browsing and enables easy-to-use interactive Internet access from the mobile handset. The forum believes that WAP will enable operators to develop innovative services to provide differentiation in competitive market environments.
The WAP forum represents “the de facto world-wide standard for providing Internet communications and advanced telephony services on digital mobile phones, pagers, personal digital assistants and other wireless terminals”.
(Source – http://www.wapforum.org )
In order to place the significance of the forum in relation to this project, one must realise that the forum members represent over 90% of the global handset market, carriers with more than 100 million subscribers, leading infrastructure providers, software developers and other organisations providing solutions to the wireless industry. I have appreciated that it would be both detrimental and naïve, to even begin an individual study, without first gaining an insight into the beliefs and teachings of the WAP forum.
1.3 GOALS OF WAP FORUM
– To become independent of wireless network standard.
– To provide access to all.
– To submit specifications for adoption by appropriate industry and standards
Bodies.
– Applications scale across transport options. To create a global wireless protocol specification to work across differing wireless network technologies.
– To enable applications to scale across a variety of transport options and device types.
– Extensible over time too new networks and transports.
1.5 BENEFITS OF WAP
There are various benefits for using WAP, in the same way that there are various groups that will benefit from using WAP, from operators to users and from manufacturers to developers.
For wireless network operators WAP will cut costs and increase revenues by both improving existing services such as interfaces to voice mail and prepaid systems, and facilitating new value-added services such as account management and billing inquires.
End users of WAP will benefit from easy, secure access to relevant Internet information and services such as messaging, banking and entertainment through their mobile device. On a smaller scale Intranet information such as corporate databases can also be accessed via WAP technology.
For manufacturers the global open standard provides endless scope for new product and marketing opportunities. And for developers, the simple fact that there are well over 100 million compatible devices worldwide, makes it clearly obvious the significant revenue that is available to developers.
These goals and benefits represent the dominant ideology behind WAP applications and the formation of the WAP forum. Considering that the forum has over 95% of the wireless industry supporting it, it became obviously apparent that concentrating this literary review on the WAP forum was a necessity, in order to gain an insight into the technology and strategies required to develop, deploy and support wireless application.
CHAPTER TWO
2.0 THE ARCHITECHTURE AND WORKINGS OF WAP.
Before one could possibly consider discussing how to design a WAP application, it is vitally necessary to first provide a detailed analysis of the practicalities and actual architecture of WAP. Due to the fact that this type of architecture is something that many people are not familiar with, and can therefore prove to be extremely complicated, I have decided not only to document this section but also to depict simple diagrams in order to provide a working knowledge of the WAP environment. My deems that only once a working knowledge of this environment is established, would it be suitable to continue and discuss the design and implementation of his own application.
Despite the explosive growth of wireless networks, the wireless Internet, has not yet taken off. There are many reasons for this, both technical and non-technical. However from a technical perspective, the adoption of the wireless Internet has been limited by two primary characteristics; the capabilities of hand held devices and wireless networks. When hand held devices enter the Internet space, the gap between Internet client capabilities widens. This makes it difficult for servers to provide a level of service that is appropriate for every client. Most web servers fail to recognise that computers are no longer all wired and connected to high-speed networks.
WAP specifies two essential elements of wireless communication: an end-to-end application protocol and an application environment based on a browser. The application protocol is a layer communication protocol that is embedded in each WAP –enabled device. The network side includes a server component implementing the other end of the protocol that is capable of communicating with any WAP user agents.
2.1 BACKGROUND
Due to the fact that mobile phones were unheard off 20 years ago, it is understandable that the technology developed for the Internet was designed for desktop and larger computers. These computers had generally medium to high bandwidth and reliable data networks. Whereas wireless devices present a more constrained computing environment. He key limitations of wireless devices include:
– less powerful CPUs,
– Less memory,
– Restricted power consumption,
– Smaller displays,
– Different input devices.
Further more due to the limitations with power on wireless devices, data networks also presents a more constrained communication environment. These limitations include less bandwidth, more latency, and less connection stability.
2.2 NETWORK OPERATORS
As the number of wireless devices and the demand for them increases, operators must be looking to provide more advanced and usable services. The operators must look to achieve this by addressing these following areas:
– Interoperable – terminals for different manufacturers communicate with different services in the mobile network.
– Scaleable – mobile network operators are able to scale services to customer needs.
– Efficient – provides quality of service suited to the behaviour and characteristics of the mobile network.
– Reliable – provides a consistent and predictable platform for deploying services.
– Secure – enables services to be extended over potentially
A more technical and in-depth analysis of the actual workings and architecture of the Wireless Application Protocol are now offered by me, so as one can understand not only how to develop an application, but also to understand exactly how a WAP application works.
2.3 COMPONENTS OF WAP ARCHITECTURE AND IT’S BASIC WORKINGS
Just like an engine has vital parts, and the body has vital organs, WAP has vital components, which are a necessity in order to function properly. The first of these is the WAP gateway. The gateway is a telecommunications software infrastructure that provides an interface between telecommunications protocols within the mobile operator’s network and Internet protocols.
The second major component is the origin server, this is a computer, which stores WAP content. The origin server communicates with the WAP gateway over the HTTP protocol so it can be on a local network or anywhere on the Internet. Current web servers are capable of storing WML, WMLScript and Wireless Bitmaps.
The third component is the wireless telephony application server. This provides an interface between the WAP gateway and other infrastructure elements of the mobile operator’s network. The WTA server can also be used to provide a WAP front end to existing applications such as prepaid billing.
And finally we have the terminal device. This can vary from a pocket pager to a palm top computer. As long as the device comes complete with a WAP micro-browser and connection to a WAP gateway. I have decided to concentrate on one of these such devices, the mobile phone.
2.3.1 HOW A WAP APPLICATION RUNS BETWEEN CLIENT AND SERVER.
As this is a relatively new concept for many, I have decided to explain this somewhat complicated process, with the aid of a diagram in order to provide a more simplistic overview.
(FIGURE 1: WAP MODEL)
Applications are written in the wireless mark-up language (WML), and stored on either a normal web server or directly on the WAP gateway. The content stored on the web server will be accessible from the client device via the cellular network and a WAP gateway or proxy, (the WAP proxy acts as the gateway between the cellular network and the Inter/Intranet). This is when the WAP technology kicks in, any application written in HTML will have to be converted to WML before they are sent to the client device, this is carried out by the HTML filter which can form either part of the web server or the WAP gateway. The data sent by the origin server and the handset is binary encoded to optimise transmission over the narrow bandwidth of the cellular network.
2.3.2 SO HOW DO THESE COMPONENTS WORK TOGETHER?
Surprisingly we all know more about the workings of WAP than we actually think, this is because it works on the same fundamentals as that of the Web. In as much to say that, a user makes a request for information using a URL. This URL is presented in the form of a hyperlink, then the information is retrieved and presented to the user. This means that at either end of the WAP system is a user and content. To apply this theory to my application, a person uses a mobile phone to make a request and to view the content.
However there are two ways of retrieving the content for the user. Firstly the information can be retrieved direct from a WAP server, the user simply requests content from the server, the server retrieves the content, and the content is then returned to the device. The second method is slightly more intricate in that the client device is in communication with a “WAP gateway”. The client device requests the content from the gateway, the gateway retrieves the content, reformats it, and then the content is returned to the device. One must understand that the WAP gateway translates WAP messages into another protocol, such as HTTP. However it is not possible for me this study to demonstrate the latter of these practices as the technical software necessary for such an application is only available to large companies interested in this field of study.
2.4 WAP SYSTEM ARCHITECTURE
Before one can design a wireless application a complete understanding of both the internal and external architecture is extremely necessary, that is why I have decided to allocate an entire chapter to this topic.
Many people understandably assume that WAP is a single protocol, but in actual fact it consists of a stack of protocols that provide different layers that are necessary to design an application.
(FIGURE 2: The WAP protocol stack.)
The light weight WAP protocol stack is designed to minimise that required bandwidth and maximise the number of wireless network types that can deliver WAP content – GSM, SMS, USSD, CSD, GPRS, EDGE and CDMA. Since WAP is based on a scalable, layered architecture, each layer can develop independently of the others. This makes it possible to switch onto new bearers, to use new transport protocols, without major changes in the other layers.
The WAP layered architecture enables other services and applications to utilise the features of the WAP stack through various interfaces. External applications may access the session, transaction, security and transport layers directly. In order to analyse the WAP stack, I have decided to discuss each layer individually.
Wireless Application Environment: a lightweight application environment based on browser technology with mark-up and script capabilities and telephony awareness.
Session Layer: provides communication session services for the application environment.
Transaction Layer: a lightweight reliability layer suited to request/response applications.
Security Layer: authentication and data encryption function.
Transport Layer: basic communications data mover function.
Network Layer: bearer services and the physical network type.
2.4.1 WIRELESS APPLICATION ENVIRONMENT (WAE)
The Wireless Application Environment (WAE) offers the software platform environment for the application software. It’s based on a combination of World Wide Web (WWW) and mobile telephony technologies. The WAE aims to establish an interoperable environment that will allow operators and service providers to build applications and services that can reach a wide variety of different wireless platforms. WAE is built into the so-called micro browser program that works in a very similar way to normal WWW browsers which we all know interprets Hyper Text Mark-up Language (HTML) and JavaScript, for use on desktop devices. WAE consists of Wireless Mark-up Language (WML), WMLScript, and Wireless Telephony Application(WTA).
– WML is a lightweight mark-up language, similar to HTML, but designed for use on hand held mobile devices.
– WMLScript is a lightweight scripting language, similar to JavaScript
– WTA includes telephony services and programming interfaces.
A more detailed description of WML and WMLScript is provided by me, and is located in it’s own subsection at the end of this chapter.
2.4.2 WIRELESS SESSION LAYER (WSP)
The session layer of the WAP architecture consists of the Wireless Session Protocol (WSP) and Wireless Transport Layer Security (WTLS). They provide connection-based services to the application layer, WAE and WTA. Basically a session is started , content is exchanged, and the session is later closed. Also the session can be suspended and resumed. WSP is the WAP equivalent of HTTP. Within HTTP and WSP is the concept of request and reply, each consisting of a header and a body. The header is data about the data and consists of information about the particular request or response, the body consists of WML, WMLScript or images. WSP also defines a server “push” transaction where the server sends unrequested info to a client device. This service can include services such as up to the moment sports results, and can be tailored for each individual.
2.4.3 WIRELESS TRANSACTION LAYER (WTP)
The Wireless Transaction protocol (WTP) works between the WSP and the security layer (WTLS). What the WTP actually does is reduce data packets into lower level datagrams and transforms them in useful data. WTP also keeps track of received and sent packages and does acknowledgement sending when needed.
2.4.4 SECURITY LAYER (WTLS)
Wireless Transport Layer Security Protocol (WTLS) is made up off all the cryptography orientated features of WAP. This includes crypting, decrypting, user authentications and data integrity checking. WTLS is the WAP equivalent of the HTTP SSL or TLS.
2.4.5 TRANSPORT LAYER (WDP)
The Transport Layer Protocol in WAP is commonly known as the Wireless datagram Protocol (WDP). The WDP layer operates above the data capable bearer services supported by the various network types. As a transport service it offers a consistent service to the upper layer protocols of WAP. Furthermore due to the fact that the transport layers interface and basic features are kept consistent, it allows global interoperability to be achieved using mediating gateways.
2.4.6 NETWORK LAYER
The bearer service is the wireless data link between the client and the server. Many different service bearers are possible: CDPD in the cellular system, SMS in the GSM cellular system, and one-way and two-way paging. Each client device must obviously have at least one bearer service and some client devices may have several, for example, the GSM phones.
After reading chapter 2 of this study, it is my desire that the notion of WAP consisting of a single protocol be dispelled. It was hoped that the stack of protocols, be described and explained in a simple yet informative manner. This chapter was extremely necessary to discuss the many different protocols and their functions before one could actually go on to design and implement a new WAP application.
2.5 ADDITIONAL FEATURES OF WAP ARCHITECTURE
When using the conventional web the user interactively requests information, which web server’s supply, and this is called a synchronous model. To support notifications consistently across different network types, the UP. Link platform provides two logical delivery channels for notifications. Firstly there is the asynchronous model that is also known as the “push model”. Servers that use the asynchronous model do not wait until a user requests information. Instead they use a profile to determine which information is important to the user and asynchronously send the information to the user as soon as it becomes available. Secondly there is the “pull channel”, WML services use the pull channel to send notifications that contain less time-sensitive information. The UP.Link platform fully supports this model of interaction, allowing WML services to send information to UP. Link subscribers asynchronously. These messages that are also known as notifications and are already widely used on mobile devices for functions such as sports up-dates, weather reports and alerts.
2.6 HOW WAP CONTENT IS DISPLAYED.
The basic display unit of a WAP application is known as a “card”. A card can be considered as a screen of information or indeed a few screens can make up a single card. In many cases it takes more than one card to make up a WAP application or service, when this is the case a group of these related cards is known as a “deck”. If one was to compare these terms to their counterparts, a card would serve the same purpose as a HTML file, and a deck on a client device can be called like a URL on the Internet. Due to the fact that a client device has a limited display, and may only have a single-line display a single card may need to be stretched over several screens. This is why there are variations in the presentation of content from one device to the next, i.e., a mobile phone addresses this problem by offering a scrolling option. A card called on a mobile phone can display text, images, hyperlinks, and input fields. How to navigate through these fields and how to input data varies for each manufacturer of the client devices.
Now that I have discussed the basic format of a WAP application, what tools or language do we use to design an application.
2.7 WIRELESS MARK-UP LANGUAGE (WML) AND WML Script.
Wireless Mark-up Language (WML), is a DTD (Document Type Definition) of XML (Extendable Mark-up Language) that is a subset of SGML (Standard Generalised Mark-up Language). The WAP forum provides a formal DTD for WML and can be located at their respective web-sites (See bibliography). DTD will be discussed in further detail in the methodology of this thesis, contained in chapter three.
WML is intended for the use in specifying content and user interface for narrowband devices, such as the mobile phone. WML is very similar to HTML. It is a mark-up language with tags and elements, used for formatting textual information, it consists of approximately thirty tags. Due to the nature of it’s objective i.e., for use on wireless devices, it has been designed as a lightweight language.
Furthermore WMLScript is used to complement the Wireless Mark-up Language. WML is extremely diverse considering it is designed for narrow-band devices, it can display content using text, images, lists etc, however all this content is static and there is no way to extend the language without modifying WML itself. WMLScript is necessary in order to make a WAP application dynamic, it was designed to provide programmable functionality that can be used over narrow-band communication links in devices with limited capabilities. WMLS is to WML as Java is to HTML. WMLS is designed to provide general scripting capabilities to the WAP architecture. WMLS is based on the core of the EMCAScript language specification that defines the basic types, variables, expressions and statements of the language. This core can be used almost identically for the WMLS specification, making WMLS as familiar as possible and thus easier to learn.
CHAPTER THREE
3.0 DEVELOPING A WAP APPLICATION
Thus far everything that has been discussed represents the theory behind the actual workings and architecture of a WAP application. Chapter three will now provide the main backbone to this entire project, in that it will offer a detailed methodology into my application. This chapter will progress in a systematic fashion, firstly discussing how to actually get started and what technology is necessary, and then moving on to discuss and explain with the use of diagrams, in a step by step manor exactly how I have designed and implemented my application.
In order to design a WAP application it is necessary for the developer to obtain an Dreamweaver SDK (software development kit). There are many of these available to download on the Internet, which will enable any novice to get up and started. After much deliberation I have decided to use Dreamweaver SDK.
3.1 OPENWAVE PHONE SIMULATOR PLATFORM
The Openwave Phone Simulator 1 is the environment for which all the WAP applications run, it provides a secure, wireless access to many Internet and network services using data-capable wireless devices. We are all more familiar with these workings than we actually think in that many of its concepts are very similar to those, which we’ve experienced using a conventional web browser. Just like a desktop computer, the user must press keys in order to navigate and request URLs, however unlike computer browsers which use HTML to display information on a screen, wireless devices use WML, a language developed to facilitate small handheld devices (see chapter 2.7).
The main body of the Openwave Phone Simulator is the Simulator Console, it allows Generic Devices to access any web-site acting as a HTTP proxy. Not only does the Simulator Console translate HTML, but it also enables Generic Devices to conduct many of the functions that we only associate with desktop computers such as being able to send, receive and save e-mails and also carry out on-line transactions.
3.1.1 HOW THE OPENWAVE PHONE SIMULATOR PLATFORM WORKS
Before begins to document and display my application, I feels it necessary to provide a basic example of how a typical transaction takes place over a wireless network. This is a simple, theoretical transaction, which should breakdown a WML transaction into its simplest form, in order to show the basic workings of the Openwave Phone Simulator platform.
1. Suppose someone want’s to find out a football result for a game, which has just finished. The user uses his/her wireless device to request a URL,
2. The Generic Device creates a request containing the URL and sends it to the
Simulator Console.
3. The Simulator Console creates a conventional HTTP request, and then sends it
on to the web server.
4. Once the web server receives the request it then starts the process of
retrieving the information.
5. Once the HTTP file has been located by the web server, it is then sent back to
Simulator Console.
6. Now that the Simulator Console has received the response, the content is
translated into WML, and is then sent to the Generic device.
7. The client can now view the content on the Generic device.
3.2 USING THE OPENWAVE PHONE SIMULATOR
Just as a web developer can load and test his/her HTML before a web application is made live on the Internet, so to can a WAP developer. This testing can be conducted using a Openwave Phone Simulator, which allows you to load, test and debug your WML code.
The Openwave Phone Simulator has two different modes; firstly we have the mode that includes the Generic Device. The Generic Device interacts with the Simulator Console just like a real wireless device. This mode requires access to a Simulator Console before you can use it. And secondly there is the “HTTP direct”. This mode loads WML directly from a web server, by passing the Simulator Console. For the purpose of this application I have decided to use the “HTTP direct” mode, which requires no special set-up.
When downloading your simulator it’s advisable to save it to a hard drive as it requires a lot of space. Figure 3 is a diagram of what the Simulator Console looks like, and what key functions are available when you download the Openwave Phone Simulator, from the http://developer.openwave.com web-site.
We did have a choice as to what kind of display the simulator would have, by simply clicking on the configuration box located in the file on the toolbar, however after experimenting with them all, it was decided to use the Generic Device as it offered all the major key functions and displayed the content in the clearest fashion, which is displayed in figure 3 next page.
|
|
|
|
|
|
|
|
(Figure 3: screen dump of simulator functions)
3.3 FUCTIONS ON THE SIMULATOR.
A. At the top of the Generic Device we are provided with a go field. It is here where one would enter URL’s, and be able to make your request to access information.
B. The top left button located immediately below the display screen, is known as the Select function key. Once you have navigated through the various cards to your desired destination one must press the Select button in order to access the content.
C. The top right button located immediately below the display screen, is known as the Options function key. By pressing this key, one is provided with a selection of applications, which are available to the user.
D. The four arrow keys and the four single keys directly below, all make-up the navigation functions. By using the arrows, one can place the cursor anywhere on the display screen and navigate through the various cards.
E. Like conventional web browsers, Openwave Phone Simulator also have a home mechanism. This comes in the form of a HOME function key. This enables the user to return to the home page at any point during his/her journey.
F. Furthermore, similar to the web browser again, all Openwave Phone Simulator have a back mechanism and this comes in the form of a BACK function key. The Generic Device keeps a history of the cards that you have accessed, enabling you to travel back through the stack. However no such FORWARD function is available on the Openwave Phone Simulator.
G. Finally we have the number keys, which also double as the text entry keys. When an application has been accessed and user input is required the number keys are used to input data. To enter text on the Openwave Phone Simulator, you can either use your computer keyboard or use the mouse to click on the keypad area of the screen.
3.4 THE DESIGN OF THE wap-portal APPLICATION
Now that I have fully developed the practicalities and technology behind a WAP application, the foundations have been laid for me to discuss and display my application. The aim of this study is to provide any beginner with an in-depth knowledge into the principals and workings of a WAP application. Therefore in order for this study to be a success, it became apparent that my application would have to incorporate as many of the aforementioned principals and functions as possible.
The theory behind this application is that the content can be changed to make the application relevant to any subject. The content could vary from local news to world, sport, however to keep this application relevant to the readers and me, it was decided to design an application for all. In theory this application allows people to get various information and services that could interest and assist them for the fore coming period.
3.5 DEVELOPING A WAP APPLICATION
So how do we get started?
Once you have obtained a knowledge and feel confident using WML, it is time to start designing your application. To begin one must open a new notepad document, this is where the WML coding is saved in the same way that HTML is saved. And just in the same way that in order to design a web page on the Internet it must be saved as a HTML file, in order to design a WAP application it must be saved as a WML file e.g. http://www.workstationbd.com/wap-portal/index.wml.
In order to provide a well-structured methodology, I have decided to breakdown the application into smaller programs. By doing so I will be able to show the individual functions of my application as well as being able to describe the format of the Wireless Mark-up Language. Ultimately the coding will be pieced together to display my new WAP application.
3.6 HOW TO START STRUCTURING A WML FILE.
Before one can get started, one must realise that WAP Forum 1 to mention the largest governs a standard for WAP.
– All WML files have to begin in a similar fashion, this is an example of how an application may begin: –
<?xml version=”1.0″?>
<!DOCTYPE wml PUBLIC “-//WAPFORUM//DTD WML 1.1//EN” “http://www.wapforum.org/DTD/wml_1.1.xml”>
These lines are necessary so that the version of wml can be established and confirmed by the browsers. WML is an XML language and requires a DTD (Documentation Type Declaration). If you don’t use a DTD the browser will not recognise it as all the WAP browsers look for the DTD declaration.
– As mentioned in the previous chapter, wml is very similar to HTML and is a tag-based language. Tags in wml are defined by an open tag <……> and a close tag </…..>.
– A WML file then starts with the tag <wml> and ends with </wml>.
– Content within the wml file is encapsulated by the cards defined by the tags<card> and </card>. Text should also be encapsulated with in <p> and </p> tags.
– WML also offers various tags that allow you to specify the font, size and layout of text.
– Furthermore the designer has the capabilities to maintain whatever format he/she requires using tags such as, line break and alignment.
– And finally, there can be many cards within a wml file. This is called a “deck” of cards. Consideration must be given to the quantity of information supplied in the wml file. More content means longer download times and if the user is unlikely to use all the cards within a deck it is wasting bandwidth and time.
3.7 CREATING A STATIC TITLE WML FILE
Now that all the key principals have been discussed, it is time to start displaying my application. This is a static wml file that is used by me as a title page, and can be viewed in figure 4 below.
<?xml version=”1.0″?>
<!DOCTYPE wml PUBLIC “-//WAPFORUM//DTD WML 1.1//EN” “http://www.wapforum.org/DTD/wml_1.1.xml”>
<wml>
<card>
<p>
A WAP APPLICATION,
COMPATIBLE WITH THE “WIRELESS
APPLICATION PROTOCOL”
<br/>AUTHOR: TIPU LAL NATH
</p>
</card>
</wml>
(Figure 4: screen dump of a static title page)
3.8 CARD BY CARD ANALYSIS OF THE wap-portal APPLICATION
The ideology behind my application is that any people with a wireless device can get information about any category of this portal and read latest information. The concept behind the application could be customised to bring the user any type of information from world news to local sports and various services.
Once the user accesses my application a index page is displayed, see figure 5 below, this simply tells the user the topic of content located at this site.
(Figure 5: screen dump of wap-portal)
However, in order to make this application easier for the user a timer has been put into place. The timer means that the index page is only displayed for an adequate period of time, so as the user knows what information he/she is about to read. After a couple of seconds the title page will automatically be replaced by help card, which displays a series of topics and links which are available for the user to access.
<?xml version=”1.0″?>
<!DOCTYPE wml PUBLIC “-//WAPFORUM//DTD WML 1.1//EN” “http://www.wapforum.org/DTD/wml_1.1.xml”>
<wml>
<template>
<do type=”prev1″ label=”Help”>
<go href=”help.wml”/>
</do>
</template>
<card id=”index” title=”wap-portal”
ontimer=”help.wml” newcontext=”true”>
<timer value=”1000″/>
<p>
<a href=”news/news.wml”>News</a><br/>
<a href=”emergencies/emergencies.wml”>Emergencies</a><br/>
<a href=”travel/travel.wml”>Travel</a><br/>
<!–<a href=”city_guide/yellowpages/cityguide.wml”>City Guide</a><br/>–>
<a href=”entertainment/entertainment.wml”>Entertainment</a><br/>
<!–<a href=”m_infotainment/”>Mobile Infotainment</a><br/>–>
<a href=”email/email.wml”>Email</a><br/>
<a href=”wap_search/wapsearch.wml”>WAP Search</a><br/>
<a href=”other_services/otherservices.wml”>Other Services</a>
</p>
</card>
</wml>
(Figure 6: screen dump of links)
Now that the user has reached this stage in the application, he/she must know decide their desired destination and begin to use the function keys and navigate for them-selves, visual evidence of the links in provided in figure 6 above. Due to the fact that there is a limited display on the Openwave Phone Simulator, not all the links are visible on the screen. The user must now scroll down using the arrow key to read all the options that are available.
A wml file is referred to as deck, made up of one or more cards of information; navigation between these cards is by hypertext links. The anchor tag specifies the url when a link is selected, and the href part of the anchor tag specifies the url to follow. The following example of coding not only shows how navigation between cards works, but also how, it is programmed so that the user must accept a link in order to view it. So if the user wants to view the content stored on card 4, he/she must scroll down the links until the arrow is aligned with that link on the simulator, this link must them be accepted by the user on the simulator.
<?xml version=”1.0″?>
<!DOCTYPE wml PUBLIC “-//WAPFORUM//DTD WML 1.1//EN” “http://www.wapforum.org/DTD/wml_1.1.xml”>
<wml>
<template>
<do type=”prev” label=”Back”>
<prev/>
</do>
<do type=”prev1″ label=”Help”>
<go href=”#help”/>
</do>
<do type=”prev2″ label=”Home page”>
<go href=”http://localhost:88/wap-portal/index.wml”/>
</do>
</template>
<card id=”emergencies_card” title=”wap-portal:Emergencies” ontimer=”#emergencies_card”>
<timer value=”500″/>
<!–<p align=”center”>
This section is brought<br/>
to you by<br/>
wap-portal
</p>–>
<p align=”center”>
<img src=”emergencies.wbmp” alt=”Emergencies”/><br/>
</p>
<p>
<a href=”hospitals1.wml”>Hospitals</a><br/>
<a href=”chemists.wml”>24-hours Chemists</a><br/>
<a href=”clinics.wml”>Clinics</a><br/>
<a href=”atmlocation.wml”>ATM Location</a><br/>
<a href=”petrolpump.wml”>24-hours Petrol Pumps</a><br/>
<a href=”police.wml”>Police Stations</a><br/>
<a href=”ambulance.wml”>Ambulance</a><br/>
<a href=”fireservice1.wml”>Fire Service</a><br/>
<a href=”taxicab.wml”>Taxi Service</a><br/>
</p>
</card>
<card id=”help” title=”wap-portal:News”>
<p>
You have reached wap-portal. Press the select button or the rollar bar to use any of the features. If you want more help, please contact customer service at 000.
</p>
</card>
</wml>
(Figure 7: screen dump of a emergency services card content.)
The final function that is offered by me to enable easy navigation, is the back function. This allows the user to return back to card 1 where the links are displayed. This means that the user can pick and choose which information he/she accesses and in which order.
3.9 Dynamic Content Update Process for wap-portal
Now we want to discuss the very interesting part of my application. I used HTML and PHP for updating contents of my application dynamically. Below I have shown some screen shot of dynamic pages and some codes of dynamic pages.
3.9.1 Dynamically News Update
In theapplication manual_news folder contains four HTML files (man_gen_news.html, man_sp_news.html, man_biz_news.html and man_tech_news.html). When we give related contents to these files and execute then each HTML file call related PHP files (man_gen_news.php, man_sp_news.php, man_biz_news.php and man_tech_news.php) which creates more related WML files.
Screen dump of man_gen_news.html:
(Figure 8: screen dump of man_gen_news.html)
Codes of man_gen_news.php:
<?php
function WAPSpecialChars( $code, $codes, $replacement )
{
$decode = $code;
for( $i = 0; $i < sizeof( $codes ); $i++ )
{
$decode = ereg_replace( $codes[ $i ], $replacement[ $i ], $decode );
}
return $decode;
}
function generateWMLIndex( $links, $filename )
{
$fw = fopen( $filename . “.wml”, “w” );
fputs( $fw, “<?xml version=\”1.0\”?>\n” );
fputs( $fw, “<!DOCTYPE wml PUBLIC \”-//WAPFORUM//DTD WML 1.1//EN\” \”http://www.wapforum.org/DTD/wml_1.1.xml\”>\n” );
fputs( $fw, “<wml>\n” );
fputs( $fw, “<template>\n” );
fputs( $fw, “<do type=\”prev\” label=\”Back\”>\n” );
fputs( $fw, “<prev />\n” );
fputs( $fw, “</do>\n” );
//fputs( $fw, “<do type=\”prev1\” label=\”General News\”>\n” );
//fputs( $fw, “<go href=\”man_general_news.wml\”/>\n” );
//fputs( $fw, “</do>\n” );
fputs( $fw, “</template>\n” );
fputs( $fw, “<card id=\”a1\” title=\”wap-portal:General News\”>\n” );
fputs( $fw, “<p>\n”);
for( $i = 0; $i < sizeof( $links ); $i++ )
{
//$links[$i] = ereg_replace(“$”, “$$”,$links[$i]);
$links[$i] = htmlspecialchars($links[$i]);
$links[$i] = stripslashes($links[$i]);
fputs( $fw, “<a href=\”” . $filename . “_” . ( $i + 1 ) . “_0.wml\”>” . trim( $links[ $i ] ) . “</a><br/>\n” );
}
fputs( $fw, “</p>\n</card>\n</wml>” );
fclose( $fw );
}
function generateWMLFiles( $text, $filename, $index )
{
$start = 0;
$i = 0;
$text = htmlspecialchars( $text );
$text = stripslashes($text);
$text = ereg_replace( “\n\n”, “\n”, $text );
//$text = ereg_replace( “\n”, “<br/>”, $text );
while( $start < strlen( $text ) )
{
$fw = fopen( $filename . “_” . $index . “_” . $i . “.wml”, “w” );
fputs( $fw, “<?xml version=\”1.0\”?>\n” );
fputs( $fw, “<!DOCTYPE wml PUBLIC \”-//WAPFORUM//DTD WML 1.1//EN\” \”http://www.wapforum.org/DTD/wml_1.1.xml\”>\n” );
fputs( $fw, “<wml>\n” );
fputs( $fw, “<template>\n” );
fputs( $fw, “<do type=\”prev\” label=\”Back\”>\n” );
fputs( $fw, “<prev />\n” );
fputs( $fw, “</do>\n” );
fputs( $fw, “<do type=\”prev1\” label=\”General News\”>\n” );
fputs( $fw, “<go href=\”man_gen_news.wml\”/>\n” );
fputs( $fw, “</do>\n” );
fputs( $fw, “<do type=\”prev2\” label=\”GSB News Index\”>\n” );
fputs( $fw, “<go href=\”gsbnews.wml\”/>\n” );
fputs( $fw, “</do>\n” );
fputs( $fw, “</template>\n” );
fputs( $fw, “<card id=\”a1\” title=\”wap-portal:General News\”>\n” );
fputs( $fw, “<p>\n”);
if( ( strlen( $text ) – $start ) < 800 )
{
fputs( $fw, substr( $text, $start ) );
fputs( $fw, “</p>\n</card>\n</wml>\n” );
fclose( $fw );
return;
}
else
{
$chunk = substr( $text, $start, 800 );
$stop = $start + 800;
//echo $chunk . “<br>\n”;
while( true )
{
if( ord( substr( $chunk, $stop, 1 ) ) == 32 ) break;
else $stop–;
}
fputs( $fw, substr( $chunk, 0, $stop ) . “<br/>\n” );
fputs( $fw, “<a href=\”” . $filename . “_” . $index . “_” . ( $i + 1 ) . “.wml\”>Continue</a>” );
$start += $stop;
}
fputs( $fw, “</p>\n</card>\n</wml>\n” );
fclose( $fw );
$i++;
}
}
$i = 0;
if( strlen( $_POST[“news1”] ) )
{
$links[ $i ] = $_POST[“news1”];
$texts[ $i++ ] = $_POST[“text1”];
}
if( strlen( $_POST[“news2”] ) )
{
$links[ $i ] = $_POST[“news2”];
$texts[ $i++ ] = $_POST[“text2”];
}
if( strlen( $_POST[“news3”] ) )
{
$links[ $i ] = $_POST[“news3”];
$texts[ $i++ ] = $_POST[“text3”];
}
if( strlen( $_POST[“news4”] ) )
{
$links[ $i ] = $_POST[“news4”];
$texts[ $i++ ] = $_POST[“text4”];
}
if( strlen( $_POST[“news5”] ) )
{
$links[ $i ] = $_POST[“news5”];
$texts[ $i++ ] = $_POST[“text5”];
}
if( strlen( $_POST[“news6”] ) )
{
$links[ $i ] = $_POST[“news6”];
$texts[ $i++ ] = $_POST[“text6”];
}
generateWMLIndex( $links, $_POST[“filename”] );
for( $j = 0; $j < $i; $j++ )
generateWMLFiles( $texts[ $j ], $_POST[“filename”], $j + 1 );
?>
Screen dump of man_sp_news.html:
(Figure 9: screen dump of man_sp_news.html)
Codes of man_sp_news.php:
<?php
//include “pageindex.php”;
function WAPSpecialChars( $code, $codes, $replacement )
{