Java: A Portable Commercial Programming Language

JAVA

Today, it is widely accepted that Java as a programming language offers the most

portable commercial environment for writing software applications. The success

of Java has been mostly in providing standard Application Program Interfaces

(APIs), a very thoughtfully designed infrastructure for OOP that prohibits many

bad design and implementation habits such as multiple inheritance. Standard

and open APIs offer a process of evolving a language that is open to many

vendors. 

Furthermore, there exist implementations of the virtual machine and

the native dependencies of the APIs for most popular operating systems. There

are three major categories of Java APIs and virtual machines, namely J2ME, J2SE,

and J2EE. Java offers three distinct features as a mobile application platform:

1. Java is an object oriented programming language. As any other programming

language, it can be used to write applications.

2. Java offers complete code mobility and weak mobile agent ability. Java allows

for platform-independent programming.

3. Java is a platform.

First, Java, as with any other programming language, is just that: a programming

language. It allows us to program a set of instructions. Perhaps just as

importantly Java is somewhat of a vendor-neutral language-based platform.”

Java seems to have solved the problem that has plagued many other

programming languages in the past: the lack of standardizing libraries.

1

BREW

Qualcomm’s BREW (Binary Run-time Environment for

Wireless) gives application developers a new and

different approach in producing mobile applications.

BREW is built directly into the hardware. It is offered

as an API to access the CDMA, GSM/GPRS, or UMTS

chip sets that provide the support for it. 

But, it is

primarily intended for the variations of CDMA, a

technology owned and licensed by Qualcomm. BREW

applications can be written on a PC using the BREW

Software Development Kit (SDK).

Once the

application is developed, it must be tested, and then

deployed. Deployment of BREW applications is a

process done jointly by Qualcomm and

telecommunications carriers and not just the

developer.

2

set of applications of BREW

1

. 

BREW MIF Editor

: Every BREW module, defined as the classes that

make up  one or more BREW applications, has an associated Module

Information File

(MIF).

2. 

BREW Device Configurator

: This is a stand-alone application that

allows developers

to make up their own handset by configuring a vanilla mobile phone

and specifying the behaviour of the keys, the look and feel of the

screen, and  other specifics of the device.

3. 

BREW Emulator

: For those who have designed and implemented

any mobile  application, it is obvious that one of the most difficult

steps in the development   process is the incremental unit testing.

4. 

BREW Image Authoring Tool

: There is an image authoring tool that

allows creation of images for BREW. This tool can use PNG or BMP

files.

5. 

BREW ARM Compiler

: Many mobile devices are based on the ARM

or Strong-  ARM hardware platform (registered trademarks of ARM

Corporation).

3

set of applications of BREW

6. 

Image Converter

: The tool set provides an image converter to convert 4-bit

bitmaps to 2-bit bitmaps as BREW only supports 2-bit bitmaps because of the

limited resources on mobile devices

7. 

BREW Resource Editor

: If you have worked with Java or C++ to build GUI

client-side applications, then you are familiar with the concept of a resource

bundle. Resource files in BREW are a collection of images, strings, and dialog

look-and-feel components that allow changing the look and feel of the application

for internationalization and similar purposes without changing the code

base. The BREW Resource Editor gives the developers a GUI interface to manage

the resource files.

8. 

BREW Pure Voice Converter

: This command line utility allows the developers

to convert wave files (audio) to Pure Voice files or vice versa.

9. 

BREW AppLoader

: This tool allows the developer to deploy an application on

a handset through a PC connector. This is a testing and not a deployment tool.

10. 

BREW Grinder

: The Grinder generates a variety of inputs and tests the

application.

11. 

BREW TestSig Generator and AppSigner

: The TestSig tool provides the developer

a mechanism to generate a test Class ID.

4

WINDOWS CE

An operating system is the master control program that

enables the hardware by abstracting it to the application via

drivers [Development tools for Mobile and Embedded

Applications 2002]. Microsoft’s various products revolve

around different versions of an operating system

. The versions

that concern us, the mobile application developers, most are

Windows CE and Embedded Windows XP. Windows CE has

been around since 1997 and Embedded Windows XP is being

released at the time of authoring this text

. 

These two

operating systems are designed for two different purposes.

There are different flavors of the Windows CE operating

systems, of course, depending on the hardware platform.

Some of these flavors are the Pocket PC, Windows CE .NET, and

Pocket PC 2002

. 

These flavors largely depend on the

commercial bundling of different feature sets and hardware

platforms with which they are shipped (such as Compaq’s

IPAQ). Embedded Windows XP, in contrast, is a subset of the

desktop version of Windows XP components. Development for

Embedded Windows XP is a bit more straightforward than

developing for Windows CE

.

5

Microsoft provides tools to build applications for each

environment too. These are as follows

1. Embedded Visual C++:This is a tool set separate from Visual

Studio, the typical development environment for PC-based

Windows applications. It allows for authoring mobile

applications in C++.

2. Embedded Visual Embedded Visual Basic: This tool provides

the ability to write applications using

Visual Basic.

3. Smart Device Extensions for .NETSmart Device Extensions for

.NET: The .NET application programming platform, the newest

set of tools for building Microsoft Windows-based applications,

can be complemented with a set of extensions that allow

developers to author .NET applications for mobile devices.

4. Microsoft Mobile Internet Toolkit: This is really a server-side

frame work We will discuss it along with the other publishing

tools later in this chapter.

6

WAP

Wireless Application Protocol (WAP) is the single framework

most used in building mobile applications today. Despite all of

its initial high promises, its lack of meeting those promises, and

being written off for dead, WAP seems to have survived the

critics and continues to improve. 

WAP, which was initially

intended to be as pervasive for wireless and mobile applications

as HTTP has been for the Web, never achieved the level of

success initially expected. However, to date, WAP has  the

largest install base of all open application development

platforms (second to  NTT Docomo’s closed and proprietary i-

mode system) on mobile phones, meaning  that WAP is installed

on more mobile phones than any other software

.  WAP shares

some similarities to HTTP. From its inception to now, it has

become  more and more like HTTP. WAP 1.x and WAP 2.x are

significantly different with  WAP 1.x being the basis for nearly all

the current installations in the market today  and WAP 2.x being

the target platform for WAP devices during 2003 and 2004.  Let

us go over some basics about WAP

.

7

WAP

1. WAP is intended for thin clients. Much like HTTP, the designers of

WAP 1.x were thinking about a thin-client technology: a case where

nearly all logic is calculated on the server and very simple display

instructions are bundled in some mark up language to be displayed by

the client.

2. WAP is built on its own lower level communication protocol.

Whereas HTTP assumes the existence of TCP/IP (which in turn

provides persistent connections), WAP is built on its own set of

