Lab 3. Mobile web applications

3.1 Introduction

Mobile web applications are applications running on a mobile browser. They are actually web pages and websites that look and feel like native applications, built for a particular operating system (Android, IOS or WM) or using a specific technology (JME – Java for Embedded Devices).

The WAP (Wireless Application Protocol) standard was the first conceived and used standard for allowing deployment of browser based new applications onto mobile devices and to allow interconnection of WAP enabled mobile devices to the Internet.

At the beginning, mobile phones and the Internet were two technologies that had nothing in common; together with the apparition of WAP, the huge quantity of Internet like information was made available to mobile users endowed with properly equipped devices.

WAP introduction brought benefits both for mobile users and for service providers. A mobile user was able to get on a single device telephony services and data services similar to those it is accessing from a PC connected to the Internet: news, sport results, stock prices etc. For service providers, WAP allowed for service provision irrespective of the user location or, on the contrary, the development of new, location-based services.

The history of WAP is closely related to that of the WAP forum(1997), a working group composed of mobile terminals (feature phones) manufacturers, network operators and application developers. Inside the WAP forum a major role was played by the OpenWave software company that was producing browsers for feature phones.

WAP specifications issued by OMA are structured on releases (WAP 1.1- proposed in 1999, WAP 1.2-2000 and WAP 2.0 -2001); currently 2/2.5G mobile devices are WAP 1.1 and WAP 1.2 compliant, while for 3G mobile networks WAP 2.0 was the de facto standard. Since 2002 the WAP forum no longer exists, it was integrated in the Open Mobile Alliance, an international standardization body that delivers specifications both for WAP and other wireless technologies devoted in providing mobile data services.

Among concurrent technologies, I-Mode was used for mobile internet access in Japan and Asia. Nowadays, with the advent of smartphone technology, the mobile web technologies evolved from xHTML-MP and WAP-CSS (WAP 2.0) to HTML5 which is supported by Google, Apple, Microsoft etc. The WAP communication model is still used by feature phones, in MMS messaging and for WAP push based notifications.

3.2 The WAP communication model

The WAP model is different to that of the World- Wide Web (Fig.1).

WAP applications and WAP content were written using a similar format to that used on the WWW to exchange various types of documents. The WAE (Wireless Application Environment) specifies all elements for application development and execution and is based on user agents i.e. micro-browser based interpreters for WAP based content such as WML (Wireless Markup Language), WML scripts. WML and WML scripts are used to describe WAP content (images, dynamic or static pages) in a similar manner in which HTML is used to encode Internet like information.

WAP applications and WAP content were written using a similar format to that used on the WWW to exchange various types of documents. The WAE (Wireless Application Environment) specifies all elements for application development and execution and is based on user agents i.e. micro-browser based interpreters for WAP based content such as WML (Wireless Markup Language), WML scripts. WML and WML scripts are

used to describe WAP content (images, dynamic or static pages) in a similar manner in which HTML is used to encode Internet like information.

Fig.1 WAP communication model

Similarly to Internet a piece of information is identified by an URL (Uniform Resource Locator) under the form protocol://hostname/filename. When a user wants to access information through WAP things are happening as follows:

- the user selects the URL of the desired information; - the mobile phone forwards the URL request to a WAP gateway using a binary, tokenized format for achieving a high compression ratio; - the WAP gateway translates the request onto a classical request, for example using HTTP (Hyper Text Transmission Protocol), and places it into Internet; - the appropriate web server picks the request and processes it in an identical mode that

