Introduction to Mobile Computing Principles and Designing Mobile Applications

MOBILE COMPUTING PRINCIPLES
DESIGNING AND DEVELOPING
MOBILE APPLICATIONS WITH
UML AND XML
REZA B’FAR
1
Introduction to Mobile Computing
 
1.1 Introduction
1.2 Added Dimensions of Mobile Computing
1.3 Condition of the Mobile
1.4 Architecture of Mobile Software
Applications
Android Development- the basics
2
Introduction
 
Mobile computing systems are computing systems that may be
easily moved physically and whose computing capabilities may be
used while they are being moved. Examples are laptops, personal
digital assistants (PDAs), and mobile phones
.
Among the distinguishing aspects of mobile computing
systems are their prevalent wireless network connectivity,
their small size, the mobile nature of their use, their power
sources, and their functionalities that are particularly suited
to the mobile user
. 
Because of these features, mobile
computing applications are inherently different than
applications written for use on stationary computing systems
.
3
Introduction
     
Abacus    ……………… 500 B.C.
     Electricity ………….……1800's
      First Computers…..…. Mid  1900's
     Networking   ……………1960 – 1970
     Satellites……………………1970 –  1980
      Cellular Technologies…1980 – 2000
In the next section , we will look at those things that
make the functional nature of  mobile applications
different than their stationary counterparts, take a
survey of  various development techniques that can be
used to address these differences
, 
and look at various
basic technologies that allow us, as software developers,
to create meaningful mobile applications in an
extensible, flexible, and scalable manner
.
4
Introduction
 
Because the greatest advances in mobile
communications originated in the military,  it is no
surprise that one of the first applications of wireless
communication  for mobile computing systems was in
displaying terrain maps of the battlefield.  
From this,
the 
global positioning system (GPS) 
evolved so that
soldiers could  know their locations at any given time.
Portable military computers were provided  to
provide calculations, graphics, and other data in the
field of battle
. 
In recent  years, wireless telephony
has become the major provider of a revenue stream
that  is being invested into improving the
infrastructure to support higher bandwidth  data
communications.
5
Wireless Mobile
  
Recently, computer networks have evolved by leaps and
bounds. These networks   have begun to fundamentally
change the way we live. Today, it is difficult  to imagine
computing without network connectivity. 
Networking and
distributed  computing are two of the largest segments that
are the focus of current efforts in computing. Networks and
computing devices are becoming increasingly blended
together
. 
Most mobile computing systems today, through
wired or wireless connections,  can connect to the network.
. Because of the nature of mobile computing  systems,
network connectivity of mobile systems is increasingly
through wireless  communication systems rather than
wired ones
. 
And this is quickly becoming somewhat of a
nonmandatory distinguishing element between mobile and
stationary  systems
.
6
Wireless Mobile
 
There are four pieces to the mobile problem: the
mobile user, the mobile device, the mobile
application, and the mobile network. 
We will
distinguish the mobile user from the stationary user
by what we will call the mobile condition The set of
properties that distinguishes the mobile user from
the user of a typical, stationary computing system
.
We will wrap the differences between typical devices,
applications, and networks with mobile devices,
applications, and networks into a set of properties
that we will call the 
dimensions of mobility
: 
the set of
properties
  
that distinguishes the mobile computing
system from the stationary computing
  
system
.
7
ADDED DIMENSIONS OF MOBILE COMPUTING
   
The dimensions of  mobility (Figure 1.3) are as
follows:
 
1.  location awareness,
2. network connectivity quality of service (QOS),
 3. limited device capabilities (particularly storage
and CPU),
  4. limited power supply,
  5. support for a wide variety of user interfaces,
  6. platform proliferation, and
  7. active transactions
8
ADDED DIMENSIONS OF MOBILE COMPUTING
9
 Location
   
Location : 
There are two general categories: localization
and location sensitivity.
Localization
 
is the mere ability of the architecture of the
mobile application to accommodate logic that allows the
selection of different business logic, level of work flow, and
interfaces based on a given set of location  information
commonly referred to as locales. Localization is not exclusive
to mobile applications but takes a much more prominent role
in mobile applications
. 
Localization is often required in
stationary applications where users at different geographical
locations access a centralized system. 
For example, some
point-of-sale (POS) systems 
and e-commerce Web sites are
able to take into account the different taxation rules
depending on the locale of the sale and the location of the
purchase. Whereas localization is something that stationary
applications can have, location sensitivity s something fairly
exclusive to mobile applications.
10
 Location
11
 Location