communication protocols that wrap around TCP, UDP, or a variety of

other possible protocol implementations.

3. Typical deployment of WAP includes a proxy or a gateway. Wireless

carriers (also referred to as bearer networks) like to have control of

every single incoming and outgoing bit of data that travels on their

network. This is understandable as usage time is the typical

mechanism for billing.

4. WAP is a complete framework for mobile applications. Whereas

most tools created for development of applications treat a part of the

mobile application chain, WAP treats, or at least attempts to treat, all

parts of the mobile equation.

8

Chapter3.

XML: The Document and

Metadata Format for

Mobile Computing

The Extensible Markup Language—XML—is a

subset of the Standard Generalize Markup

Language (SGML) specified in ISO standard

8879. SGML was created to create and maintain

complex and portable documents to be used in

highly scalable systems in a non proprietary

manner to any particular vendor. XML has

become a key technology in the development

of content for the World Wide Web

. 

Today, with

the birth of Web services, it is used for more

than its original purpose of representing

documents.

9

10

XML and Mobile Applications

1.

Mobile applications should understand and be able to manipulate

XML content. As content on the Internet, and other networks,

moves into an XML format, it is very desirable that a given mobile

application can handle XML. How the XML is handled is of particular

interest. Although the task of parsing and interpreting the XML can

be done on the mobile device itself, or some proxy such as an

application server that processes all content for the device, issues

such as performance become of paramount concern

2.

Mobile applications use XML to facilitate their implementations. For

example, XML documents can be used by mobile applications to

exchange data; configuration of a device or a server may be

encapsulated in an XML file; some protocols such as WAP use XML

as the means for presentation. There are countless places where

mobile applications and related frameworks can use XML internally.

11

DOM Parsing

The Document Object Model (DOM) is the tree

representation of all of the XML elements. Every element

becomes a node and nodes. Nodes can have children to

support nesting of nodes in the same way as an XML

element can have other elements. The mapping of DOM to

UML is very simple. 

Every node is an object, an instance of a

class. The XML attributes are the object attributes and the

children nodes are encapsulated data members. ADOM

parser written in an object-oriented language such as Java,

C++, or C# goes through the entire XML document and

creates a tree of nodes, with the nodes being objects. 

DOM

parsers are also required to preserve the order of elements.

There may be meaning in the order of elements. The same

is not required of attributes.

12

SAX Parsing

S

A

X

(

S

i

m

p

l

e

A

P

I

f

o

r

X

M

L

)

c

r

e

a

t

e

s

a

s

e

r

i

e

s

o

f

e

v

e

n

t

s

a

s

i

t

p

a

r

s

e

s

t

h

r

o

u

g

h

t

h

e

X

M

L

d

o

c

u

m

e

n

t

i

n

s

t

e

a

d

o

f

c

r

e

a

t

i

n

g

a

n

o

b

j

e

c

t

m

o

d

e

l

o

f

t

h

e

e

n

t

i

r

e

d

o

c

u

m

e

n

t

i

n

m

e

m

o

r

y

.

T

h

e

r

e

a

r

e

t

w

o

k

e

y

a

d

v

a

n

t

a

g

e

s

t

h

a

t

S

A

X

o

f

f

e

r

s

o

v

e

r

D

O

M

:

1

.

M

o

s

t

o

f

t

h

e

t

i

m

e

,

w

e

d

o

n

o

t

n

e

e

d

a

l

l

o

f

t

h

e

i

n

f

o

r

m

a

t

i

o

n

i

n

t

h

e

d

o

c

u

m

e

n

t

.

S

o

,

t

h

e

o

b

j

e

c

t

m

o

d

e

l

d

e

s

i

r

e

d

d

o

e

s

n

o

t

h

a

v

e

t

o

h

a

v

e

e

v

e

r

y

e

l

e

m

e

n

t

a

n

d

a

t

t

r

i

b

u

t

e

o

f

t

h

e

d

o

c

u

m

e

n

t

.

A

c

u

s

t

o

m

o

b

j

e

c

t

m

o

d

e

l

i

n

t

h

i

s

c

a

s

e

i

s

m

o

r

e

e

f

f

i

c

i

e

n

t

.

W

e

c

a

n

w

r

i

t

e

a

c

u

s

t

o

m

o

b

j

e

c

t

m

o

d

e

l

a

n

d

a

d

r

i

v

e

r

t

h

a

t

c

a

t

c

h

e

s

t

h

e

S

A

X

e

v

e

n

t

s

a

s

t

h

e

S

A

X

p

a

r

s

e

r

r

e

a

d

s

t

h

r

o

u

g

h

t

h

e

d

o

c

u

m

e

n

t

a

n

d

e

m

i

t

s

t

h

e

m

a

n

d

f

i

l

l

s

u

p

t

h

e

c

u

s

t

o

m

o

b

j

e

c

t

m

o

d

e

l

.

2

.

W

e

d

o

n

o

t

h

a

v

e

t

o

w

a

i

t

f

o

r

t

h

e

e

n

t

i

r

e

d

o

c

u

m

e

n

t

t

o

b

e

p

r

o

c

e

s

s

e

d

b

e

f

o

r

e

u

s

i

n

g

t

h

e

c

o

n

t

e

n

t

s

o

f

t

h

e

d

o

c

u

m

e

n

t

.

F

o

r

v

e

r

y

l

a

r

g

e

d

o

c

u

m

e

n

t

s

,

D

O

M

b

e

c

o

m

e

s

p

r

o

b

l

e

m

a

t

i

c

a

s

i

t

h

a

s

t

o

l

o

a

d

t

h

e

e

n

t

i

r

e

d

o

c

u

m

e

n

t

i

n

t

o

m

e

m

o

r

y

b

e

f

o

r

e

i

t

m

a

k

e

s

i

t

s

c

o

n

t

e

n

t

s

a

v

a

i

l

a

b

l

e

.

I

n

c

o

n

t

r

a

s

t

,

a

s

a

S

A

X

p

a

r

s

e

r

p

r

o

g

r

e

s

s

e

s

t

h

r

o

u

g

h

p

r

o

c

e

s

s

i

n

g

a

d

o

c

u

m

e

n

t

,

i

t

e

m

i

t

s

e

v

e

n

t

s

;

t

h

e

r

e

f

o

r

e

,

b

y

n

a

t

u

r

e

,

i

t

a

l

l

o

w

s

i

m

m

e

d

i

a

t

e

p

r

o

c

e

s

s

i

n

g

o

f

t

h

e

i

n

f

o

r

m

a

t

i

o

n

13

XML WEB SERVICES

Web Services are a prime example of an organic, as opposed to a

synthetic, evolution  in technology. They exist because the HTTP

protocol is ubiquitous: Just  about everyone today has access to the