it processes other HTTP requests (static information is stored in WML format using tags; dynamic data can be provided using client (WML script) or server side scripts (ex: VBScript). The web server compiles the WAP content, adds a HTTP header to the WML information, add also information about how content should be handled using the mechanism MIME (Multipurpose Internet Mail Extensions) ( text/html, image/png etc.) and than returns it to the WAP gateway

- the WAP gateway removes the HTTP header and encodes data into a binary format to be transmitted to the mobile phone

- the micro-browser residing on the phone processes the received WML information and displays it.

The WAP standard was defined using an OSI model like layered approach that allows flexible development using connection or connectionless, secure or non- secure, compressed or non- compressed data transfer.

From an application point of view the most important layer is WAE. WAE defines:

- a markup language for describing content on wireless WAP browsers -WML/XHTML-MP (Extensible Hypertext Markup Language – Mobile Profile) - a client side scripting language -WML script; - telephony APIs that are allowing integration of voice calls with data accesses; - MMS support;

3.2 Wireless Markup Language (WML)

In a similar manner to the classical HMTL, WML is used in WAP to specify the layout of pages, to control navigation within a WAP site, to allow access to pages outside the WAP site, to provide data input facilities and to manage parameters.

WML was derived from XML (Extensible Markup Language) and uses some specific concepts to organize data that is to be displayed by the mobile browser:

- cards –a page that is to be displayed is split in sub-pages; such a sub-page is called a card and only a card is viewable at a given instant;

- deck – is a collection of cards, navigation between cards within a deck is local (no client server interaction necessary).

WML supports a large variety of devices (features phones, PDA’s); however the content displayed on a device depends strongly on its nature. Most WML SDK’s were including a reference device/simulator for inspecting the behavior of a page on feature phones: programmable soft keys, arrow keys for forward and backward navigation etc. There are also applications allowing user to render wap pages on such limited capability devices (for example Opera Mobile Emulator – fig.2).

Fig.2 WAP simulators

WML, like HTML, is a markup language i.e. it structures information for display purposes using tags1 and

processing directives in order to describe the structure of a document. Markup begins always with the <wml>

tag and ends with tag </wml>. A WML deck must include a document prologue that indicates the type of the

markup language and its associated set of rules:

3.3 WML Script

WML script was introduced in order to enrich WML functionality forallowing implementation of procedural logic inside WML applications (functions, loops, conditions etc), easing access from the WAP page to peripheral devices for providing telephony and SMS transmission and reception functions, allowing check and validation for WML variables, implementation of dynamic pages etc.

WMLScript is a client-side scripting language; its content is compiled on the WAP gateway into a binary

format. The mobile device and the WAP gateway are exchanging WML script data under this binary format. The advantage of such an approach is that a compiler is not needed onto the mobile device, allowing thus a better use of the mobile phone’s memory and CPU.

3.4 XHTML-MP

XHTML-MP is a markup language promoted by the WAP 2.0 series of specifications 2.0. It Adds new features to WML and unifies the way of for mobile web app development. Starting from XHTML-MP, these are developed using in the same manner with classic web applications, using for example CSS support for formatting content. Currently, the vast majority of WAP pages are developed using this technology. 3.4 WAP push technology

In contrast to the “pull” technology used in classical WAP communications (Fig.1) WAP push technology is a network feature that allows displaying of data on the mobile’s phone browser without a prior need for a request (a simplified architecture for WAP push is shown below).

Fig.3 WAP Push communication model

The Push Initiator is a functional entity that decides when such a message must be sent, it

establishes its content and forwards it to a Push Proxy Gateway (PPG). The PPG formats the message in a format suitable for transmission over the wireless leg and sends the WAP push message using either GPRS, either SMS as a bearer. The formatted message itself carries a reference (a port number) to the application that will process the message i.e. the mobile browser. Once getting onto the mobile device, depending on its type, the message will trigger some actions. Several types of messages are defined for WAP push. The most important are:

- Service Indication (SI) : these type of messages are carrying the following information: a text

message that is to be displayed by the mobile phone, and a link used for “pull” like requests. If the user accepts the message (by clicking on “OK”- mobile phone dependent) the WAP browser will automatically be launched and the mobile phone will retrieve data by

“pull” means.

- Service Loading (SL) : does not contain any text information for the mobile user; moreover the user intervention is not required. On reception of this type of message the phone’s browser will automatically perform the type of action included in the message (load a page, download and install an application or a ringtone, execute a service etc).

3.5.1 Encoding a WAP push SI message into a binary SMS format

The process of encoding a SI message will be illustrated on an example. Considering the following

message:

<?xml version="1.0"?> <!DOCTYPE si PUBLIC "-//WAPFORUM//DTD SI 1.0//EN" "http://www.wapforum.org/DTD/si.dtd">

<si>

<indication href=http://wap.google.com

si-id=5> action="signal-high"

mcs 2006 </indication>

</si>

DTD – only the XML version must be

encoded start of SI message

the indication tag is used for delimiting the content of the SI message and of its attributes the link embedded on the message; identifier of the message, message to be displayed immediately text message end of SI message

For the previous SI message the output of the WBXML parser is:

WSP (Wireless Session Protocol) is a dedicated WAP protocol and for WAP push messages it adds functionality related to:

- adding information for allowing the recipient to distinguish between several push messages - adding information for allowing the recipient distinguish between regular messages and

WAP push messages - identifying the MIME content type and the length for the content type.

For the previous example, the following WSP information will be added:

7A0601AE 7A- Push ID (any value, auto incrementation) 06 – the message is of push PDU type 01 – content type encoded on 1 octet AE – token for the application/vnd.wap.sic – MIME type indicating to the recipient how to deal with the message

WDP (Wireless Datagram Protocol) is a dedicated WAP protocol and for WAP push messages it adds functionality related to application port level addressing i.e. an application running on the mobile device can listen only to some predefined ports.

For the previous example, the following WDP information will be added:

0605040B8423F0

06- WDP header length in octets

05- length of port information (1 octet for length+ 2 octets for each port destination and source)

0B84 – predefined value for destination port (WAP browser)

23F0 –value for the source port (any value since communication is unidirectional).

Finally the message is embedded onto a SMS-MO PDU format on the UD field using an 8 bit encoding.

The SMS header includes all the fields studied at the previous laboratory work. If the message would be

sent to the 40744991816 MSISDN its structure would be:

0061000C910447941918F600F5

00 – SC address from the SIM card 61 – SMS-SUBMIT type with confirmation 00 – message index (any value) 0C – length of the destination number (in digits) 91 – international format for the destination number 0447941918F6 – swapped format for the destination number 00 – protocol identifies F5 – DCS – 8 bit

The User data length field encodes in hexadecimal the length in octets of the User data field. For the above example the structure of the PUSH PDU would be:

0061000C910447941918F600F5300605040B8423F07A0601AE01056A0045C60C037761702E676F6F

676C652E636F6D000801036D63732032303036000101 When using AT commands, the sequence AT + CMGS = 61 <PUSH PDU><ctrl-z> will send

the corresponding message.

3.6 Mobile web applications using HTML5 3.6.1 Introduction

Since the introduction of XHTML-MP mobile web-based applications are developed using the same model used for classic web applications (fig.4).

Fig.4. Simplified model for (mobile) web application development

Scripts, as in WAP, are sets of instruction running on the web browser (client-side scripts) or on the web server (server-side scripts) that allow implementation of procedural logic or change of the content of the web page to be displayed on the client side. Essentially, client-side scripting allows for modification of the webpages once they arrive at the mobile browser whilst server-side scripting is used for creating or changing the webpage (the content) itself.

The mobile web uses JavaScript as the main client-side scripting language whereas on the server side PHP and ASP are typically employed.

Most mobile phones support nowadays HTML5 as the markup language used to structure and to present the content on the mobile web browser.

3.6.2 HTML5 and CSS3

HTML5 leveraged as the de facto standard for structuring the content of a mobile web page. As WAP,

HTML5 uses predefined tags to structure and display this content.

The basic structure of a Hello world like page in HTML5 and its rendering on the the w3schools web

site is shown below:

Fig. 5 The html-based “Hello world” page on a desktop emulator

The <!DOCTYPE> tag is simpler and there is no need for referencing a DTD.

The <html> tag indicates the content of the page and is the root all other elements. The visible part of the page is to be included between the <body> and </body> elements whereas its title is included in the <title> tag. The

Client browser

(client-side scripts)

WEB Server

(server-side scripts)

content

Request

Response

content of the page is included in dedicated tags such as <p> and <h1> and is included between the start tag and the end on the tag represented with angled brackets <tagname>…</tagname>.

The <head> tag is used for including meta information about the page such as viewports for responsive designs, that allow autoscaling of the content of the page depending on the resolution and/orientation, the character set to be used for formatting the page etc.

The content of the page can be styled using a dedicated language allowing the use of styles within an HTML5 documents. The dedicated language for HTML5 is CSS3 (Cascading Style Sheets 3). CSS can be added to style html content either by using a separate file, either in the html document itself by using style attributes or the <style> dedicated tag in the head section of the document. Fig.6 shows the content of the Hello world page with some styling applied.

Fig.6 The “Hello world” page using HTML5 and CSS

3.6.3 Assignments

1) Download the content of the archived project placed on the website. The compressed file is based on an Cordova/PhoneGap project that allows building hybrid mobile applications using scripts through a dedicated file that uses Cordova technology for providing both Web APIs and APIs interfacing with a native operating system The project overrides the OnCreate method of a typical Android project for allowing the use of an Android emulator in order to display the content of an HTML5 page without Web Server interaction.

