CHAPTER 1P1: FCH/SPH P2: FCH/SPH QC: FCH/SPH T1: FCH 0521817331c01 CB752-B’Far-v3 May 4, 2005...

CHAPTER 1

INTRODUCTION TO MOBILE

COMPUTING

P1: FCH/SPH P2: FCH/SPH QC: FCH/SPH T1: FCH

0521817331c01 CB752-B’Far-v3 May 4, 2005 18:26

CHAPTER 1

Introduction to MobileComputing

Where is the life we have lost in living? Where is the knowledge we have lost ininformation? Where is the wisdom we have lost in knowledge?

T. S. Elliot

1.1 INTRODUCTION

Mobile computing systems are computing systems that may be easily moved physi-cally and whose computing capabilities may be used while they are being moved.Examples are laptops, personal digital assistants (PDAs), and mobile phones. Bydistinguishing mobile computing systems from other computing systems we canidentify the distinctions in the tasks that they are designed to perform, the waythat they are designed, and the way in which they are operated. There are manythings that a mobile computing system can do that a stationary computing systemcannot do; these added functionalities are the reason for separately characterizingmobile computing systems.

Among the distinguishing aspects of mobile computing systems are their preva-lent wireless network connectivity, their small size, the mobile nature of their use,their power sources, and their functionalities that are particularly suited to the mo-bile user. Because of these features, mobile computing applications are inherentlydifferent than applications written for use on stationary computing systems. And,this brings me to the central motivation behind authoring this book.

The application development and software engineering disciplines are veryyoung engineering disciplines compared to those such as structural, mechanical,and electrical engineering. Software design and implementation, for the most part,

3


0521817331c01 CB752-B’Far-v3 May 4, 2005 18:26

4 INTRODUCTION TO MOBILE COMPUTING

Abacus Elect

ricity

Firs

t Com

pute

rsNet

workin

gSat

ellite

sCel

lula

r Tec

hnol

ogie

s

500 B.C. 1800's Mid1900's

1960–1970

1970–1980

1980–2000

FIGURE 1.1. A Timeline of Mobile Computing.

remain part art and part science. However, there are definite signs of maturationwith the development of architectures, metrics, proven tools, and other method-ologies that give an engineering discipline its structure. Whereas there are a varietyof methodologies, techniques, frameworks, and tools that are used in developingsoftware for stationary systems, there are very few for mobile systems. Althoughmobile computing systems have existed as long as their stationary counterparts,most of the mature tools, methodologies, and architectures in software engineeringtoday address the needs of stationary systems. One of our goals in this book willbe to reflect on the research being done today to help evolve mobile applicationdevelopment and to outline some of the early proven techniques and technologiesbeing tried in the commercial and academic environments.

In this text, we will look at those things that make the functional nature ofmobile applications different than their stationary counterparts, take a survey ofvarious development techniques that can be used to address these differences, andlook at various basic technologies that allow us, as software developers, to createmeaningful mobile applications in an extensible, flexible, and scalable manner.

1.1.1 A Brief History of Mobile ComputingFigure 1.1 shows a timeline of mobile computing development. One of the veryfirst computing machines, the abacus, which was used as far back as 500 B.C.,was, in effect, a mobile computing system because of its small size and portability.As technology progressed, the abacus evolved into the modern calculator. Mostcalculators today are made with an entire slew of mathematical functions whileretaining their small size and portability. The abacus and calculators became im-portant parts of technology not only because of their ability to compute but alsobecause of their ease of use and portability. You can calculate the proceeds of afinancial transaction anywhere as long as you had an abacus in 500 B.C. or have acalculator today. But, calculating numbers is only one part of computing.

Other aspects of computing, namely storage and interchange of information, donot date as far back as the abacus. Though writing has always been a way of storinginformation, we can hardly call a notebook a computing storage mechanism. Thefirst mobile storage systems can be traced back only as far as the advent of the ageof electronics.

stabrez

Highlight


0521817331c01 CB752-B’Far-v3 May 4, 2005 18:26

1.1 Introduction 5

FIGURE 1.2. Wireless Communication Systems.

A mobile computing system, as with any other type of computing system, can beconnected to a network. Connectivity to the network, however, is not a prerequisitefor being a mobile computing system. Dating from the late 1960s, networkingallowed computers to talk to each other. Networking two or more computerstogether requires some medium that allows the signals to be exchanged amongthem. This was typically achieved through wired networks. Although wired net-works remain the predominant method of connecting computers together, theyare somewhat cumbersome for connecting mobile computing devices. Not onlywould network ports with always-available network connectivity have to be per-vasive in a variety of physical locations, it would also not be possible to be con-nected to the network in real time if the device were moving. Therefore, providingconnectivity through a wired system is virtually cost prohibitive. This is wherewireless communication systems come to the rescue (Figure 1.2).

By the 1960s, the military had been using various forms of wireless communi-cations for years. Not only were wireless technologies used in a variety of voicecommunication systems, but the aviation and the space program had created greatadvances in wireless communication as well. First, the military developed wire-less communication through line of sight: If there were no obstacles betweenpoint A and point B, you could send and receive electromagnetic waves. Then


0521817331c01 CB752-B’Far-v3 May 4, 2005 18:26


the set of properties that distinguishes the mobile user from the user of a typical, sta-tionary computing system. We will wrap the differences between typical devices,applications, and networks with mobile devices, applications, and networksinto a set of properties that we will call the dimensions of mobility: the set of prop-erties that distinguishes the mobile computing system from the stationary computingsystem. Once we have some understanding of the mobile problem, we will lookat some established nonproprietary methodologies and tools of the software in-dustry trade such as Unified Modeling Language (UML) as well as some commer-cial proprietary tools such as Sun Microsystem’s Java, Microsoft’s Windows CE,Symbian, and Qualcomm’s BREW. Once we have looked at these tools, we will setout to solve the problem of architecting, designing, and implementing solutionsfor mobile computing problems.

Let us start by looking at some of those variables that create a distinction betweenmobile and stationary computing systems.

1.2 ADDED DIMENSIONS OF MOBILE COMPUTING