Web. Web services build on the HTTP protocol methods, mostly GET

and POST, to build an RPC (Remote Procedure Call) that allows two

systems to exchange messages over HTTP. But

, 

why not use CORBA,

COM, JINI, or other distributed computing protocols? XML based Web

services are not efficient: They convert binary to text to convert it back

to binary again. This is a weak point of XML based Web services when it

comes to dealing with mobile applications. However, there are work-

arounds Web services are a text-based MMI (Machine-to-Machine

Interface). However, they are simple to build and they take advantage

of the ubiquity of the Web

. 

Protocols such as CORBA have failed in

becoming ubiquitous. Other protocols such as COM are proprietary to a

platform. The platform of Web services is the Web. Regardless of level

of efficiency, those two aspects alone create an economic reason for

Web services to exist.

 Another consideration that accompanies the use

of Web services  (typically HTTP based though they can be based on

other protocols such as SMTP)  is security.

14

Web Services and Mobile Applications

1. Web Service Proxy

: The infrastructure of mobile

applications can use Web services for messaging. For

example, a given system may allow mobile users to find

someone’s phone number through a directory service

and subsequently get the driving directions to that

person’s place of residence. These two functions, finding

the phone number and the driving directions, may be

fulfilled by two different systems, each implemented in a

different environment

. 

So, the back end for our mobile

system may use Web services to connect to each one of

these systems and retrieve the information we need to

return it to us. The interface between the back-end

system and the device remains consistent and can be

implemented through whatever communication protocol

may be necessary. This  is the more likely scenario for

most systems.

15

Web Services and Mobile Applications

2

.

D

i

r

e

c

t

C

o

n

n

e

c

t

i

o

n

t

o

W

e

b

S

e

r

v

i

c

e

s

:

M

o

b

i

l

e

d

e

v

i

c

e

s

w

i

t

h

m

o

r

e

r

e

s

o

u

r

c

e

s

c

a

n

d

i

r

e

c

t

l

y

a

c

c

e

s

s

t

h

e

n

e

t

w

o

r

k

t

h

r

o

u

g

h

t

h

e

u

s

e

o

f

W

e

b

s

e

r

v

i

c

e

s

(

s

e

e

F

i

g

u

r

e

3

.

4

)

.

O

f

c

o

u

r

s

e

,

t

h

i

s

r

e

q

u

i

r

e

s

a

c

o

n

s

i

d

e

r

a

b

l

y

a

d

v

a

n

c

e

d

m

o

b

i

l

e

d

e

v

i

c

e

a

s

w

e

h

a

v

e

t

o

h

a

v

e

v

e

r

y

e

f

f

i

c

i

e

n

t

X

M

L

p

a

r

s

i

n

g

a

s

w

e

l

l

a

s

t

h

e

a

b

i

l

i

t

y

t

o

w

r

i

t

e

s

u

b

s

t

a

n

t

i

a

l

a

p

p

l

i

c

a

t

i

o

n

s

t

h

a

t

i

m

p

l

e

m

e

n

t

t

h

e

a

p

p

l

i

c

a

t

i

o

n

o

f

X

M

L

t

h

a

t

s

u

p

p

o

r

t

s

t

h

e

p

a

r

t

i

c

u

l

a

r

W

e

b

s

e

r

v

i

c

e

t

o

w

h

i

c

h

t

h

e

m

o

b

i

l

e

d

e

v

i

c

e

m

u

s

t

c

o

n

n

e

c

t

t

o

.

16

KEY XML TECHNOLOGIES FOR MOBILE

COMPUTING

S

o

m

e

s

t

a

n

d

a

r

d

a

p

p

l

i

c

a

t

i

o

n

s

o

f

X

M

L

h

a

v

e

b

e

e

n

s

p

e

c

i

f

i

c

a

l

l

y

d

e

s

i

g

n

e

d

w

i

t

h

m

o

b

i

l

e

a

p

p

l

i

c

a

t

i

o

n

s

i

n

m

i

n

d

.

S

t

a

n

d

a

r

d

i

z

a

t

i

o

n

o

f

s

u

c

h

a

p

p

l

i

c

a

t

i

o

n

s

o

f

X

M

L

i

s

r

e

q

u

i

r

e

d

t

o

p

r

o

v

i

d

e

i

n

t

e

r

o

p

e

r

a

b

i

l

i

t

y

b

e

t

w

e

e

n

d

i

s

p

a

r

a

t

e

s

y

s

t

e

m

s

.

A

s

w

e

m

e

n

t

i

o

n

e

d

p

r

e

v

i

o

u

s

l

y

,

m

o

b

i

l

e

a

p

p

l

i

c

a

t

i

o

n

s

s

h

o

u

l

d

b

e

a

b

l

e

t

o

h

a

n

d

l

e

X

M

L

c

o

n

t

e

n

t

.

T

h

i

s

m

a

y

m

e

a

n

p

a

r

s

i

n

g

t

h

e

c

o

n

t

e

n

t

t

o

t

a

k

e

s

o

m

e

a

c

t

i

o

n

s

b

a

s

e

d

o

n

t

h

e

c

o

n

t

e

n

t

,

t

r

a

n

s

f

o

r

m

i

n

g

t

h

e

c

o

n

t

e

n

t

f

o

r

v

a

r

i

o

u

s

u

s

e

r

i

n

t

e

r

f

a

c

e

s

,

o

r

u

s

i

n

g

X

M

L

a

s

t

h

e

m

e

t

a

d

a

t

a

f

o

r

h

a

n

d

l

i

n

g

v

a

r

i

o

u

s

t

y

p

e

s

o

f

c

o

n

t

e

n

t

.

T

h

e

r

e

a

r

e

a

s

e

t

o

f

s

t

a

n

d

a

r

d

s

b

y

W

3

C

a

n

d

p

r

o

p

r

i

e

t

a

r

y

r

e

c

o

m

m

e

n

d

a

t

i

o

n

s

b

y

v

a

r

i

o

u

s

v

e

n

d

o

r

s

t

h

a

t

a

p

p

l

y

f

o

r

t

h

e

s

e

c

a

s

e

s

.

W

e

w

i

l

l

f

o

c

u

s

o

n

s

t

a

n

d

a

r

d

s

r

e

c

o

m

m

e

n

d

e

d

b

y

W

3

C

a

s

t

h

e

y

a

r

e

t

y

p

i

c

a

l

l

y

m

o

r

e

e

n

c

o

m

p

a

s

s

i

n

g

t

h

a

n

p

r

o

p

r

i

e

t

a

r

y

r

e

c

o

m

m

e

n

d

a

t

i

o

n

s

.

17

XML-Based User Interface Technologies for

Mobile Applications

A

s

w

e

p

r

e

v

i

o

u