2) Import the project into the Eclipse IDE 3) Launch an Android Virtual Device (AVD) and check how the webpage is displayed. 4) Create a new AVD with different display capabilities and repeat 3). 5) Add styling to the Web page by using the file index.css included in the project or in a similar manner to

the one shown in the figure above. 6) Clear the content of the index.html file and, based on the HTML5 reference tutorial at

https://www.w3schools.com/html/default.asp build a mobile web page for the Mobile Communications course website http://ares.utcluj.ro/mc_2018.htmlUse various tags to achieve the same effect.

7) Open the TestPhoneGap project already imported in the Eclipse IDE installed on the desktop PC and analyze the functionality provided by the Codova/PhoneGap framework

3.7 Building dynamic applications using server-side scripting

Although extra functionality can be added to HTML5 based applications using client-side scripting, dynamic, customized data display cannot be achieved using only client-side programming techniques Fortunately, it is rather simple to integrate HTML5 with server based scripting languages like: PHP, JSP/servlets or ASP. The following paragraph concentrates on presenting aspects related to the HTML5 ASP interaction.

3.7.1 Active Server Pages

Microsoft Active Server Pages (ASP) is a server-side scripting environment that can be used to develop, create and run dynamic and interactive applications. Server-side scripting means that when a browser requests some data from a web server a script is called by the web server; the code contained in the script is executed and only afterwards the results are returned to the browser that made the request.