It should be obvious that any mobile computing system can also be stationary! Ifwe stop moving it, it is stationary. So, we can say that mobile computing systemsare a superset of stationary computing systems. Therefore, we need to look at thoseelements that are outside of the stationary computing subset. These added dimen-sions will help us pick out variables that in turn allow us to divide and conquerthe problems of mobile computing. The dimensions of mobility, as we will refer tothem in this text, will be the tools that allow us to qualify our problem of build-ing mobile software applications and mobile computing systems. Although thesedimensions of mobility are not completely orthogonal with respect to each other,they are separate enough in nature that we can distinguish them and approximatethem as orthogonal variables. Also, keep in mind that some of these dimensionsare limitations; nevertheless, they are still added dimensions that need not be con-sidered when dealing with the typical stationary application. These dimensions ofmobility (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, and7. active transactions.

It is absolutely crucial that the reader understands these dimensions of mobilityand keeps them in mind throughout the process of design and implementation ofthe mobile application. Too often, engineers begin with attention to design and getbogged down in details of the tools that they use and small focused problems withinthe bigger picture of the system, its design, and its architecture. The definition ofthe word “mobile” reveals the first dimension we will consider: location.

stabrez

Sticky Note

What are the dimensions of mobile computing?


0521817331c01 CB752-B’Far-v3 May 4, 2005 18:26

1.2 Added Dimensions of Mobile Computing 9

Multimodal andVariant Uls

Large Variety ofPlatforms

ActiveBehavior

LimitedDevice

Capabilities

WirelessConnectivity

LocationAwareness

LimitedPower Supply

FIGURE 1.3. Dimensions of Mobility.

1.2.1 LocationA mobile device is not always at the same place: Its location is constantly changing.The changing location of the mobile device and the mobile application presents thedesigners of the device and software applications with great difficulties. However,it also presents us with an opportunity of using the location and the change inlocation to enhance the application. These challenges and opportunities can bedivided into two general categories: localization and location sensitivity.

Localization is the mere ability of the architecture of the mobile application toaccommodate logic that allows the selection of different business logic, level ofwork flow, and interfaces based on a given set of location information commonlyreferred to as locales. Localization is not exclusive to mobile applications buttakes a much more prominent role in mobile applications. Localization is oftenrequired in stationary applications where users at different geographical locationsaccess a centralized system. For example, some point-of-sale (POS) systems ande-commerce Web sites are able to take into account the different taxation rulesdepending on the locale of the sale and the location of the purchase. Whereaslocalization is something that stationary applications can have, location sensitivityis something fairly exclusive to mobile applications.

Location sensitivity is the ability of the device and the software application tofirst obtain location information while being used and then to take advantage ofthis location information in offering features and functionality. Location sensitivitymay include more than just the absolute location of the device (if there is sucha thing as absolute location—Einstein must be rolling in his grave now!). It mayalso include the location of the device relative to some starting point or a fixedpoint, some history of past locations, and a variety of calculated values that maybe found from the location and the time such as speed and acceleration.

There are a variety of methods for collecting and using the location of the userand the device. The user may simply be prompted for his or her location, but thiswouldn’t make a very user-friendly application. Imagine a system that can onlygive you directions to where you want to go if you know where you are: It will beuseful often, but occasionally, you won’t know where you are or it would be toodifficult to figure out your location. The device may be reset for a relative locationif it has the ability to sense motion and can keep track of the change of location


0521817331c01 CB752-B’Far-v3 May 4, 2005 18:26


Satellite 1

Satellite 3

Satellite 2

Q1

Q3

Q2

B

a1b1

a3b3

a2b2

FIGURE 1.4. Determining Position Based on Triangulation.

for some period of time after this reset. Most location-sensing technologies (theparticulars of which will be discussed in Chapter 12) use one or more of threecategories of techniques: triangulation, proximity, and scene analysis [Hightowerand Borriello 2001].

Triangulation (Figure 1.4) relies on age-old geometric methods that allow cal-culation of the location of a point that lies in the middle of three other pointswhose exact locations are known. If the distance to each one of the three pointsis known, we can use geometric techniques to calculate the exact location of theunknown point. Proximity-based methods measure the relative position of the un-known point to some known point. Scene analysis relies on image processing andtopographical techniques to calculate the location of the unknown point based ona view of the unknown point from a known point.

The most well known location sensing system today is GPS. GPS-enabled de-vices can obtain latitude and longitude with accuracy of about 1–5 m. GPS has itsroots in the military; until recently, the military placed restrictions on the accuracyof GPS available for public use. Most of these restrictions have now been lifted.GPS devices use triangulation techniques by triangulating data points from thesatellite constellation that covers the entire surface of the earth. If a device doesnot have GPS capabilities but uses a cellular network for wireless connectivity,


0521817331c01 CB752-B’Far-v3 May 4, 2005 18:26


signal strength and triangulation or other methods can be used to come up withsome approximate location information, depending on the cellular network.

Regardless of how location information is obtained, it is one of the major dif-ferences between mobile and stationary systems. Location information can be tomobile applications what depth can be to two-dimensional pictures; it can give usan entirely new tool to automate tasks. An example of a stand-alone mobile soft-ware application that uses location information could be one that keeps track ofthe route that a user drives from home to work every day without the user enteringthe route manually; this could then be used to tell the user which route is the fastestway to get to work on a particular day or which route may result in the least amountof gas consumed. An example of a wirelessly networked mobile application takingadvantage of location could be one that shows a field service worker where to gonext, once he or she is finished with a task at one site, based on the requests forwork in the queue and the location of the field service worker. It should be notedthat acquiring position information requires connectivity to some network-basedinfrastructure. This infrastructure is typically isolated from the other network-based application infrastructures. Therefore, when we say stand-alone, we meanan application that may use some specific network-based infrastructure, such asGPS, for obtaining location information but is not connected to any other networksas a part of a distributed or network-based application.

Location information promises to be one of the biggest drivers of mobile appli-cations as it allows for the introduction of new business models and fundamentallynew methods of adding productivity to business systems.

1.2.2 Quality of ServiceWhether wired or wireless connectivity is used, mobility means loss of networkconnectivity reliability. Moving from one physical location to another creates phys-ical barriers that nearly guarantee some disconnected time from the network. If amobile application is used on a wired mobile system, the mobile system must bedisconnected between the times when it is connected to the wired docking portsto be moved. Of course, it is always a question whether a docking port is availablewhen required let alone the quality and type of the available network connec-tivity at that docking port. In the case of wireless network connectivity, physicalconditions can significantly affect the quality of service (QOS). For example, badweather, solar flares, and a variety of other climate-related conditions can nega-tively affect the (QOS). This unreliability in network connectivity has given rise tothe QOS field and has led to a slew of accompanying products. QOS tools andproducts are typically used to quantify and qualify the reliability, or unreliability,of the connectivity to the network and are mostly used by network operators. Net-work operators control the physical layer of the network and provide the facilities,such as Internet Protocol (IP), for software application connectivity.

Usually, the QOS tools, run by the network operators, provide information suchas available bandwidth, risk of connectivity loss, and statistical measurements thatallow software applications to make smart computing decisions. The key to de-signing and implementing mobile applications is that network connectivity andQOS need to be taken into account with an expanded scope. Most software


0521817331c01 CB752-B’Far-v3 May 4, 2005 18:26


applications, mobile or not, take advantage of networking in some way and, there-fore, do have network connectivity features. Stationary applications typically neednot worry about the quality of network connectivity as this is handled by lowerlevel layers than the application: the operating system, the hardware (such as thenetwork card in a personal computer), the network itself, and all of the other com-ponents that make network computing possible. Stationary software applicationstypically assume some discrete modes of connectivity mostly limited to connectedor disconnected. This works for most applications because most wired networkconnectivity is fairly reliable.

However, the effect of QOS in designing mobile applications is much moreprofound. Whereas typical nonmobile applications need to know how to stopoperating “gracefully” when suddenly disconnected from the network, mobileapplications have to know how to continue to operate even after they are discon-nected from the network or while they connect and disconnect from the networkintermittently and frequently. For example, let us take the case of a user who istraveling on a train, is using an application on his PDA connected wirelessly tosome network, and is downloading a work-related report to look over when thetrain passes through a tunnel and he loses network connectivity. If the applicationdoes not have the ability to stop partway through the download process and restartwhen connectivity is restored, the user may never be able to retrieve the desiredfile as he passes through one tunnel after the other and the download process startsover and over again. The application, therefore, must know how to deal with lackof reliable connectivity.

When it comes to taking into account the QOS in most applications, certainfunctionality is expected of most mobile applications. For example, almost all mo-bile applications should know how to stop working when the application suddenlydisconnects from the network and then resume working when it connects again.Other functionality may be desired but not required. For example, often QOS dataare measured and provided by the network operator. For example, the real-timebandwidth available may be part of the data provided and refreshed on some timeinterval. Such data can be utilized to design applications that dynamically adapttheir features and functionality to the available bandwidth.

1.2.3 Limited Device Storage and CPUNo one wants to carry around a large device, so most useful mobile devices aresmall. This physical size limitation imposes boundaries on volatile storage, non-volatile storage, and CPU on mobile devices. Though solid-state engineers areworking on putting more and more processing power and storage into smallerand smaller physical volumes, nevertheless, as most mobile applications today arevery 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 ofmodern applications designed to run on personal computers (PCs) and serverscontinue to care less and less about system resources such as memory and pro-cessing power, it is a sure bet that memory limitations will be around for a long


0521817331c01 CB752-B’Far-v3 May 4, 2005 18:26


time for mobile applications because when it comes to mobile systems and devices,smaller is nearly always better.

Smaller devices are easier to carry and, consequently, may become more perva-sive. This pervasiveness also largely depends on the price of the devices. Makingelectronic devices very small normally increases the cost, as the research anddevelopment that go into making devices smaller are very expensive. But, oncea technology matures and the manufacturing processes for making it becomesmostly automated, prices begin to decline. At the point when the device is moreand more of a commodity, smaller also means less expensive. This is why a PDA ismuch less expensive than a PC and yet it is much smaller. So, there is not a simpleproportional relationship between size of device and cost of device. Our generalrule stands that when it comes to mobile systems and devices, smaller is nearly alwaysbetter. The small size serves the mobile purpose of the device the best. And, weall know that there are physical boundaries on the size of transistors on modernmicrochips. This means that there is some ceiling for storage and processing powerof a device with a limited size bound by the heat produced by the transistors, thenumber of transistors that can possibly fit into each component, and the manyother factors that the microprocessor industry has been studying since the birthof microchips.

Limitations of storage and CPU of mobile devices put yet another constrainton how we develop mobile applications. For example, a mobile calendaring appli-cation 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 thedevice is disconnected from the network. But, because the amount of data thatcan be stored on each type of device varies depending on the device type, it is notpossible to allocate this storage space statically. Also, some information may beused more frequently than others; for example, the two weeks surrounding thecurrent time may be accessed more frequently in the calendar application or theremay be some contacts that are used more frequently. Mobile applications must bedesigned to optimize the use of data storage and processing power of the devicein terms of the application use by the user.

In this example, the calendaring application may or may not be the only appli-cation that uses the storage capacity of the device. So, the first step in designingthe application would be designing the appropriate functionality for discovery ofother applications on the device, the storage space that they use, and the totalstorage space available, and then computing the amount of storage available tothe calendaring application. The operating system of some devices may offer theavailable storage space, but this is not guaranteed. So, we need to design with theleast amount of assumptions about the hardware capabilities of the device or withall those assumptions valid for all of the devices to be supported by the mobileapplication.

Storage and processing issues are largely addressed by the various operatingsystems and platforms on the mobile devices. Therefore, a large part of engineer-ing mobile applications requires first a theoretical understanding of the various


0521817331c01 CB752-B’Far-v3 May 4, 2005 18:26


types of platforms and operating systems available on mobile devices, then anunderstanding of the available commercial implementations of the varieties oftypes of operating systems and platforms and the type of applications best suitedfor each platform–device combination. We will look at these issues closer inChapter 2.

This dimension of mobile application design, namely the effect of device limi-tations, is perhaps the most well known of all dimensions in today’s mobile appli-cation design. This was the first problem that software developers approached asthey tried to port frameworks, platforms, and methodologies of application devel-opment of the 1980s and 1990s to mobile applications. It soon became obvious toresearchers and developers that existing paradigms and platforms did not suffice.For now, many have simply adopted older methodologies and are building mobileapplications as pure embedded applications using assembly language native to thedevice on which they want the application to run. However, we have already seen,in the evolution of application development for PCs and servers, that develop-ing native applications is cost prohibitive. This is the reason that most of today’scomplex applications are not written in assembly; rather, they are written in C,C++, or a similar language and then compiled for the platform of need. Virtualmachines have given us yet another level of indirection to avoid authoring device-and platform-specific code in languages such as Java, thereby, decreasing the costof application development even more.

The point is that there is typically some cost involved with layers of indirectionin software. Though these layers of abstraction and indirection can have manybenefits, we need to balance their use with the single fact that mobile devices arelimited in their CPU, memory, and other computing capabilities. And, this muddiessolutions to some design and implementation problems that would otherwise bevery clear.

1.2.4 Limited Power SupplyWe have already seen that the size constraints of the devices limit their storagecapabilities and that their physical mobility affects network connectivity. For thesame set of reasons that wireless is the predominant method of network con-nectivity for mobile devices, batteries are the primary power source for mobiledevices. Batteries are improving every day and it is tough to find environmentswhere suitable AC power is not available. Yet, often the user is constantly movingand devices are consuming more and more power with processors that have moreand more transistors packed into them. For example, a user who walks in NewYork City and lives in the suburbs may leave work, begin using his or her PDA,get on the subway, and continue using it until returning home. When traveling inAsia, Africa, and South America, users are certain to rely on their batteries morefrequently as reliable wired power sources are less pervasive than they are in NorthAmerica and Europe.

The desirability of using batteries instead of an AC power source combined withthe size constraints creates yet another constraint, namely a limited power supply.This constraint must be balanced with the processing power, storage, and sizeconstraints; the battery is typically the largest single source of weight in the mobile


0521817331c01 CB752-B’Far-v3 May 4, 2005 18:26


BuyAirplaneTicket

Home Airport

CheckArrivalTime

FIGURE 1.5. An Application That Uses Both Voice and Text User Interfaces.

device [Welch 2000]. The power supply has a direct or an indirect effect on every-thing in a mobile device. For example, the brighter the display, the more batterypower is used, so the user interface is indirectly coupled to the power supply.

Most power management functionality is built into the operating system ofthe mobile device. Therefore, when it comes to device power management, thedesign focus is more on making the right choice in selecting the proper platform(device, operating system, etc.) and configuring the platform properly. In a typicalstationary application, this would suffice. But, in mobile applications, we need tolook everywhere we can to save power. Because the operating systems of mobiledevices are typically very lean and have as few functionalities as possible, manytimes the application must carry some burden of awareness of the power supply.

Some platforms allow monitoring of the remaining power and other relatedpower information. Some platforms allow multiprocessing and multithreading,which have an effect on the control over the variation of the CPU activity, whichin turn has an effect on the control over the power consumed by the device.Overall, the design and implementation of the application itself is affected lessby this dimension of mobility than by any of the others mentioned in this book.This is merely because operating systems and platforms are largely responsiblefor handling the power consumption issues. However, we will discuss the effectson choice of platform and other architectural and implementation effects that thepower supply has on mobile computing systems in a bit more detail in Chapters 15and 16.

1.2.5 Varying User InterfacesStationary users use nonmobile applications while working on a PC or a similardevice. The keyboard, mouse, and monitor have proved to be fairly efficient userinterfaces for such applications. This is not at all true for mobile applications.Examples of some alternative interfaces are voice user interfaces, smaller displays,stylus and other pointing devices, touch-screen displays, and miniature keyboards.Using a combination of interface types is not uncommon (see Figure 1.5).

For example, drivers who want to get some directions to their destinationmay use a data-enabled cellular phone, navigate through a simple graphical user


0521817331c01 CB752-B’Far-v3 May 4, 2005 18:26


interface (GUI) menu to a driving directions application, and then retrieve the de-sired directions through a voice user interface by saying the address of the sourceand destination and listening to the directions. Note that navigating to the applica-tion may be done much more efficiently on a GUI: It may be as simple as pushingtwo or three numbers that activate some choices on the screen. However, enteringtext on the small display of a cellular phone and through the numeric keys of aphone is very cumbersome. It is much easier to say the source and destination and,subsequently, have a voice recognition system translate them, find the directions,and read them to the user by using a text-to-speech system.

A mobile application, based on its device support, the type of users using it,the conditions under which it is used, and many other factors discussed later inthis book offers a variety of user interfaces. Perhaps the biggest paradigm shift thatdesigners and implementers of mobile applications must undergo is to understandthe necessity of finding the best user interface(s) for the application, architectingthe system to accommodate the suitable user interface(s), implementing them, andkeeping in mind that a new user interface may be required at any time. Althoughthese user interface advances promise to be one of the main aspects of the nextcomputing revolution, they add much complexity and confusion to the applicationdesign as the current application design and implementation methodologies onlytake into account keyboards, monitors, pointing devices, and sometimes touch-screens. The developer can no longer make any assumptions about the input andoutput mechanisms to the system; therefore, the development process becomesaltogether different, complicating an already complex design process.

User interfaces are difficult to design and implement for the following reasons[Meyers 1993]:

1. Designers have difficulties learning the user’s tasks.2. The tasks and domains are complex.3. A balance must be achieved among the many different design aspects, such as

standards, graphic design, technical writing, internationalization, performance,multiple levels of detail, social factors, and implementation time.

4. The existing theories and guidelines are not sufficient.5. Iterative design is difficult.6. There are real-time requirements for handling input events.7. It is difficult to test user interface software.8. Today’s languages do not provide support for user interfaces.9. Programmers report an added difficulty of modularization of user interface

software.

Meyers recognizes the problems associated with user interfaces of stationary com-puting systems. These problems are compounded by the multichannel requirementof mobile systems. Multichannel systems are systems that use multiple types ofuser interfaces for input and output such as text, voice, and video (see Chapter 8).

Since the recognition of the complexity of designing user interfaces by Meyersand others, some headway has been made in providing us some tools to reducethis complexity. First, because many GUI-based applications have been developed


0521817331c01 CB752-B’Far-v3 May 4, 2005 18:26


for stationary systems, the iterative process of design and implementation andfeedback from the users have taught us much about what works and what doesnot. So, we now know more about how to design user interfaces (item 4 in thepreceding list).

But, methodologies, tools, and patterns used in the development of stationaryapplications do very little to separate concerns of user interface from the rest ofthe application. Sure, there are several design patterns such as the (often misused,abused, and overused) model-view-controller (MVC), but the use of these patternsalone does not take into account the special concerns of various types of userinterfaces. They merely make some attempt at separating some of the concernsof the user interface from the rest of the system. They serve us well when weare dealing with a single set of textual inputs and outputs, but today’s populararchitectural techniques and design patterns are insufficient for a large varietyof user interfaces. And this is why much of the research in the area of mobilecomputing focuses precisely on this problem: How does one separate the concernsof the user interface from the application regardless of the type of user interface?

Today, we also have proven software design and development methodologies,such as that of object oriented programming (OOP) and use of unified modelinglanguage (UML), and the supporting languages and tools, that allow us to gatherthe requirements of the system more clearly (item 1 in the list of difficulties), tomodularize software design (item 9), and to design software without dependenceon the language of choice (item 8). But, we have no such methodologies and toolsto take into account the multichannel requirements of mobile systems or any ofthe other added dimensions of mobile application design. Though there is no con-sensus today how to use these tools to ease the development of multichannel userinterfaces, the reader will be presented with what we see as emerging methodolo-gies and tools that leverage existing proven methodologies and tools such as OOPand UML.

Not only do most software applications designed today have large couplingbetween the user interface and the application, but also very few are designedto render to any desired user interface with few modifications. Most of today’sapplications need to be massively retrofitted or rewritten altogether every time anew set of user interfaces must be supported. Of course, there is also the specialconcerns of each type of user interface, such as voice user interfaces, that must betaken into account.

We dedicate several chapters in this book to discussing various issues sur-rounding software architecture for rendering to any type of user interface, voiceuser interfaces, and the ways that users communicate with systems. For now, theimportant factor is to recognize that the user interface design and implementationprocess has a much bigger effect on an average mobile application than its coun-terpart nonmobile application.

1.2.6 Platform ProliferationBecause mobile devices are small and there is much less hardware in them than ina PC, they are typically less costly to assemble for a manufacturer. This means thatmore manufacturers can compete in producing these devices. These cheaper, and


0521817331c01 CB752-B’Far-v3 May 4, 2005 18:26


typically smaller, devices are often used for special purposes. The sum of theseand other similar reasons gives rise to proliferation of the types of devices in themarketplace that an application must support.

Platform proliferation has very significant implications on the architecture, de-sign, and development of mobile applications. Platform proliferation heightensthe importance of designing and developing devices independent of the platform.Writing native code specific to the mobile device, unless absolutely necessary be-cause of performance requirements, is not a recommended practice because of theproliferation of devices. For example, it is not wise to write a voice-driven phonebook application that runs only on one type of platform. Of course, the platformmakers and manufacturers of devices and operating systems of those devices willalways try to create restrictions on the developer to prohibit writing platform-independent applications. They may conversely give the developer features thatmay only be implemented on their platform to tie the developer to that platform.Regardless of the efforts of commercial platform builders, the software architectsand developers should be focused on their primary task of meeting the user’srequirements. And if these requirements include support of multiple platforms,which happens more frequently than not for mobile computing systems, platformindependence should be on the top of the architects’ and developers’ list whenchoosing the tools to build an application.

We will try to address the problem of platform proliferation by using nonpro-prietary methodologies and tools, such as UML, when possible. Throughout thebook, we will show our sample code for multiple platforms, alternating from oneto the other, so that the reader is exposed to particulars of implementation onseveral of the most prevalent commercial platforms.

1.2.7 Active TransactionsMost of today’s stationary applications have a restriction that can reduce the ben-efits of a mobile application system enormously: The user of the system mustinitiate all interactions with the system. We call such systems passive systems be-cause they are in a passive state, waiting for some external signal from the user totell them to start doing some particular thing. With stationary applications, thistypically works well. Most people sit down to use a computer because they intendto perform some task. Whatever actions they may perform could signal one ormore other passive systems to perform some computing task such as retrievinginformation or calculating some numbers.

At the same time, during the past two decades, messaging-based systems havebeen born and have evolved. With messaging systems, any one participant of thesystem can send a message to the other participant(s), and, if desired, under aspecific topic in an asynchronous manner. We will discuss both asynchronous andmessaging systems later in this chapter and other sections of this book. But, the keyidea to take away is that any one participant in the system could send a message toanother participant in the system. Later came the idea of push. In the push modelof communication, an information producer announces the availability of certaintypes of information, an interested consumer subscribes to this information, and


0521817331c01 CB752-B’Far-v3 May 4, 2005 18:26


the producer periodically publishes the information (pushes it to the consumer)[Hauswirth and Jazayeri 1999]. There is much in common between the conceptsof messaging systems and push systems. The principle difference is that messagingsystems are asynchronous by definition. This requirement does not exist for push-based systems.

Push systems, by definition, are active systems. For example, a particular usercould be browsing the Web and, while purchasing some goods online, be noti-fied of the change in the price of a particular stock. In this example, the systemhas taken an active role in starting communication with the user on a particulartopic.

Push–pull systems (a more complete name for push systems as the receiver ofthe “pushing” is said to be “pulling” on a particular topic) can be implemented ina number of ways, including using event-driven systems, messaging middleware,and poll-based systems. Implementation aside, unfortunately, push systems havemostly been a disappointing failure. One of the reasons for this failure has beenthat most push pull systems have targeted users who are largely focused on thetask at hand.

If a user sits at his or her desk and begins using a PC, the user is constantly re-minded, in an indirect manner, that he or she can access some piece of information.Even if the user is not performing some exact task, the simple condition of sittingdown and using a keyboard and a mouse puts the user in a state where he or sheis more likely to remember information processing related tasks. Educators oftencall this principle being on-task: As long as students are sitting at their desks, withtheir books open, there is a much higher chance of accomplishing tasks related tostudying. Based on the same principle, the user who is sitting behind his or herdesk working on a PC is on-task and focused. For example, if the user sits downand begins to type a memo to a coworker, the chances of the user remembering tocheck, say, his or her stock portfolio has increased by the mere fact that there arevisual reminders, such as the browser icon on the desk top, that will remind theuser to perform the task. Even if the user forgets (which is unlikely, particularlyif you are sitting on thousands of shares of stock that are worth a tenth of whatthey used to be after a market crash), if he or she is merely reminded by an e-mail,the user can very easily begin the transaction that performs whatever tasks areneeded to retrieve the necessary information and perform the necessary tasks. Areminder system certainly helps mainly because the user is focused on the task ofcomputing and is available to receive the reminder. (We will talk about the lackof focus of the mobile user more in the next section.)

In this book, we will define active transactions as those transactions initiatedby the system. Active transactions may be synchronous or asynchronous. All ac-tive transactions are initiated by the system. Synchronous transactions are time-dependent transactions. Note that the term transaction is used in data storageand other systems to indicate boundaries for roll-back and committing of a seriesof actions that must be successfully executed, in some predetermined manner,for the completion of the transaction. We use the term in a slightly differentmanner. We use it to refer to a sequence of interactions between the user and the


0521817331c01 CB752-B’Far-v3 May 4, 2005 18:26

1.4 Architecture of Mobile Software Applications 25

and finish the same transaction later on a different device and at a different placeand time.

The mobile condition of the mobile user should be the primary guiding toolin architecting, designing, and implementing the mobile application. The variousproblems presented to us by the mobile condition may require solutions thathave inherent conflicts. For example, to increase the number of devices and userinterfaces supported, we may want to centralize the business logic and use thedevices only as thin clients. (Thin clients are discussed in detail in Chapter 16.)However, to make the user interface as friendly as possible and to make the useof application possible even when the device is not connected to the network, wewould want to push a significant portion of the application to the client. Obviously,these two aspects are in direct conflict. In another example, we may see that aparticular mobile application requires increased CPU to perform a particular taskfaster. But the increased CPU may mean a considerably larger device, making itmore difficult to carry. As with any other engineering problem, while designingmobile applications, we will find that we often need to balance the solutions toproblems presented by each mobility dimension. There is no better balancing guidethan the mobile condition of the mobile user. Of course, cost in itself can offsetthe benefits of any solution. Once again, as with any other engineering problem,the solution needs to fit the problem of the customer, in our case the mobile user,within a given budget. With an unlimited budget, nearly anything can be done.But, of course, we all know that there is not such a thing as an unlimited budget.

Therefore the cost and the mobile condition comprise the variables that describeour customer. Every mobile user will have a specific set of needs, but those twoare constants. In added dimensions of mobility, we have the major effects of themobile condition on the requirements for building mobile applications. Once wehave gathered the requirements from the user, the first step in building the mobileapplication is to decide on the architecture. And this is what we will discuss next.

1.4 ARCHITECTURE OF MOBILE SOFTWARE APPLICATIONS

The first step in building a software application, after the process of gatheringrequirements, is to lay down a high-level plan of what the application will be likewhen it is finished. Mobile applications, like any other software application, re-quire such a high-level plan. We call this high-level plan of the mobile applicationa “mobile software architecture.” Our approach to architecture in this text willbe bottom up: we will introduce a variety of design patterns, application archi-tectures, and processes with each addressing some specific problem with mobileapplications (Figure 1.6).

If you are not familiar with the basic prevalent application architectures in to-day’s distributed Web applications, we recommend that you read Sections 16.1.1and 16.1.2 of Chapter 16. You will see the terms N-Tier, client–server, mobileagent, and peer-to-peer quite frequently throughout this text and you shouldhave at least a passing familiarity with them. In Chapter 16, we will define


0521817331c01 CB752-B’Far-v3 May 4, 2005 18:26


Architectual Style

Dimensions of Mobility

DesignPatterns

FIGURE 1.6. Mobile Application Development Design Consideration Space.

software architecture to be a particular high-level abstraction of the system and how itscomponents collaborate. Then, we will summarize what we will learn in Chapters 1through 15 to get a feeling for various architectural designs and techniques formobile applications. For now, let us look at what software architectures will meanto us within the confines of mobile application development.

There are also architectural patterns; these are patterns that are recognizableonce they are used prevalently in some architectures. Although there are no fullyestablished design patterns, architectural patterns, or even architectures in the fieldof mobile computing because of its infancy, one of our goals in this text is to outlinesome techniques that show evidence of such techniques beginning to mature.These patterns exhibit themselves in a variety of families of problems. For example,we will introduce several different architectures for design and implementation ofmultimodal user interfaces. We will also introduce some lower level design patternsfor separating the concerns of building user interfaces from our core application.

Note that the architectural decisions made in a software system are typically themost important during the lifetime of that software system. Architecture is also asmuch of an art as a skill gained through experience. It is at least partially a stylisticaspect of software. With this said, we will try to lay out the various alternativesmade available by commercial vendors and academics. You will need to make theappropriate decisions based on the requirements of the individual project.

1.5 OUR ROAD MAP

In this first chapter, we looked at the dimensions of mobility and the mobilecondition. These two helped us understand the fundamental differences betweendesigning a mobile application and a stationary application. Next, we surveyedsome high level architectures. As we mentioned, much of what architectures do forus is to lay out a high-level plan of how the components of the system interact with

1.1 Applications

Although many applications can benefit from wireless networks and mobilecommunications, particular application environments seem to be predestinedfor their use. The following sections will enumerate some of them – it is left toyou to imagine more.

1.1.1 VehiclesToday’s cars already comprise some, but tomorrow’s cars will comprise manywireless communication systems and mobility aware applications. Music, news,road conditions, weather reports, and other broadcast information are receivedvia digital audio broadcasting (DAB) with 1.5 Mbit/s. For personal communica-tion, a universal mobile telecommunications system (UMTS) phone might beavailable offering voice and data connectivity with 384 kbit/s. For remote areas,satellite communication can be used, while the current position of the car isdetermined via the global positioning system (GPS). Cars driving in the samearea build a local ad-hoc network for the fast exchange of information in emer-gency situations or to help each other keep a safe distance. In case of an accident,not only will the airbag be triggered, but the police and ambulance service willbe informed via an emergency call to a service provider. Cars with this technol-ogy are already available. In the future, cars will also inform other cars aboutaccidents via the ad-hoc network to help them slow down in time, even before adriver can recognize an accident. Buses, trucks, and trains are already transmit-ting maintenance and logistic information to their home base, which helps toimprove organization (fleet management), and saves time and money.

Figure 1.1 shows a typical scenario for mobile communications with manywireless devices. Networks with a fixed infrastructure like cellular phones (GSM,UMTS) will be interconnected with trunked radio systems (TETRA) and wirelessLANs (WLAN). Satellite communication links can also be used. The networksbetween cars and inside each car will more likely work in an ad-hoc fashion.Wireless pico networks inside a car can comprise personal digital assistants(PDA), laptops, or mobile phones, e.g., connected with each other using theBluetooth technology.

This first scenario shows, in addition to the technical content, somethingtypical in the communication business – many acronyms. This book containsand defines many of these. If you get lost with an acronym, please check theappendix, which contains the complete list, or check the terms and definitionsdatabase interactive (TEDDI) of ETSI (2002).

Think of similar scenarios for air traffic or railroad traffic. Different prob-lems can occur here due to speed. While aircraft typically travel at up to900 km/h and current trains up to 350 km/h, many technologies cannot oper-ate if the relative speed of a mobile device exceeds, e.g., 250 km/h for GSM or100 km/h for AMPS. Only some technologies, like DAB work up to 900 km/h(unidirectional only).

Introduction 3

02Chap01 8804 (1-24) 30/5/03 11:03 am Page 3

1.1.2 EmergenciesJust imagine the possibilities of an ambulance with a high-quality wireless con-nection to a hospital. Vital information about injured persons can be sent to thehospital from the scene of the accident. All the necessary steps for this particu-lar type of accident can be prepared and specialists can be consulted for an earlydiagnosis. Wireless networks are the only means of communication in the caseof natural disasters such as hurricanes or earthquakes. In the worst cases, onlydecentralized, wireless ad-hoc networks survive. The breakdown of all cablingnot only implies the failure of the standard wired telephone system, but also thecrash of all mobile phone systems requiring base stations!

1.1.3 BusinessA travelling salesman today needs instant access to the company’s database: toensure that files on his or her laptop reflect the current situation, to enable thecompany to keep track of all activities of their travelling employees, to keep data-bases consistent etc. With wireless access, the laptop can be turned into a truemobile office, but efficient and powerful synchronization mechanisms are neededto ensure data consistency. Figure 1.2 illustrates what may happen when employ-ees try to communicate off base. At home, the laptop connects via a WLAN orLAN and DSL to the Internet. Leaving home requires a handover to another tech-nology, e.g., to an enhanced version of GSM, as soon as the WLAN coverage ends.Due to interference and other factors discussed in chapter 2, data rates drop whilecruising at higher speed. Gas stations may offer WLAN hot spots as well as gas.Trains already offer support for wireless connectivity. Several more handovers todifferent technologies might be necessary before reaching the office. No matter

Mobile communications4

ad-h

oc

Personal Travel Assistant,DAB, PDA, laptop,GSM, UMTS, WLAN,Bluetooth, ...

UMTS, WLAN, DAB,GSM, cdma2000,TETRA, ...

Figure 1.1A typical application of

mobile communications:road traffic

02Chap01 8804 (1-24) 30/5/03 11:03 am Page 4

when and where, mobile communications should always offer as good connectiv-ity as possible to the internet, the company’s intranet, or the telephone network.

1.1.4 Replacement of wired networksIn some cases, wireless networks can also be used to replace wired networks,e.g., remote sensors, for tradeshows, or in historic buildings. Due to economicreasons, it is often impossible to wire remote sensors for weather forecasts,earthquake detection, or to provide environmental information. Wireless con-nections, e.g., via satellite, can help in this situation. Tradeshows need a highlydynamic infrastructure, but cabling takes a long time and frequently proves tobe too inflexible. Many computer fairs use WLANs as a replacement for cabling.Other cases for wireless networks are computers, sensors, or information dis-plays in historical buildings, where excess cabling may destroy valuable walls orfloors. Wireless access points in a corner of the room can represent a solution.

1.1.5 Infotainment and moreInternet everywhere? Not without wireless networks! Imagine a travel guide fora city. Static information might be loaded via CD-ROM, DVD, or even at homevia the Internet. But wireless networks can provide up-to-date information atany appropriate location. The travel guide might tell you something about thehistory of a building (knowing via GPS, contact to a local base station, or trian-gulation where you are) downloading information about a concert in thebuilding at the same evening via a local wireless network. You may choose aseat, pay via electronic cash, and send this information to a service provider(Cheverst, 2000). Another growing field of wireless network applications lies inentertainment and games to enable, e.g., ad-hoc gaming networks as soon aspeople meet to play together.

1.1.6 Location dependent services

Introduction 5

LAN, WLAN780 kbit/s

GSM 53 kbit/sBluetooth 500 kbit/s

UMTS, GSM115 kbit/s

LAN100 Mbit/s,

WLAN54 Mbit/s

GSM/EDGE 384 kbit/s,WLAN 780 kbit/s

GSM 115 kbit/s,WLAN 11 Mbit/s

UMTS, GSM384 kbit/s

UMTS, DECT2 Mbit/s

Figure 1.2Mobile and wirelessservices – always bestconnected

02Chap01 8804 (1-24) 30/5/03 11:03 am Page 5

Many research efforts in mobile computing and wireless networks try to hidethe fact that the network access has been changed (e.g., from mobile phone toWLAN or between different access points) or that a wireless link is more errorprone than a wired one. Many chapters in this book give examples: Mobile IPtries to hide the fact of changing access points by redirecting packets but keep-ing the same IP address (see section 8.1), and many protocols try to improvelink quality using encoding mechanisms or retransmission so that applicationsmade for fixed networks still work.

In many cases, however, it is important for an application to ‘know’ some-thing about the location or the user might need location information forfurther activities. Several services that might depend on the actual location canbe distinguished:

● Follow-on services: The function of forwarding calls to the current userlocation is well known from the good old telephone system. Wherever youare, just transmit your temporary phone number to your phone and it redi-rects incoming calls.2 Using mobile computers, a follow-on service couldoffer, for instance, the same desktop environment wherever you are in theworld. All e-mail would automatically be forwarded and all changes to yourdesktop and documents would be stored at a central location at your com-pany. If someone wanted to reach you using a multimedia conferencingsystem, this call would be forwarded to your current location.

● Location aware services: Imagine you wanted to print a document sittingin the lobby of a hotel using your laptop. If you drop the document overthe printer icon, where would you expect the document to be printed?Certainly not by the printer in your office! However, without additionalinformation about the capabilities of your environment, this might be theonly thing you can do. For instance, there could be a service in the hotelannouncing that a standard laser printer is available in the lobby or acolor printer in a hotel meeting room etc. Your computer might then trans-mit your personal profile to your hotel which then charges you with theprinting costs.

● Privacy: The two service classes listed above immediately raise the questionof privacy. You might not want video calls following you to dinner, butmaybe you would want important e-mails to be forwarded. There might belocations and/or times when you want to exclude certain services fromreaching you and you do not want to be disturbed. You want to utilize loca-tion dependent services, but you might not want the environment to knowexactly who you are. Imagine a hotel monitoring all guests and selling theseprofiles to companies for advertisements.

● Information services: While walking around in a city you could always use


2 Actually, this is already done with the phone network – your phone just handles some signalling.

02Chap01 8804 (1-24) 30/5/03 11:03 am Page 6

your wireless travel guide to ‘pull’ information from a service, e.g., ‘Whereis the nearest Mexican restaurant?’ However, a service could also actively‘push’ information on your travel guide, e.g., the Mexican restaurant justaround the corner has a special taco offer.

● Support services: Many small additional mechanisms can be integrated tosupport a mobile device. Intermediate results of calculations, state informa-tion, or cache contents could ‘follow’ the mobile node through the fixednetwork. As soon as the mobile node reconnects, all information is avail-able again. This helps to reduce access delay and traffic within the fixednetwork. Caching of data on the mobile device (standard for all desktopsystems) is often not possible due to limited memory capacity. The alterna-tive would be a central location for user information and a user accessingthis information through the (possibly large and congested) network all thetime as it is often done today.

1.1.7 Mobile and wireless devicesEven though many mobile and wireless devices are available, there will be manymore in the future. There is no precise classification of such devices, by size,shape, weight, or computing power. Currently, laptops are considered the upperend of the mobile device range.3 The following list gives some examples ofmobile and wireless devices graded by increasing performance (CPU, memory,display, input devices etc.). However, there is no sharp line between the cate-gories and companies tend to invent more and more new categories.

● Sensor: A very simple wireless device is represented by a sensor transmittingstate information. One example could be a switch sensing the office door. Ifthe door is closed, the switch transmits this to the mobile phone inside theoffice which will not accept incoming calls. Without user interaction, thesemantics of a closed door is applied to phone calls.

● Embedded controllers: Many appliances already contain a simple or some-times more complex controller. Keyboards, mice, headsets, washingmachines, coffee machines, hair dryers and TV sets are just some examples.Why not have the hair dryer as a simple mobile and wireless device (from acommunication point of view) that is able to communicate with the mobilephone? Then the dryer would switch off as soon as the phone starts ringing– that would be a nice application!

● Pager: As a very simple receiver, a pager can only display short text mes-sages, has a tiny display, and cannot send any messages. Pagers can even beintegrated into watches. The tremendous success of mobile phones, hasmade the pager virtually redundant in many countries. Short messages havereplaced paging. The situation is somewhat different for emergency services

Introduction 7

3 Putting a mainframe on a truck does not really make it a mobile device.

02Chap01 8804 (1-24) 30/5/03 11:03 am Page 7

where it may be necessary to page a larger number of users reliably withinshort time.

● Mobile phones: The traditional mobile phone only had a simple black andwhite text display and could send/receive voice or short messages. Today,mobile phones migrate more and more toward PDAs. Mobile phones with fullcolor graphic display, touch screen, and Internet browser are easily available.

● Personal digital assistant: PDAs typically accompany a user and offersimple versions of office software (calendar, note-pad, mail). The typicalinput device is a pen, with built-in character recognition translating hand-writing into characters. Web browsers and many other software packagesare available for these devices.

● Pocket computer: The next steps toward full computers are pocket comput-ers offering tiny keyboards, color displays, and simple versions of programsfound on desktop computers (text processing, spreadsheets etc.).

● Notebook/laptop: Finally, laptops offer more or less the same performanceas standard desktop computers; they use the same software – the only tech-nical difference being size, weight, and the ability to run on a battery. Ifoperated mainly via a sensitive display (touch sensitive or electromagnetic),the devices are also known as notepads or tablet PCs.

The mobile and wireless devices of the future will be more powerful, less heavy,and comprise new interfaces to the user and to new networks. However, one bigproblem, which has not yet been solved, is the energy supply. The more featuresthat are built into a device, the more power it needs. The higher the perfor-mance of the device, the faster it drains the batteries (assuming the sametechnology). Furthermore, wireless data transmission consumes a lot of energy.

Although the area of mobile computing and mobile communication isdeveloping rapidly, the devices typically used today still exhibit some majordrawbacks compared to desktop systems in addition to the energy problem.Interfaces have to be small enough to make the device portable, so smaller key-boards are used. This makes typing difficult due to their limited key size. Smalldisplays are often useless for graphical display. Higher resolution does not help,as the limiting factor is the resolution capacity of the human eye. These deviceshave to use new ways of interacting with a user, such as, e.g., touch sensitivedisplays and voice recognition.

Mobile communication is greatly influenced by the merging of telecommu-nication and computer networks. We cannot say for certain what the telephoneof the future will look like, but it will most probably be a computer. Even today,telephones and mobile phones are far from the simple ‘voice transmissiondevices’ they were in the past.4 Developments like ‘voice over IP’ and the gen-eral trend toward packet-oriented networks enforce the metamorphosis oftelephones (although voice services still guarantee good revenue). While no one


4 Chapter 4 will present more features of modern mobile phone systems, including the growingdemand for bandwidth to use typical Internet applications via the mobile ‘phone’.

02Chap01 8804 (1-24) 30/5/03 11:03 am Page 8

LIMITATIONS OF MOBILE COMPUTING

1. Insufficient Bandwidth: Mobile Internet access is generally slower than direct cable

connections, using technologies such as GPRS and EDGE, and more recently 3G and 4G

networks. These networks are usually available within range of commercial cell phone towers.

Higher speed wireless LANs are inexpensive but have very limited range.

2. Security Standards: When working mobile, one is dependent on public networks, requiring

careful use of Virtual Private Network (VPN). Security is a major concern while concerning the

mobile computing standards on the fleet. One can easily attack the VPN through a huge number

of networks interconnected through the line.

3. Power consumption: When a power outlet or portable generator is not available, mobile

computers must rely entirely on battery power. Combined with the compact size of many mobile

devices, this often means unusually expensive batteries must be used to obtain the necessary

battery life. Mobile computing should also look into Greener IT [3], in such a way that it saves

the power or increases the battery life.

4. Transmission interferences: Weather, terrain, and the range from the nearest signal point can

all interfere with signal reception. Reception in tunnels, some buildings, and rural areas is often

poor.

5. Potential health hazards: People who use mobile devices while driving are often distracted

from driving are thus assumed more likely to be involved in traffic accidents. Cell phones may

interfere with sensitive medical devices. There are allegations that cell phone signals may cause

health problems.

6. Human interface with device: Screens and keyboards tend to be small, which may make

them hard to use. Alternate input methods such as speech or handwriting recognition require

training.

CHAPTER 1P1: FCH/SPH P2: FCH/SPH QC: FCH/SPH T1: FCH 0521817331c01 CB752-B’Far-v3 May 4, 2005...

Documents

Transcript of CHAPTER 1P1: FCH/SPH P2: FCH/SPH QC: FCH/SPH T1: FCH 0521817331c01 CB752-B’Far-v3 May 4, 2005...