s

l

y

m

e

n

t

i

o

n

e

d

,

o

n

e

o

f

t

h

e

f

i

r

s

t

m

a

r

k

u

p

l

a

n

g

u

a

g

e

s

t

o

b

e

p

e

r

v

a

s

i

v

e

l

y

u

s

e

d

w

a

s

H

T

M

L

.

M

o

s

t

o

f

t

h

e

W

e

b

d

o

c

u

m

e

n

t

s

t

o

d

a

y

e

x

i

s

t

i

n

H

T

M

L

.

H

T

M

L

i

s

a

n

a

p

p

l

i

c

a

t

i

o

n

o

f

S

G

M

L

,

b

u

t

i

t

i

s

n

o

t

v

e

r

y

c

l

e

a

n

.

X

H

T

M

L

i

s

a

n

a

t

t

e

m

p

t

a

t

c

l

e

a

n

i

n

g

u

p

t

h

e

H

T

M

L

s

y

n

t

a

x

a

n

d

p

r

o

v

i

d

i

n

g

a

v

e

r

s

i

o

n

o

f

H

T

M

L

t

h

a

t

i

s

a

n

a

p

p

l

i

c

a

t

i

o

n

o

f

X

M

L

.

X

H

T

M

L

w

i

l

l

r

e

p

l

a

c

e

H

T

M

L

p

a

s

t

v

e

r

s

i

o

n

4

.

0

1

a

n

d

i

t

i

s

a

n

a

p

p

r

o

v

e

d

W

3

C

s

t

a

n

d

a

r

d

.

O

n

e

o

f

t

h

e

b

i

g

g

e

s

t

p

r

o

b

l

e

m

s

t

h

a

t

H

T

M

L

p

r

e

s

e

n

t

e

d

w

a

s

t

h

a

t

i

t

w

a

s

n

o

t

d

e

s

i

g

n

e

d

t

o

b

e

u

s

e

d

b

y

a

w

i

d

e

v

a

r

i

e

t

y

o

f

u

s

e

r

i

n

t

e

r

f

a

c

e

t

y

p

e

s

.

H

T

M

L

w

a

s

d

e

s

i

g

n

e

d

w

i

t

h

m

i

n

i

m

u

m

r

e

q

u

i

r

e

m

e

n

t

s

o

f

a

c

o

l

o

r

s

c

r

e

e

n

o

f

6

4

0

×

4

8

0

p

i

x

e

l

s

a

n

d

t

h

e

P

C

i

n

m

i

n

d

.

T

h

o

u

g

h

s

o

m

e

c

o

n

s

i

d

e

r

a

t

i

o

n

s

w

e

r

e

m

a

d

e

f

o

r

s

c

r

e

e

n

s

t

h

a

t

d

i

d

n

o

t

d

i

s

p

l

a

y

g

r

a

p

h

i

c

s

,

n

o

t

m

u

c

h

e

l

s

e

w

a

s

a

v

a

i

l

a

b

l

e

t

o

t

h

e

d

e

v

e

l

o

p

e

r

.

A

l

s

o

,

H

T

M

L

w

a

s

n

o

t

s

t

r

i

c

t

e

n

o

u

g

h

i

n

e

n

f

o

r

c

i

n

g

s

y

n

t

a

x

.

S

o

,

p

r

o

g

r

a

m

m

a

t

i

c

c

h

a

n

g

e

s

t

o

H

T

M

L

t

o

m

a

k

e

i

t

f

i

t

v

a

r

i

o

u

s

d

e

v

i

c

e

s

w

a

s

n

o

t

p

o

s

s

i

b

l

e

w

i

t

h

o

u

t

m

a

k

i

n

g

a

s

s

u

m

p

t

i

o

n

s

(

w

h

i

c

h

i

n

t

u

r

n

c

r

e

a

t

e

b

u

g

s

)

.

18

XML-Based User Interface Technologies for

Mobile Applications

X

F

o

r

m

s

a

l

l

o

w

s

u

s

t

o

b

u

i

l

d

u

s

e

r

i

n

t

e

r

f

a

c

e

s

w

i

t

h

a

f

o

c

u

s

o

n

t

h

e

i

n

t

e

r

a

c

t

i

o

n

s

a

n

d

d

a

t

a

e

x

c

h

a

n

g

e

s

b

e

t

w

e

e

n

t

h

e

u

s

e

r

a

n

d

t

h

e

u

s

e

r

i

n

t

e

r

f

a

c

e

a

s

o

p

p

o

s

e

d

t

o

s

p

e

c

i

f

i

c

t

y

p

e

s

o

f

u

s

e

r

i

n

t

e

r

f

a

c

e

.

X

F

o

r

m

s

a

l

l

o

w

s

u

s

t

o

s

e

p

a

r

a

t

e

c

o

n

c

e

r

n

s

a

m

o

n

g

p

r

e

s

e

n

t

a

t

i

o

n

l

o

g

i

c

s

p

e

c

i

f

i

c

t

o

t

h

e

a

p

p

l

i

c

a

t

i

o

n

,

t

h

e

p

r

e

s

e

n

t

a

t

i

o

n

l

o

g

i

c

s

p

e

c

i

f

i

c

t

o

t

h

e

d

e

v

i

c

e

,

t

h

e

d

a

t

a

e

x

c

h

a

n

g

e

d

b

e

t

w

e

e

n

t

h

e

u

s

e

r

a

n

d

t

h

e

s

y

s

t

e

m

,

a

n

d

t

h

e

i

n

t

e

r

a

c

t

i

o

n

f

l

o

w

.

I

t

i

s

n

a

t

u

r

a

l

f

o

r

X

M

L

t

o

b

e

t

h

e

c

o

r

e

o

f

a

u

s

e

r

i

n

t

e

r

f

a

c

e

s

y

s

t

e

m

i

n

f

r

a

s

t

r

u

c

t

u

r

e

,

m

o

b

i

l

e

o

r

n

o

t

.

X

M

L

i

s

t

e

x

t

u

a

l

,

s

t

r

u

c

t

u

r

e

d

,

a

n

d

d

o

c

u

m

e

n

t

b

a

s

e

d

.

T

h

o

s

e

t

h

r

e

e

e

l

e

m

e

n

t

s

a

r

e

o

f

u

t

m

o

s

t

i

m

p

o

r

t

a

n

c

e

i

n

b

u

i

l

d

i

n

g

a

h

u

m

a

n

–

c

o

m

p

u

t

e

r

i

n

t

e

r

f

a

c

e

(

H

C

I

)

.

T

h

e

r

e

a

r

e

o

t

h

e

r

a

p

p

l

i

c

a

t

i

o

n

s

o

f

X

M

L

f

o

r

m

o

b

i

l

e

a

p