12
The most well known location sensing system today is
GPS. GPS-enabled devices  can obtain latitude and
longitude with accuracy of about 1–5 m. GPS has its roots
in the military; until recently, the military placed
restrictions on the accuracy of GPS available for public
use. Most of these restrictions have now been lifted.
GPS devices use triangulation techniques by triangulating
data points from the satellite constellation that covers the
entire surface of the earth. If a device does  not have GPS
capabilities but uses a cellular network for wireless
connectivity, 
signal strength and triangulation or other
methods can be used to come up with some approximate
location information, depending on the cellular network.
 Location
13
The most well known location sensing system today is
GPS. GPS-enabled devices  can obtain latitude and
longitude with accuracy of about 1–5 m. GPS has its roots
in the military; until recently, the military placed
restrictions on the accuracy of GPS available for public
use. Most of these restrictions have now been lifted.
GPS devices use triangulation techniques by triangulating
data points from the satellite constellation that covers the
entire surface of the earth. If a device does  not have GPS
capabilities but uses a cellular network for wireless
connectivity, 
signal strength and triangulation or other
methods can be used to come up with some approximate
location information, depending on the cellular network.
Quality of Service
14
Whether wired or wireless connectivity is used, mobility
means loss of network connectivity reliability. Moving from
one physical location to another creates physical barriers that
nearly guarantee some disconnected time from the network.
If a mobile application is used on a wired mobile system, the
mobile system must be disconnected between the times
when it is connected to the wired docking ports  to be moved
.
Of course, it is always a question whether a docking port is
available when required let alone the quality and type of the
available network connectivity  at that docking port. In the
case of wireless network  connectivity, physical conditions can
significantly affect the 
quality of service (QOS). 
For example,
bad weather, solar flares, and a variety of other climate-
related conditions can negatively  affect the (QOS).
Quality of Service
15
When it comes to taking into account the QOS in most
applications, certain functionality is expected of most
mobile applications. For example, almost all mobile
applications should know how to stop working when
the application suddenly disconnects from the network
and then resume working when it connects again.
Other functionality may be desired but not required.
For example, often QOS data are measured and
provided by the network operator. For example, the
real-time  bandwidth available may be part of the data
provided and refreshed on some time interval. Such
data can be utilized to design applications that
dynamically adapt  their features and functionality to
the available bandwidth.
Limited Device Storage and CPU
16
No one wants to carry around a large device, so most useful
mobile devices are  small. This physical size limitation imposes
boundaries on volatile storage, nonvolatile  storage, and CPU on
mobile devices
. 
Though solid-state engineers are working on
putting more and more processing power and storage into smaller
and smaller physical volumes, nevertheless, as most mobile
applications today are  very rudimentary, there will be more and
more that we will want to do with them.
Today’s mobile applications are resource-starved. So, although the
designers of  modern applications designed to run on personal
computers (PCs) and servers  continue to care less and less about
system resources such as memory and processing  power, it is a
sure bet that memory limitations will be around for a long time for
mobile applications because when it comes to mobile systems and
devices,  smaller is nearly always better
Limited Device Storage and CPU
17
Limitations of storage and CPU of mobile devices put yet another
constraint on how we develop mobile applications. For example, a
mobile calendaring application may store some of its data on
another node on the network (a PC, server, etc.). The contacts
stored on the device may be available at any time. However,
the contact information that exists only on the network is not
available while the device is disconnected from the network
.
 But,