ASP scripts are declared on files with the extension .asp and are based on the Visual Basic scripting language (VB scripts).

VBscript commands are always included in paragraphs delimited with <% and %> characters. Each ASP file must contain a line:

<% @LANGUAGE="VBSCRIPT" %>

that indicates ASP to process commands as VBscript. VBScript code can be also included in HTML pages using the same delimiters as mentioned above;

text that in not comprised between delimiters will be treated as HTML.

3.7.2 Using ASP to access remotely a database

Beside its simplicity, one of the strengths of VBScript is its ability to work with databases using some predefined ActiveX objects:

- Server objects - are providing access to methods and properties on the web server. For opening databases the most common used ASP method is CreateObject.

- Recordset objects - are sets of records defined by tables in a database or by queries made on a database.

For building queries VBScript allows use of SELECT – FROM like SQL statements. The following code illustrates the use of the above two objects for opening a recordset that contains all fields listed on

a table (table_name) included on a database wapdb.mdb. <%Option Explicit%>

<%

l_no = Request.QueryString("lecture")

Dim adoCon, rs, Query, Success, l_no, cuv_cheie

Set adoCon = Server.CreateObject("ADODB.Connection") adoCon.Open

"Provider=Microsoft.Jet.OLEDB.4.0; Data Source=" & Server.MapPath("wapdb.mdb")

Set rs = Server.CreateObject("ADODB.Recordset")