p

l

i

c

a

t

i

o

n

i

n

f

r

a

s

t

r

u

c

t

u

r

e

s

a

s

w

e

l

l

.

W

e

w

i

l

l

n

o

w

b

r

i

e

f

l

y

i

n

t

r

o

d

u

c

e

s

o

m

e

a

p

p

l

i

c

a

t

i

o

n

s

o

f

X

M

L

t

h

a

t

c

o

n

t

r

o

l

f

l

o

w

o

f

i

n

t

e

r

a

c

t

i

o

n

s

.

19

Putting XML to Work

X

M

L

h

a

s

a

l

r

e

a

d

y

b

e

c

o

m

e

t

h

e

d

e

f

a

c

t

o

d

o

c

u

m

e

n

t

s

t

a

n

d

a

r

d

f

o

r

e

x

c

h

a

n

g

e

o

f

h

u

m

a

n

r

e

a

d

a

b

l

e

d

a

t

a

.

W

h

e

t

h

e

r

s

u

c

h

w

i

l

l

b

e

t

h

e

c

a

s

e

f

o

r

m

a

c

h

i

n

e

-

t

o

-

m

a

c

h

i

n

e

c

o

m

m

u

n

i

c

a

t

i

o

n

i

s

q

u

e

s

t

i

o

n

a

b

l

e

;

n

e

v

e

r

t

h

e

l

e

s

s

,

s

u

c

h

a

p

p

l

i

c

a

t

i

o

n

s

e

x

i

s

t

a

n

d

t

h

e

i

r

p

o

p

u

l

a

r

i

t

y

i

s

i

n

c

r

e

a

s

i

n

g

.

I

n

t

h

i

s

c

h

a

p

t

e

r

,

w

e

l

o

o

k

e

d

a

t

a

v

a

r

i

e

t

y

o

f

X

M

L

-

b

a

s

e

d

t

e

c

h

n

o

l

o

g

i

e

s

a

n

d

t

o

o

k

a

n

i

n

t

r

o

d

u

c

t

o

r

y

g

l

i

m

p

s

e

a

t

t

h

e

i

r

u

s

e

i

n

m

o

b

i

l

e

a

p

p

l

i

c

a

t

i

o

n

s

.

T

h

e

n

,

w

e

l

o

o

k

e

d

a

t

R

D

F

,

a

p

a

r

t

o

f

t

h

e

S

e

m

a

n

t

i

c

W

e

b

t

h

a

t

i

s

b

e

c

o

m

i

n

g

p

e

r

v

a

s

i

v

e

l

y

m

o

r

e

c

r

u

c

i

a

l

t

o

m

o

b

i

l

e

a

p

p

l

i

c

a

t

i

o

n

s

.

W

e

f

o

l

l

o

w

e

d

t

h

i

s

b

y

d

i

s

c

u

s

s

i

o

n

s

o

f

C

C

/

P

P

a

n

d

U

A

P

r

o

f

a

s

a

p

p

l

i

c

a

t

i

o

n

s

o

f

R

D

F

a

n

d

X

M

L

f

o

r

m

o

b

i

l

e

a

p

p

l

i

c

a

t

i

o

n

s

a

n

d

f

i

n

i

s

h

e

d

o

f

f

t

h

e

c

h

a

p

t

e

r

b

y

t

a

l

k

i

n

g

a

b

o

u

t

X

M

L

t

o

U

M

L

m

a

p

p

i

n

g

.

The significance of XML to mobile applications is twofold: First, it offers a

well-formed and deterministically modifiable format for human-readable

data, and second, it offers interoperability.

20

Chapt.5

 Generic User Interface Development

such as issues related to human factors are not well

defined. In this text, we will use terminologies outlined

by ECMA (European Computer Manufacturer

Association), W3C (World Wide Web Consortium), or

similar non-commercial standards bodies. 

It is also

important to note that user interface development for

mobile applications is a new field; therefore, there will be

occasions when these bodies have not decided on a

standard way of addressing these problems. In such

cases, we will build some logical vocabulary as built on

top of the existing standards and as decided by the

author of this book

. The first step in moving forward is to

ask ourselves, “Why do we want to build generic user

interfaces?” First, mobile applications are typically used

by a wider array of operating environments and systems

than a PC. Because there is such a wide array of end

clients for mobile applications, we need to be able to

adapt the application quickly, if not in real time, with

very little or no additional development effort.

21

User Interface Development

A software application is started by a person,

another software application, a hardware

application, or a combination thereof. A demon

program may invoke a server  application at a

particular time; this is an example of a software

application being  invoked by another software

application. 

The operating system itself is an

application  that may be started by a

hardware/software driven application, turning the

computer on, providing power to the CPU, and

allowing the initialization software  permanently

stored on the hardware to invoke an operating

system.

Excluding artificially  intelligent systems, all

software applications, at some point and perhaps

through a long line of succession, are either started

or scheduled to start by a  person—a user.

22

Human Factors

Dix et al. define human factors, often referred to as

ergonomics, as the study of

the physical characteristics of the interaction: how

the controls are designed, the physical environment

in which the interaction takes place, and the layout

and physical qualities of the screen [Dix et al. 1998].

For any typical application, we need to consider the

following as the elements of human factors

consideration:

1. the look and feel of the application and how the

users “like” the user interface,

2. the ease of learning the interface well and

becoming efficient at using the user

interface, and

3. health issues in using the user interface.

23

Usability, Human Factors, and Other

Considerations for  Developing Stationary PC-Based

User Interfaces

list some issues that the software engineering

industry, as a whole, deems to be important

1.

Intuitiveness: User interfaces should be intuitive.

User interfaces should be intuitive. The first time

a user uses an application, he or she should be

able to navigate his or her way through without

too much trouble, assuming a reasonable

amount of familiarity with the application

domain.

2.

Consistency: Consistency: A software application

should present user interface components that

are consistent with each other and consistent

with their operating environments.

24

Usability, Human Factors, and Other

Considerations for  Developing Stationary PC-Based

User Interfaces

3. Learnablility: The user should be able to

learn how to use the user interface within

the first few times of using it and remember

how to use it without having to refer to

manuals. This goes hand in hand with the

user interface being intuitive.

4.

 Nonintrusively Helpful: The user interface

and the underlying application should

provide help and hints. There can never be

too much in the way of help and hints on a

user interface.

25

Usability, Human Factors, and Other

Considerations for  Developing Stationary PC-Based

User Interfaces

5. Accommodating Expert Users: A good user

interface provides shortcuts for the expert

users. Applications should be efficient and fast

to use for expert users. As a user learns how to

use the system better, he or she should be able

to access the information and perform the tasks

faster and faster.

6. Trustable: The user interface should be

predictable, trustable, and easily understood.