because the amount of data that can be stored on each type of
device varies depending on the device type, it is not possible to
allocate this storage space statically. 
Also, some information may
be used more frequently than others; for example, the two weeks
surrounding the current time may be accessed more frequently in
the calendar application or there may be some contacts that are
used more frequently. Mobile applications must be designed to
optimize the use of data storage and processing power of the
device  in terms of the application use by the user
.
Limited Power Supply
18
We have already seen that the size constraints of the devices limit
their storage capabilities and that their physical mobility affects
network connectivity. For the same set of reasons that wireless is
the predominant method of network connectivity for mobile
devices, batteries are the primary power source for mobile
devices. 
Batteries are improving every day and it is tough to find
environments where suitable AC power is not available. Yet, often
the user is constantly moving and devices are consuming more and
more power with processors that have more and more transistors
packed into them. 
The desirability of using batteries instead of an
AC power source combined with the size constraints creates yet
another constraint, namely a limited power supply. This constraint
must be balanced with the processing power, storage, and size
constraints; the battery is typically the largest single source of
weight in the mobile. 
The power supply has a direct or an indirect
effect on everything in a mobile device 
.
Extra DIMENSIONS OF MOBILE COMPUTING
19
Varying User Interfaces
: Stationary users use nonmobile
applications while working on a PC or a similar device. The
keyboard, mouse, and monitor have proved to be fairly efficient
user interfaces for such applications. This is not at all true for
mobile applications.
Platform Proliferation
: Because mobile devices are small and there
is much less hardware in them than in a PC, they are typically less
costly to assemble for a manufacturer. This means that more
manufacturers can compete in producing these devices.
Active Transactions
: Most of today’s stationary applications have a
restriction that can reduce the benefits of a mobile application
system enormously: The user of the system must initiate all
interactions with the system. We call such systems passive systems
because they are in a passive state, waiting for some external
signal from the user to tell them to start doing some particular
thing.
ARCHITECTURE OF MOBILE SOFTWARE APPLICATIONS
20
The first step in building a software application, after the
process of gathering requirements, is to lay down a high-
level plan of what the application will be like when it is
finished. 
Mobile applications, like any other software
application, require such a high-level plan . We call this
high-level plan of the mobile application a “mobile
software architecture
.” Our approach to architecture in
this text will be bottom up: we will introduce a variety of
design patterns, application architectures, and processes
with each addressing some specific problem with mobile
applications (next Figure).
21
CHAPTER 2 
Introduction to Mobile
Development Frameworks
and Tools
At its most primitive level, software is a set of instructions
for hardware written in machine language. At a higher
level, there are assemblers and higher level programming
languages. There are frameworks, tools, and other methods
of abstracting various aspects of software design that help
us achieve one central goal
: 
to handle complexity of
software more reliability and faster. The biggest problem
with software design and implementation is complexity
and it is this complexity that leads into buggy systems, high
cost of development, and long development cycles, and the
existence of programming languages, frameworks, and
other development  tools is primarily to solve this very
problem of software complexity
. 
In  other words, as one of
the most fundamental software design concepts,
abstraction  reduces complexity (at least theoretically).
22
Introduction to Mobile
Development
Frameworks and tools for mobile application development
are evolving based on the growth of architectural
techniques and innovations that accommodate the
dimensions of mobility. 
Although the purpose of any
significant tool and framework used in mobile application
development should be to reduce the complexity of the
mobile application, all tools, regardless of their
implementations, attempt to address the same issues.
However, depending on the architectures that each may
support, their implementation and usage significantly vary.
Therefore, it makes sense to create the taxonomy of these
tools based on the architectures. Let us begin by looking at
the frameworks and tools that address mobile application
development in a fully centralized architecture.
23
FULLY CENTRALIZED FRAMEWORKS AND TOOLS
Developing fully centralized mobile applications differs from other fully
centralized  applications by virtue of QOS, limited power supply, active
transactions, and location awareness Fully centralized mobile
applications typically have custom-designed clients to perform specific
tasks. So, the user interface on the devices used to access the centralized
system is optimized to the task being performed
. The software on such
devices is typically embedded in nature and is designed to do only one
thing. Also, because of this embedded nature of fully centralized mobile
systems, resources of the device are not a concern in software
development
: The abilities of the client are known beforehand. Platform
proliferation, once again for the same reason, is not a concern: Software
systems in fully centralized mobile systems are all about the software on
the fully centralized host; the client devices are dumb with little or no
ability to perform dynamic computing tasks and what little software
exists on them is embedded
. 
Therefore, three of the dimensions of
mobility—namely platform proliferation, limited device capabilities, and
support for a variety of user interfaces—do not apply to fully centralized
applications
24
N-TIER CLIENT–SERVER FRAMEWORKS AND TOOLS
As we discussed in Chapter 1, client–server architectures
allow us to enable communication between two
applications with one application acting as the server and
the other acting as the client. For mobile applications, the
server may have special needs, but it is typically powerful
enough to run a wide range of applications. 
For mobile
applications, there may be special logic that treats the
dimensions of mobility. Client applications, in the case of
mobile development, are typically those being run on
mobile devices. Writing large applications for the devices to
serve as the client is typically not possible, primarily
because of the limited resources on the devices and the
large variety of them. 
So, more often than not, mobile
applications are distributed. The state of the art, as of the
date of authoring this text, in proven distributed computing
systems are the N-tier client–server architectures.
25
N-TIER CLIENT–SERVER FRAMEWORKS AND TOOLS
One of basic problems of application development that is
magnified in mobile environments is code portability and
mobility. The varieties of the so-called platforms (combination
of hardware and operating systems) have prompted the creation
of tools and frameworks such as Sun’s Java Virtual Machine and
Microsoft’s Common Language Run-time. 
The primary goal of
these tools is to give code more portability across platforms. The
problem is magnified when considering the added factors that
the variety of mobile devices dwarfs the variety among PC and
server operating systems, that virtual machines tend to be large
and require lots of memory and CPU cycles, and that, once
more,
 they are designed primarily with the primary task of