Query = "select content from lectures " & "where lecture_no = '"&l_no&"'" rs.Open Query,adoCon

%>

When performing a query the recordset object can contain more that one record; navigation through records is done using predefined methods such as MoveNext, MovePrevious. Identification of the first/last

record is done using also predefined methods: BOF(beginning of file)/EOF (end of file).

When using recordset objects it is a common practice to destroy created objects when they are no longer needed. For the above listed code the sequence of VBScript commands that performs this is:

<% rs.Close set rs = nothing %>

- Response objects – are used to send data to a client. Results can be displayed to a client immediately

or only after all scripts have ended; a response object uses for this purpose the Buffer property. When set to true using the following statement:

<% Response.Buffer = "true" > the web server does not send output to the client until all of the VBScripts on the current page have been processed. If a page must not be cached (it must expire one request is completed) the following statement is employed:

Response.Expires=0

- Session objects – are used to save data during a user-session. A variable stored on a Session object

is persistent for the entire user session even if the user navigates back and forward.

- Request objects – are used to retrieve data passed from a browser to the web server. For example the following code:

<% Dim s s = Request(“var1”) %>

can be used to retrieve in a local variable (s) the content of a variable (var1) a WML client to the web server.

3.7.3 Assignments

1) Analyze the content of the complete ASP script provided in the appendix; explain the functionality of each statement based on the previous explanations and on the ASP description webpage (https://msdn.microsoft.com/en-us/library/aa286483.aspx)

2) Launch a web browser on the desktop computer and, respectively, on the Android emulator. Type in the address window the following URL: http://193.226.17.162/interog.asp?lecture=1. Change the values of the query parameter (lecture) to 2 and 3 and explain the results shown on the web and on the mobile browser.

3.8 Client-side scripts in HTML5

Client-side scripts are usually used to implement procedural logic in html pages and to modify or to filter

the contents of a returns webpage. For defining script HTML5 uses a dedicated tag <script>. The script element might contain scripting parameters such as variables or it can point out to an external script through a dedicated attribute (src). The next figure represents an html page that modifies the content of the HTML/CSS web page in figure 6 using a script. The script itself uses a predefined method getElementById that is applied to a document object i.e. the webpage itself. The paragraph tag used to display a text has a supplementary (id) attribute that is first set and then retrieved by calling the method. The same effect could be achieved by using an external function.

Fig.7 Client-side scripting example

3.8.1 Assignments

Fig.8 Client-side scripting using functions

1) Test the code shown in the figure above using the Android terminal emulator.

2) Design a webpage that includes a <select> tag that allows for creation of a drop-down list with 4 options: “Lecture 1”, “Lecture 2”, “Lecture 3” and “Lecture 4”. Add button and a paragraph; add all necessary code for allowing dynamic modifications of the text contained in the paragraph, according to the chosen option. 3) Based on 3, write a script that will allow dynamic display of content of the selected mobile communications lecture. (Hint: a XMLHttpRequest object could be employed for placing a GET request for an ASP script, in a similar manner to the one presented in §3.6.3). 4) Modify the application and indicate which the necessary modification for the ASP script are in order to allow display both of the content and of the date fields for a particular lecture. 5) Style the mobile web page using CSS.

Appendix 1: The wapdb.mdb MSAccess database

Appendix 2 The interog.asp script

<% @LANGUAGE="VBSCRIPT"%> <%Option Explicit%> <% l_no = Request.QueryString("lecture") Dim adoCon, rs, Query, Success, l_no, cuv_cheie Set adoCon = Server.CreateObject("ADODB.Connection") adoCon.Open "Provider=Microsoft.Jet.OLEDB.4.0; Data Source=" & Server.MapPath("wapdb.mdb") Set rs = Server.CreateObject("ADODB.Recordset") Query = "select content from lectures " & "where lecture_no = '"&l_no&"'" rs.Open Query,adoCon Response.Buffer = True Session("keywords") = rs("content") Response.Write rs("content") rs.Close set rs = nothing %>