There should be a simple set of rules that are

used in building the user interface that allow

the user to be able to guess what the reaction

of the user interface may be.

26

Usability, Human Factors, and Other

Considerations for  Developing Stationary PC-Based

User Interfaces

7. Robustness [Dix et al. 1998]: A good user

interface should gracefully recover from user

errors (e.g., display the proper dialogue

boxes to guide the user when an error

happens), should convey the relation to the

application logic easily to the user (e.g.,

make sure that the user knows which data

are changing, when transactions are

committed, etc.), and should be fast enough

and let the user know when there are long

waits for responses.

27

Example 5.1: User Interface Consistency Guidelines for a

Mortgage Banking  Application.

A) Guidelines by Domain:

a. Color: Use white, black, scales of gray, and scales of blue only. These are the

branding colors associated with ACME Mortgage corporation.

b. VUI Prompts: All prompts relating to gathering information for the financial

portions of the loan application should be recorded by a female voice talent. All

prompts relating to gathering information for the personal sections of the loan

applications should be recorded by a young male voice talent.

B) Guidelines by User Interface Components:

a. Color: Use blue for all of the buttons. Use white for all of the backgrounds. Use

black for all of the fonts. Use scales of gray for all other interface components

.

b. VUI prompts: All informative prompts must be recorded by a female voice talent.

All warnings must be recorded by a male voice talent. When the user does not

understand one prompt pronounced by a given voice artist twice, the voice talent

should be dynamically changed to allow the user to understand the voice of

another voice talent.

28

BUILDING GENERIC USER INTERFACES

Before we go into this further, let us look at when we want to build generic

interfaces and when we do not. Let us consider applications that can benefit from

a layered user interface approach:

1. Applications that change frequently: Many applications change very frequently.

Such constant changing of state may be caused by the business model that the

application serves or a variety of other reasons.

2. Applications that support a wide variety of devices: We have talked about this

several times now, so the reader should well know that mobile applications need

to support a variety of device types.

3. Applications that must have many loosely coupled parts: One of the advantages

of building a generic user interface to a system is that it enables loose coupling

between the user interface components themselves and among the look-and-feel

components, interaction logic, and application flow logic.

4. Applications that offer multiple user interfaces with a range of complexity: A

good reason to justify building systems with generic user interfaces is the

requirement of supporting multiple user interfaces, each with some difference in

the required feature sets

.

29

BUILDING GENERIC USER INTERFACES

So, when implementing the generic user interface, we provide all of the possible

functionality needed from the various user interfaces. In this way, we achieve

several goals:

a. We avoid building the logic for the user to interact with the system multiple

times.

b. We build a consistent way of accessing all functionality. Remember that

maintaining consistency across multiple user interfaces for our system is a must.

The first place to start to establish such consistency is with the way the back end

expects the user interactions to behave.

c. If we decide to make the system state full (so that the system remembers the

things that the user does as he or she navigates through the system), we can

easily maintain the state across different user interfaces. (We will look at exactly

how to implement such functionality in Chapter 8.)

d. Changing the set of functionality supported by the various user interfaces

becomes significantly easier. To support a piece of functionality supported by the

generic user interface, all we need to do is to add the corresponding specialization

features to the components that specialize the generic user interfaces.

30

31

FIGURE 5.1. Layering User Interfaces.

Developing Mobile GUIs  Chapter6

final goal: building mobile user interfaces. Mobile user interfaces inherently

have different requirements than their stationary counterparts because of

the dimensions of mobility and the mobile condition of the user. The

dimensions of mobility affect design and implementation of user interfaces

in two fundamental ways. 

The first is that the user interface has to

accommodate functionality that relates to the dimensions of mobility. For

example, user interfaces must be available on all of those devices through

which the user of an application may access a system. Second, the

dimensions of mobility create various concerns that require further

separation of concerns when building user interfaces. 

Today’s state-of-the-

art techniques in model-view-controller (MVC) and presentation abstraction-

control are incomplete in treating these concerns so we will first examine

them and then examine enhancements and alternatives to the existing

techniques that allow us to design and implement with the proper

separation of concerns for the new concerns introduced by the dimensions

of mobility

32

Developing Mobile GUIs

We have already begun this process by looking at building generic user

interfaces

. Generic user interfaces simply model a user’s interaction with the

system (independent of  the modality and the communication channels).

33

PAC, MVC, and Others

As you recall, we face multiple challenges in developing user interfaces for

mobile applications. There are a multitude of devices and platforms used by

the consumers (device proliferation), the user interface must be robust

enough to allow the modalities that fit the condition of the mobile user at

the time of using the system (support for a wide variety of user interfaces),

and the user interface of one application may need to adapt itself to be used

under a number of system conditions (low battery, poor QOS, and low device

user interface capabilities). 

Because of the relative short lifetime of the

mobile device acceptance in the marketplace and the large permutations of

possible platforms (mobile operating system, hardware, network,

deployment, etc.) we have to do our best to construct the device so that

code is maintainable, extensible, and flexible. Whatever problems you may

have faced in maintainability, extensibility, and flexibility of software for

stationary  applications are permutated by the dimensions of mobility.

34

PAC, MVC, and Others

There are a variety of software development techniques for developing the

user interface to stationary applications, but we will focus on those

techniques that have evolved from the study of object-oriented

programming and design patterns. If your chosen language for building your

mobile application is C++, Java, or another object-oriented programming

language, these techniques will apply directly. However, even if you are

using a language such as C (and the relevant tool sets), the concepts will still

apply

. You may need to apply some creativity (or read up on writing object-

oriented applications with C) in adapting these techniques to the language of

your choice.

35

Model-View-Controller

Model-View-Controller (MVC) is an object-oriented design pattern for

separation of concerns of applications with user input (see Figure 6.1).MVCis

best defined by Buschmann, Meunier, Rohnert, Sommerlad, and Stal (also

known as the “Gang of Five”) in one of the staple texts of software

application development called Pattern Oriented Software Architecture: A

System of Patterns. MVC divides an interactive . 

The model is the internal

implementation of the application and does not encapsulate any data or

have any behaviour related to interactions with the user or the presentation

of data to the user. The view encapsulates any output through the user

interface to the user. What you can view on the screen or hear on the phone

is rendered by the view. 

MVC allows separation of three different concerns:

receiving input from the user (controller), implementing components that

model business logic and operations that build the core functionality of the

application (model), and presenting information to the user (view).

36

Model-View-Controller

MVC has a couple of disadvantages. First, proliferation of views and

controllers becomes unmanageable and very difficult to maintain as mobile

applications have multiple user interfaces rendered through multiple

channels and can receive input from numerous controllers. Second, the

inherent asymmetry in treating the input and the output from the user to