designing applications for stationary computing systems. Here,
there are two factors that are inherently opposite in nature.
First, we need a layer of software, be it a virtual machine or
otherwise, that abstracts us away from the specificity of
hardware.
26
Mobile Operating Systems and Virtual Machines
Although Java tries to solve the proliferation problem by making
the code portable between different platforms, there are other
plausible approaches. One of these approaches is to create tools
that make the applications native to one platform. Microsoft’s
.NET framework deploys such a strategy. The tools provided by
the .NET framework allow the programmer to develop the
application in a variety of languages supported by the
framework
. The individual applications are then compiled to
code that can be executed on the same platform. Microsoft’s
creation of the .NET platform is spurred by economic reasons,
namely to keep Windows as the dominant computer operating
system. However, this does not imply that the tools provided by
the .NET framework are either superior or inferior
.
 It is simply
a different technical approach whose merit should be judged by
the implementing developers and the users of applications that
use this platform.
27
Hardware-Specific Tools and Frameworks
One way to deal with device proliferation is to avoid it!
Device manufacturers can allow the application
programmers to develop code that directly takes advantage
of the device features and functionality. The notion of an
operating system, in such case, is much different than what
we typically think of as an operating system
. The services
offered by the operating system are few and very low level.
The downside here is a tight coupling to a platform that, in
turn, can translate to heavy reliance on the manufacturer
of that platform. This is the approach that Qualcomm offers
in its BREW platform. BREW is a framework designed to
allow application developers program applications for
devices based on Qualcomm’s CDMA technology.We will
look at CDMAfurther in Chapter 9
. 
It is a physical layer
communication protocol that offers very efficient use of the
bandwidth available in a segment of the spectrum.
28
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.
29
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.
30
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).
31
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.
32
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
.
33
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.
34
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
.
35
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.
36
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.
37
 
38
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.
39
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.
40
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
41
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.
42
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.
43
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
.
44
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
.
45
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
)
.
46
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
.
47
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.
48
 
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.
49
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.
50
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.
51
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.
52
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.
53
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.
54
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.
55
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.
56
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
.
57
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.
58
59
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
60
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).
61
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.
62
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.
63
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).
64
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.
65
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.
66
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).
67
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.
68
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.
69
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.
70
Developers began using two techniques to complement both PAC and MVC
 
71
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
72
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).
73
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.
74
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.
75
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).
76
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.
77
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.
78
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).
79
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.
80
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.
81
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.
82
Developers began using two techniques to complement both PAC and MVC
 
83
VUIs and Mobile
Applications  …Chapter 7
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.
84
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.
85
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:
86
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
87
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.
88
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.
89
 
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.
90
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:
91
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,
92
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:
93
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.
94
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.
95
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:
96
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.
97
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.
98
Slide Note
Embed
Share

Mobile computing systems involve computing capabilities that can be utilized while on the move, leveraging wireless connectivity, small size, and mobile-specific functionalities. The history of mobile computing traces back to military origins and has evolved with technologies like GPS and wireless telephony. The advancements in networks have transformed the way we interact with computing devices. This field presents unique opportunities and challenges for software developers aiming to create innovative mobile applications.


Uploaded on Sep 22, 2024 | 0 Views


Download Presentation

Please find below an Image/Link to download the presentation.

The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.

E N D