the model compounds the effect of this proliferation problem. 

For example,

a system that offers a VUI and an HTML user interface for its users would

need at least two separate controllers, one that can receives user input

through a voice channel and another that receives input from the user

through HTTP

. 

Likewise, two different views would be needed, one that

renders a GUI in HTML and another that renders an aural user interface

through playback of audio. If we wanted access to the aural user interface

through the PC as well as the telephony system, we would end up with two

controllers and two views for the VUI. It is easy to see that the user

interfaces and channels to be supported for a mobile application can become

unmanageable.

37

Model-View-Controller

MVC still gives us some value in separating the three major concerns, but its

tightly coupled and asymmetric nature, as well as its inability to treat

multiple views and controller types elegantly, makes it less than ideal for

user interfaces in mobile applications

. Let us continue our search through

existing techniques by looking at a similar design pattern, also exposed by

the “Gang of Five” called  PAC.

38

Presentation-Abstraction-Control

Presentation-Abstraction-Control (PAC) is an object-oriented design pattern

that separates the concerns of a system by breaking it down into loosely

coupled agents, each responsible for one task (see Figure 6.2). The

Presentation-PAC architectural pattern defines a structure for interactive

software systems in the form of a hierarchy of cooperating agents .

Every agent internally has components that serve one of three tasks: those

components that abstract away the core functionality and data used by the

agent (abstraction), those components that provide access to the agent

(presentation), and those components that control the interactions between

the abstraction and presentation layers (control). Note that the PAC pattern

is similar to the MVC pattern in that it hides the internal implementation of

the logical functions of the system from the user interface (i.e., the

abstraction layer hides the business logic).

39

Transformation-Based Techniques for Mobile

Applications

The first attempts at building mobile user interfaces has been to transfer

today’s HTML-driven Web model to handheld mobile devices  The goal of

such markup languages is to take a subset of functionality of HTML. This has

two benefits:

1. Only a subset is needed for devices with limited capabilities, bandwidth,

power supply, etc. and

2. having a subset enables us to have a simpler and smaller browser that

uses less of these scarce resources. Because Web content is mostly in HTML,

this means that HTML has to be transformed to the markup language

supported by the target device. But because there are a variety of devices

and slightly different implementations and variations of the markup

languages, developers were left with a significant problem: how to automate

the task of publishing to these various user interfaces.

40

Developers began using two techniques to complement both PAC and MVC:

1. 

Transcoding

: If the content is initially in HTML, we are dealing with a “view” of the

existing system. Transcoding techniques focus on extracting the information out of

this view to create an intermediate format that can in turn be used to produce other

views. The process of creating this intermediate format is referred to as

“transcoding.” Prior to use in the moble context, the term transcoding typically meant

conversion of one compressed format to another. And, as in the case of conversion of

one compressed format to another, there is almost always some loss of data in

conversion of HTML (or another markup language) into the intermediate format. The

intermediate format is used like a generic user interface and then transformed to the

various views using XSL or a similar technology.

2. 

Transforming

: Although we can start with HTML (or some other presentational

view of the system) and convert to other views of the system, this is a solution that

should be done only as a last measure. The preferred situation is that all content is

initially produced in XML that gives a presentation-neutral view of the system. This

content can then be transformed to the appropriate views using XSL or similar

technologies.

41

Developers began using two techniques to complement both PAC and MVC

There are two main differences between transcoding and transforming. First,

in transcoding, we are starting out with some final (specialized) content, not

raw (generic) content. Second, transcoding is typically lossy and needs

special instructions whereas transforming is not lossy and should not need

special instructions (other than the transformation). Both transcoding and

transforming are complementary to MVCand PAC. Figure 6.4 shows how the

content produced by a system using PAC is transcoded and transformed to

other forms of content for access by multiple user interfaces.

42

Developers began using two techniques to complement both PAC and MVC

43

VUIs and Mobile

Applications

As their name indicates, voice user interfaces (VUIs) are

interfaces that allow users to interact with computing systems

through use of voice. Although our voice can be used in

different ways, VUIs typically refer to communication through

the use of language. This narrows down the problem at hand as

communication through VUIs is a subset of communicating

through aural user interfaces. 

It is possible to communicate with

computers through sounds other than pronounced words and

sentences. Different sounds can be used to communicate

information through their frequency, amplitude, duration, and

other properties that make them unique

. However, language is

how we naturally communicate, be it through voice or text;

therefore, when referring to VUIs, we refer to communicating

with machines using pronounced language.

VUIs and Mobile

Applications

The qualities of speech are those things that differentiate

speech from other types of aural input. To build good VUIs, a

general understanding of the physical qualities of speech not

only give us a better high-level insight into the operation of

voice recognition engines but also leads us toward building

better VUIs. So, let us take a survey of what these qualities of

speech are.

VOICE RECOGNITION

Unlike voice transcription, voice recognition has not been so illusive

in achieving. 

Voice recognition allows the recognition of a word, a

phrase, a sentence, or multiple sentences pronounced by voice

against a finite set possible matches

. In other words, the computing

system tries to match something said by the user to a given set of

possibilities that it already understands. For example, telephone

companies have used this technology for years in their directory

systems asking the user to “Please say one to reach Bob and two to

reach Phil

.” If the user says “three,” the system cannot find a match

and tells the user “That’s not a valid option; please say one to reach

Bob and two to reach Phil.” Though the term 

voice recognition 

is

often used as an encompassing definition of voice transcription and

voice recognition, in this text, we will use it to recognize the so-called

command-and-control type of recognition. Some major distinctions

between voice transcription and voice recognition, as defined in this

text, are the following:

VOICE RECOGNITION

1. Directed Dialogue: As the term suggests, this is the case when

every response by the user is preceded by a list of acceptable

responses as well as an explanation of them. An example of such a

dialogue is shown in Figure 7.2. As you see in this example, the

dialogue is directed by the system. The analog of this type of dialog in

the GUI world would be an interface entirely comprised of list boxes

that are bound to predetermined selections.

2 

Natural Language: The ultimate goal of voice recognition is to be

able to have the computing system understand the commands that

you give it even if things are paraphrased or are put into the wrong

order. Figure 7.3 is an example of a natural language interaction,

taking place between a user and the computing system. As you can

see in this example, although the system can only understand

sentences and words that concern turning on and off lights or

adjusting the temperature in the house, the user is able to put those

words and sentences in any order desired

VOICE RECOGNITION

System: “Welcome home Bob. How was your day? Can I help you tonight?”

Bob: “Yeah. Turn on the lights in the garage, will you?” System: “Lights are already

on in the garage Bob. Is there anything else I can do for you?”

Bob: “Can you warm up the dinner please?”

System: “I’m sorry Bob, I only understand tasks related to lighting and temperature.

You’ll have to upgrade me to help you with the other household  controls?”

Bob: “Ok, well, turn on the lights in the kitchen and go into quiet mode.”

System: “Thank you Bob. Lights are now on in the kitchen. Just say ‘Genie’ if

you need me.”

FIGURE 7.3. Natural Language.

VOICE RECOGNITION

3. Mixed-Mode Dialogues: Mixed-mode dialogs are often referred to

as mixedinitiative or natural language as well (though this second is a

bit of a misnomer as mixed-mode dialogues are not as flexible as

natural language dialogues). 

Mixed-mode dialogues allow natural

language interactions while directing the user so as to contain the

possible responses to a given question to a minimum. Figure 7.4

shows an example of a mixed-mode dialog between our fictitious

system and Bob. Note that although the system drives the

conversation taking place with the user and tries to limit the

expected responses from the user, it understands the user’s natural

language response.

System: “Welcome home Bob. How was your day? Can I turn on any

lights or

adjust the temperature for you tonight?”

Bob: “Yeah. Could you turn on the lights please?”

System: “Where would you like to turn on the lights Bob? Your

bedroom, the

bathroom, the kitchen, or the garage?”

Bob: “My Bedroom and the bathroom lights please?”

System: “Ok Bob. Those lights are now on.”

Bob: “Great. You can go into quiet mode now.”

FIGURE 7.4. Mixed-Initiative Dialogs.

Java Speech APIs

As in the case of other APIs, the Java platform offers a canonical API,

agreed upon by the various vendors of speech-related software.

JSAPI, or Java Speech APIs, is this canonical API. Although this API is

no different than any other API, considering it has two benefits.

 First,

because it has been agreed on by more than one commercial entity,

there is less bias in it toward any particular platform implementation.

Second, it gives us a good high-level view of what any API may

implement in providing access to the underlying technologies for a

VUI.  There are three main packages in JSAPI:

Java Speech APIs

1. javax.speech: This package provides the infrastructure to connect

to the voice channels for input and output and to manage dictionary

vocabularies dynamically. It also provides the interfaces that are later

used by the other two packages  in JSAPI.

2. javax.speech.synthesis: As its name may suggest, this package

provides an API suitable for providing an interface to speech-

synthesis systems. This package provides the utilities to adjust the

different values for the quality of speech provided by the speech-

synthesis engine for tighter control of the synthesis. It also provides

JSML hooks into the system so that the synthesis can be done based

on JSML.

3. javax.speech.recognition: This package provides the interfaces for

managing grammars, rules, recognition results, and the settings of

the recognition engine. As may be suspected, it takes advantage of

JSGF,

VXML

VXML has its roots in efforts by Motorola, AT&T, and a group of other

companies. The goal was to create a model similar to the thin-client

GUI Web browsers such as Mosaic, Netscape Navigator, or MS

Internet Explorer. As various markup language were suggested by

different groups, it became apparent that a standard language was

needed and this is when various commercial entities, under the

direction of W3C, began to develop VXML

. VXML version 2.0 is the

latest ratified version of VXML. Before we go into the syntactical

aspects of VXML, let us take a step back and see what VXML is and

what it is not:

VXML

1.

VXML is normally not consumable by the end telephony device.

Perhaps the biggest misconception about VXML is that, like

HTML, it is consumed by a browser that runs on a device that is in

control of the user.

2.

SALT and VXML are not equivalent in functionality, architecture,

or any other aspects.  SALT and VXML are largely competing

technologies. VXML has been  designed to ful fill the voice

recognition piece of the puzzle in a larger architectural  design

along with a series of other standards such as CCML, SSML, SMIL,

and others.

3.

Whether VXML can be used on a project depends on whether the

voice recognition platform offers a VXML-compliant browse.

VXML simply offers us an easier method of specifying the states

and navigation methods between the different states of a VUI.We

still need the voice recognition engine and an API to accessi ts

functionality.

VXML

4. VXML can be static or dynamically generated. Just like HTML, we

can have static VXML documents, generate the VXML in batches, or

we can generate the documents at run time based on a set of rules.

VXML has the following set of goals:

1. To provide a simple mechanism to build VUIs.

2. To separate the concerns of business logic from the concerns of building VUIs.

3. To provide a language that is portable across multiple voice recognition

platforms.

4. To enable one VXML document to hold multiple voice interactions. This lessens

the number of interactions between the application running on the voice platform

and applications, databases, or other interfaces providing the business  logic

necessary to generate the VXML document.

5. To offer a small but sufficient set of features for basic telephony call control  and

text-to-speech interactions. Although the functionality through VXML for  these

functions are sufficient for smaller efforts, it is recommended that more

comprehensive efforts, particularly for mobile applications, defer telephony

control to CCPP and text-to-speech generation to SSML.

Using VXML for Mobile Applications

Though there is a great deal of effort today to implement embedded voice

recognition systems onto mobile devices, resource-starved devices do not lend

themselves to voice browsing technologies. So, when it comes to using VXML for

mobile applications, we are primarily referring to the server-side interpretation of

the VXML document.

VXML can be produced from existing GUIs using transcoding mechanisms that

convert another user interface markup language to VXML, using XSLs or other

technologies. In theory, the primary advantage of using VXML in this manner is to

reduce the necessary development, create consistency among different interfaces,

and to reduce the cost of changes and maintenance during the lifetime of an

application. In practice, things do not quite work that way because of a number

of factors. Some of these are as follows:

Using VXML for Mobile Applications

1. There is a large performance cost in using VXML on the server side.

Consequently, many commercial applications that have moved from the traditional

IVR model of building on top of vendor-specific APIs suffer some performance

loss. This problem can typically be easily solved by increasing CPU and memory.

Because CPU and memory are now mostly inexpensive commodities, the problem

is not significant. Nevertheless, it is important to be aware of the performance

loss when moving from a legacy VUI to a VXML-based VUI.

2. 

Because VXML has been designed as a browser that utilizes ECMAScript to

reduce traffic with the other applications, it is stateful. And because it is stateful,

the task of transforming a generic interface to VXML can be a fairly complicated

one.

Using VXML for Mobile Applications

3. Generating VXML with typical server-side technologies such as JSP or ASP

has the drawback of increasing network traffic although it has the advantage

of allowing us to apply the same techniques used for generating HTML-based

Web pages to generate VXML pages.

4.

 Automated conversion mechanisms that consume HTML or XHTML to produce

VXML are typically flawed. Whereas the same technologies do a fair job

with text and GUIs, VUIs are much more sensitive to errors. One wrong or

poorly designed interaction with the user will turn the user off from using the

system. The key with VUIs is that the user interface must be as close to perfect

as possible. Users are simply not as patient with VUIs as they are with

GUIs.