Presentation Transcript


  1. MOBILE COMPUTING PRINCIPLES DESIGNING AND DEVELOPING MOBILE APPLICATIONS WITH UML AND XML REZA B FAR 1

  2. Introduction to Mobile Computing 1.1 Introduction 1.2 Added Dimensions of Mobile Computing 1.3 Condition of the Mobile 1.4 Architecture of Mobile Software Applications Android Development- the basics 2

  3. Introduction Mobile computing systems are computing systems that may be easily moved physically and whose computing capabilities may be used while they are being moved. Examples are laptops, personal digital assistants (PDAs), and mobile phones. Among the distinguishing aspects of mobile computing systems are their prevalent wireless network connectivity, their small size, the mobile nature of their use, their power sources, and their functionalities that are particularly suited to the mobile user. Because of these features, mobile computing applications are inherently different than applications written for use on stationary computing systems. 3

  4. Introduction Abacus 500 B.C. Electricity . 1800's First Computers .. . Mid 1900's Networking 1960 1970 Satellites 1970 1980 Cellular Technologies 1980 2000 In the next section , we will look at those things that make the functional nature of mobile applications different than their stationary counterparts, take a survey of various development techniques that can be used to address these differences, and look at various basic technologies that allow us, as software developers, to create meaningful mobile applications in an extensible, flexible, and scalable manner. 4

  5. Introduction greatest Because communications originated in the military, it is no surprise that one of the first applications of wireless communication for mobile computing systems was in displaying terrain maps of the battlefield. From this, the global positioning system (GPS) evolved so that soldiers could know their locations at any given time. Portable military computers were provided to provide calculations, graphics, and other data in the field of battle. In recent years, wireless telephony has become the major provider of a revenue stream that is being invested into improving the infrastructure to support higher bandwidth data communications. the advances in mobile 5

  6. Wireless Mobile Recently, computer networks have evolved by leaps and bounds. These networks have begun to fundamentally change the way we live. Today, it is difficult to imagine computing without network connectivity. Networking and distributed computing are two of the largest segments that are the focus of current efforts in computing. Networks and computing devices are becoming increasingly blended together. Most mobile computing systems today, through wired or wireless connections, can connect to the network. . Because of the nature of mobile computing systems, network connectivity of mobile systems is increasingly through wireless communication systems rather than wired ones. And this is quickly becoming somewhat of a nonmandatory distinguishing element between mobile and stationary systems. 6

  7. Wireless Mobile There are four pieces to the mobile problem: the mobile user, the mobile device, the mobile application, and the mobile network. We will distinguish the mobile user from the stationary user by what we will call the mobile condition The set of properties that distinguishes the mobile user from the user of a typical, stationary computing system. We will wrap the differences between typical devices, applications, and networks with mobile devices, applications, and networks into a set of properties that we will call the dimensions of mobility: the set of propertiesthat distinguishes the mobile computing system from the stationary computingsystem. 7

  8. ADDED DIMENSIONS OF MOBILE COMPUTING The dimensions of mobility (Figure 1.3) are as follows: 1. location awareness, 2. network connectivity quality of service (QOS), 3. limited device capabilities (particularly storage and CPU), 4. limited power supply, 5. support for a wide variety of user interfaces, 6. platform proliferation, and 7. active transactions 8

  9. ADDED DIMENSIONS OF MOBILE COMPUTING 9

  10. Location Location : There are two general categories: localization and location sensitivity. Localizationis the mere ability of the architecture of the mobile application to accommodate logic that allows the selection of different business logic, level of work flow, and interfaces based on a given set of location information commonly referred to as locales. Localization is not exclusive to mobile applications but takes a much more prominent role in mobile applications. Localization is often required in stationary applications where users at different geographical locations access a centralized system. For example, some point-of-sale (POS) systems and e-commerce Web sites are able to take into account the different taxation rules depending on the locale of the sale and the location of the purchase. Whereas localization is something that stationary applications can have, location sensitivity s something fairly exclusive to mobile applications. 10

  11. Location 11

  12. Location The most well known location sensing system today is GPS. GPS-enabled devices can obtain latitude and longitude with accuracy of about 1 5 m. GPS has its roots in the military; until recently, the military placed restrictions on the accuracy of GPS available for public use. Most of these restrictions have now been lifted. GPS devices use triangulation techniques by triangulating data points from the satellite constellation that covers the entire surface of the earth. If a device does not have GPS capabilities but uses a cellular network for wireless connectivity, signal strength and triangulation or other methods can be used to come up with some approximate location information, depending on the cellular network. 12

  13. Location The most well known location sensing system today is GPS. GPS-enabled devices can obtain latitude and longitude with accuracy of about 1 5 m. GPS has its roots in the military; until recently, the military placed restrictions on the accuracy of GPS available for public use. Most of these restrictions have now been lifted. GPS devices use triangulation techniques by triangulating data points from the satellite constellation that covers the entire surface of the earth. If a device does not have GPS capabilities but uses a cellular network for wireless connectivity, signal strength and triangulation or other methods can be used to come up with some approximate location information, depending on the cellular network. 13

  14. Quality of Service Whether wired or wireless connectivity is used, mobility means loss of network connectivity reliability. Moving from one physical location to another creates physical barriers that nearly guarantee some disconnected time from the network. If a mobile application is used on a wired mobile system, the mobile system must be disconnected between the times when it is connected to the wired docking ports to be moved. Of course, it is always a question whether a docking port is available when required let alone the quality and type of the available network connectivity at that docking port. In the case of wireless network connectivity, physical conditions can significantly affect the quality of service (QOS). For example, bad weather, solar flares, and a variety of other climate- related conditions can negatively affect the (QOS). 14

  15. Quality of Service When it comes to taking into account the QOS in most applications, certain functionality is expected of most mobile applications. For example, almost all mobile applications should know how to stop working when the application suddenly disconnects from the network and then resume working when it connects again. Other functionality may be desired but not required. For example, often QOS data are measured and provided by the network operator. For example, the real-time bandwidth available may be part of the data provided and refreshed on some time interval. Such data can be utilized to design applications that dynamically adapt their features and functionality to the available bandwidth. 15

  16. Limited Device Storage and CPU No one wants to carry around a large device, so most useful mobile devices are small. This physical size limitation imposes boundaries on volatile storage, nonvolatile storage, and CPU on mobile devices. Though solid-state engineers are working on putting more and more processing power and storage into smaller and smaller physical volumes, nevertheless, as most mobile applications today are very rudimentary, there will be more and more that we will want to do with them. Today s mobile applications are resource-starved. So, although the designers of modern applications designed to run on personal computers (PCs) and servers continue to care less and less about system resources such as memory and processing power, it is a sure bet that memory limitations will be around for a long time for mobile applications because when it comes to mobile systems and devices, smaller is nearly always better 16

  17. Limited Device Storage and CPU Limitations of storage and CPU of mobile devices put yet another constraint on how we develop mobile applications. For example, a mobile calendaring application may store some of its data on another node on the network (a PC, server, etc.). The contacts stored on the device may be available at any time. However, the contact information that exists only on the network is not available while the device is disconnected from the network. But, because the amount of data that can be stored on each type of device varies depending on the device type, it is not possible to allocate this storage space statically. Also, some information may be used more frequently than others; for example, the two weeks surrounding the current time may be accessed more frequently in the calendar application or there may be some contacts that are used more frequently. Mobile applications must be designed to optimize the use of data storage and processing power of the device in terms of the application use by the user. 17

  18. Limited Power Supply We have already seen that the size constraints of the devices limit their storage capabilities and that their physical mobility affects network connectivity. For the same set of reasons that wireless is the predominant method of network connectivity for mobile devices, batteries are the primary power source for mobile devices. Batteries are improving every day and it is tough to find environments where suitable AC power is not available. Yet, often the user is constantly moving and devices are consuming more and more power with processors that have more and more transistors packed into them. The desirability of using batteries instead of an AC power source combined with the size constraints creates yet another constraint, namely a limited power supply. This constraint must be balanced with the processing power, storage, and size constraints; the battery is typically the largest single source of weight in the mobile. The power supply has a direct or an indirect effect on everything in a mobile device . 18

  19. Extra DIMENSIONS OF MOBILE COMPUTING Varying User Interfaces: Stationary users use nonmobile applications while working on a PC or a similar device. The keyboard, mouse, and monitor have proved to be fairly efficient user interfaces for such applications. This is not at all true for mobile applications. Platform Proliferation: Because mobile devices are small and there is much less hardware in them than in a PC, they are typically less costly to assemble for a manufacturer. This means that more manufacturers can compete in producing these devices. Active Transactions: Most of today s stationary applications have a restriction that can reduce the benefits of a mobile application system enormously: The user of the system must initiate all interactions with the system. We call such systems passive systems because they are in a passive state, waiting for some external signal from the user to tell them to start doing some particular thing. 19

  20. ARCHITECTURE OF MOBILE SOFTWARE APPLICATIONS The first step in building a software application, after the process of gathering requirements, is to lay down a high- level plan of what the application will be like when it is finished. Mobile applications, like any other software application, require such a high-level plan . We call this high-level plan of the mobile application a mobile software architecture. Our approach to architecture in this text will be bottom up: we will introduce a variety of design patterns, application architectures, and processes with each addressing some specific problem with mobile applications (next Figure). 20

  21. 21

  22. CHAPTER 2 Introduction to Mobile Development Frameworks and Tools At its most primitive level, software is a set of instructions for hardware written in machine language. At a higher level, there are assemblers and higher level programming languages. There are frameworks, tools, and other methods of abstracting various aspects of software design that help us achieve one central goal: to handle complexity of software more reliability and faster. The biggest problem with software design and implementation is complexity and it is this complexity that leads into buggy systems, high cost of development, and long development cycles, and the existence of programming languages, frameworks, and other development tools is primarily to solve this very problem of software complexity. In other words, as one of the most fundamental software abstraction reduces complexity (at least theoretically). design concepts, 22

  23. Introduction to Mobile Development Frameworks and tools for mobile application development are evolving based on the growth of architectural techniques and innovations that accommodate the dimensions of mobility. Although the purpose of any significant tool and framework used in mobile application development should be to reduce the complexity of the mobile application, all tools, regardless of their implementations, attempt to address the same issues. However, depending on the architectures that each may support, their implementation and usage significantly vary. Therefore, it makes sense to create the taxonomy of these tools based on the architectures. Let us begin by looking at the frameworks and tools that address mobile application development in a fully centralized architecture. 23

  24. FULLY CENTRALIZED FRAMEWORKS AND TOOLS Developing fully centralized mobile applications differs from other fully centralized applications by virtue of QOS, limited power supply, active transactions, and location awareness Fully centralized mobile applications typically have custom-designed clients to perform specific tasks. So, the user interface on the devices used to access the centralized system is optimized to the task being performed. The software on such devices is typically embedded in nature and is designed to do only one thing. Also, because of this embedded nature of fully centralized mobile systems, resources of the device are not a concern in software development: The abilities of the client are known beforehand. Platform proliferation, once again for the same reason, is not a concern: Software systems in fully centralized mobile systems are all about the software on the fully centralized host; the client devices are dumb with little or no ability to perform dynamic computing tasks and what little software exists on them is embedded. Therefore, three of the dimensions of mobility namely platform proliferation, limited device capabilities, and support for a variety of user interfaces do not apply to fully centralized applications 24

  25. N-TIER CLIENTSERVER FRAMEWORKS AND TOOLS As we discussed in Chapter 1, client server architectures allow us to enable communication between two applications with one application acting as the server and the other acting as the client. For mobile applications, the server may have special needs, but it is typically powerful enough to run a wide range of applications. For mobile applications, there may be special logic that treats the dimensions of mobility. Client applications, in the case of mobile development, are typically those being run on mobile devices. Writing large applications for the devices to serve as the client is typically not possible, primarily because of the limited resources on the devices and the large variety of them. So, more often than not, mobile applications are distributed. The state of the art, as of the date of authoring this text, in proven distributed computing systems are the N-tier client server architectures. 25

  26. N-TIER CLIENTSERVER FRAMEWORKS AND TOOLS One of basic problems of application development that is magnified in mobile environments is code portability and mobility. The varieties of the so-called platforms (combination of hardware and operating systems) have prompted the creation of tools and frameworks such as Sun s Java Virtual Machine and Microsoft s Common Language Run-time. The primary goal of these tools is to give code more portability across platforms. The problem is magnified when considering the added factors that the variety of mobile devices dwarfs the variety among PC and server operating systems, that virtual machines tend to be large and require lots of memory and CPU cycles, and that, once more, they are designed primarily with the primary task of designing applications for stationary computing systems. Here, there are two factors that are inherently opposite in nature. First, we need a layer of software, be it a virtual machine or otherwise, that abstracts us away from the specificity of hardware. 26

  27. Mobile Operating Systems and Virtual Machines Although Java tries to solve the proliferation problem by making the code portable between different platforms, there are other plausible approaches. One of these approaches is to create tools that make the applications native to one platform. Microsoft s .NET framework deploys such a strategy. The tools provided by the .NET framework allow the programmer to develop the application in a variety of languages supported by the framework. The individual applications are then compiled to code that can be executed on the same platform. Microsoft s creation of the .NET platform is spurred by economic reasons, namely to keep Windows as the dominant computer operating system. However, this does not imply that the tools provided by the .NET framework are either superior or inferior. It is simply a different technical approach whose merit should be judged by the implementing developers and the users of applications that use this platform. 27

  28. Hardware-Specific Tools and Frameworks One way to deal with device proliferation is to avoid it! Device manufacturers can programmers to develop code that directly takes advantage of the device features and functionality. The notion of an operating system, in such case, is much different than what we typically think of as an operating system. The services offered by the operating system are few and very low level. The downside here is a tight coupling to a platform that, in turn, can translate to heavy reliance on the manufacturer of that platform. This is the approach that Qualcomm offers in its BREW platform. BREW is a framework designed to allow application developers program applications for devices based on Qualcomm s CDMA technology.We will look at CDMAfurther in Chapter 9. It is a physical layer communication protocol that offers very efficient use of the bandwidth available in a segment of the spectrum. allow the application 28

  29. 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. 29

  30. 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 application is developed, it must be tested, and then deployed. Deployment of BREW applications is a process done jointly telecommunications carriers and not just the developer. Kit (SDK). Once the by Qualcomm and 30

  31. 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). 31

  32. 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. 32

  33. 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. 33

  34. 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. 34

  35. 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. 35

  36. 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. 36

  37. 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. 37

  38. 38

  39. 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. 39

  40. 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. 40

  41. SAX Parsing SAX (Simple API for XML) creates a series of events as it parses through the XML document instead of creating an object model of the entire document in memory. There are two key advantages that SAX offers over DOM: 1. Most of the time, we do not need all of the information in the document. So, the object model desired does not have to have every element and attribute of the document. A custom object model in this case is more efficient. We can write a custom object model and a driver that catches the SAX events as the SAX parser reads through the document and emits them and fills up the custom object model. 2. We do not have to wait for the entire document to be processed before using the contents of the document. For very large documents, DOM becomes problematic as it has to load the entire document into memory before it makes its contents available. In contrast, as a SAX parser progresses through processing a document, it emits events; therefore, by nature, processing of the information it allows immediate 41

  42. 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. 42

  43. 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. 43

  44. Web Services and Mobile Applications 2. Direct Connection to Web Services: Mobile devices with more resources can directly access the network through the use of Web services (see Figure 3.4). Of course, this requires a considerably advanced mobile device as we have to have very efficient XML parsing as well as the ability to write substantial applications that application of XML that supports the particular Web service to which the mobile device must connect to. implement the 44

  45. KEY XML TECHNOLOGIES FOR MOBILE COMPUTING Some standard applications of XML have been specifically designed with mobile applications in mind. Standardization of such applications of XML is required to provide interoperability between disparate systems. As we mentioned previously, mobile applications should be able to handle XML content. This may mean parsing the content to take some actions based on the content, transforming the content for various user interfaces, or using XML as the metadata for handling various types of content. There are a set of standards by W3C and proprietary recommendations by various vendors that apply for these cases. We will recommended by W3C as they are typically more encompassing than proprietary recommendations. focus on standards 45

  46. XML-Based User Interface Technologies for Mobile Applications As we previously mentioned, one of the first markup languages to be pervasively used was HTML. Most of the Web documents today exist in HTML. HTML is an application of SGML, but it is not very clean. XHTML is an attempt at cleaning up the HTML syntax and providing a version of HTML that is an application of XML. XHTML will replace HTML past version 4.01 and it is an approved W3C standard. One of the biggest problems that HTML presented was that it was not designed to be used by a wide variety of user interface types. HTML was designed with minimum requirements of a color screen of 640 480 pixels and the PC in mind. Though some considerations were made for screens that did not display graphics, not much else was available to the developer. Also, HTML was not strict enough in enforcing syntax. So, programmatic changes to HTML to make it fit various devices was not possible without making assumptions (which in turn create bugs). 46

  47. XML-Based User Interface Technologies for Mobile Applications XForms allows us to build user interfaces with a focus on the interactions and data exchanges between the user and the user interface as opposed to specific types of user interface. XForms allows us to separate concerns among presentation logic specific presentation logic specific to the device, the data exchanged between the user and the system, and the interaction flow. It is natural for XML to be the core of a user interface system infrastructure, mobile or not. XML is textual, structured, and document based. Those three elements are of utmost importance in building a human computer interface (HCI). There are other applications of XML for mobile application infrastructures as well. We will now briefly introduce some applications of XML that control flow of interactions. to the application, the 47

  48. Putting XML to Work XML has already become the de facto document standard for exchange of human readable data. Whether such will be the case for machine-to-machine communication is questionable; nevertheless, such applications exist and their popularity is increasing. In this chapter, we looked at a variety of XML-based technologies and took an introductory glimpse at their use in mobile applications. Then, we looked at RDF, a part of the Semantic Web that is becoming pervasively more crucial to mobile applications. We followed this by discussions of CC/PP and UAProf as applications of RDF and XML for mobile applications and finished off the chapter by talking about XML to UML mapping. 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. 48

  49. 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 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. Computer Manufacturer 49

  50. User Interface Development A software application is started by a person, another software application, 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 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. a hardware be started by a 50

Related


More Related Content

giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#