INTRODUCTION

The Extensible Markup Language—XML—is a subset of the Standard Generalized 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 nonproprietary 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.

There are many excellent writings and books on the topic of XML. If you are not familiar with XML, you should probably stop here, familiarize yourself with the basics of XML, and then come back and continue. In this chapter, our intent is to outline some XML-based or XML-related technologies that are key in developing mobile applications.

To understand how and why XML is used in mobile applications, we should understand a brief history of how it came to be.

Brief History

In the beginning, there was SGML. And then, from SGML, came the less intelligent, but more likable son, XML.

If there were a bible of computer science, it would tell us the history of XML with a bit more flare. But, that essentially sums up where XML came from.

When the Web was first created, XML's sister, HTML, was born first.

INTRODUCTION

One of the first topics that we discussed in this text was the definition of mobility and how it differs from wireless connectivity. By definition wireless connectivity between a mobile device and another device requires a physical layer networking technology. To cover all of the subjects that will allow one to comprehensively understand wireless connectivity and its currently existing permutations is impossible, not just in this text, but even in a dedicated text. One may require an entire library to gather all of the various topics on wireless connectivity and related inventions. So, the first thing that we might do is to reduce the scope of what wireless connectivity may mean in our discussion of mobile computing.

In this chapter, we will first look at a basic introduction to wireless communication that will include examples of techniques and technologies from the various abstraction layers in wireless communications.

We can qualify two types of connectivity to the network: strong and weak. We use the concept of strong and weak connections in various places in this text. Essentially, a weak connection refers to lower QOS than strong connectivity but higher than disconnection. This way of distinguishing weak and strong connections is fairly subjective and relative to the application. Unfortunately, because of the changing landscape of communication and computing, we cannot quantify the QOS properties of strong and weak connectivity.

INTRODUCTION

Location, location, location. The changing location of the user and the device used by the user make mobile applications fundamentally different from their stationary counterparts. Yet, most software developers, even those who have some experience with mobile applications, have little experience and understanding in how location-based information is gathered and distributed and how this information may be utilized by mobile applications. Although we will not be able to cover all aspects of location-based information in mobile applications, we will try to tackle the basic problems in this chapter.

If you have looked into developing mobile applications, you have certainly heard of “location-based services.” The UTMS Forum defines location-based services as follows:

This definition is somewhat narrow as it limits location-based services to 3G services. There are many location-based services that do not have any relationship with 3G services. So, location-based services are those things that provide the mobile device, the mobile application, and the mobile user with location information about themselves or other devices, applications, and users.

INTRODUCTION

Much of the research done in software engineering is dedicated to solving practical problems that come up when building software applications. Techniques such as Extreme Programming and RUP are two such techniques and methodologies, addressing some of the issues associated with the process of building software applications.

The dimensions of mobility, as we have seen, add to the complexity of developing mobile applications. In this way, an entirely new set of hurdles and problems are introduced. In this chapter, we will briefly look at a few of these problems. Some of these problems will be addressable by the tools that we have introduced previously in this text; others will not.

Some of the basic hurdles are caused by the fact that most developers either have experience building call centers and other types of voice systems using the telephony channel or they build PC applications with GUIs. So, we will start by looking at hurdles associated with building a VUI for those developers who come from a server-side or GUI-based development background.

VOICE USER INTERFACE HURDLES

The first question that will come to your mind will be related to the infrastructure. This will be a hurdle in real deployments.

INTRODUCTION

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 through using pronounced language.

It is also true that most us have had very frustrating experiences trying to bypass the voice recognition system and reach an operator. However, this is not an indicator of the lack of value of voice recognition systems. In fact, most systems that lead users to be frustrated are those that have not been well designed or those that require a high degree of cognition by the computing system: something that computing systems do not do well yet. As we have already seen, the user interface problem is one of the biggest problems in mobile computing.

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. By distinguishing mobile computing systems from other computing systems we can identify the distinctions in the tasks that they are designed to perform, the way that they are designed, and the way in which they are operated. There are many things that a mobile computing system can do that a stationary computing system cannot do; these added functionalities are the reason for separately characterizing mobile computing systems.

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 usage on stationary computing systems. And this brings me to the central motivation behind authoring this book.

The application development and software engineering disciplines are very young engineering disciplines compare to those such as structural, mechanical, and electrical engineering. Software design and implementation, for the most part, remains part art and part science.

INTRODUCTION

Thus far, in the first three sections of this text, we have focused on recognizing the new problems facing mobile application developers, tools to solve those problems, and how to use those tools to solve each specific problem.

Let us now look at the macro view of developing mobile applications. When we develop a stationary application, we gather requirements, lay out an architecture and design, select some tools to help us implement the application, develop the application, test, and deliver. Although this is a gross oversimplification of the application development process, it lays out the rough steps of developing stationary applications. There are development methodologies that go into each of these steps in a detailed manner and lay out a methodical approach to tackle them.

The question to ask now that we know how to deal with the detailed problems of mobile application development is whether these methodologies can be used as is or whether they must be modified to develop mobile applications.

BACK TO THE DIMENSIONS OF MOBILITY

If there is one thing you should know by now, it is that the dimensions of mobility are what make mobile applications different from their stationary counterparts. The dimensions of mobility and the mobile condition of the user, cumulatively, are what make the process of developing mobile applications different from the process of developing stationary applications.

INTRODUCTION

We have thus far discussed user interfaces in some detail. We have seen that, depending on the function of the mobile application, we may want to interact with the user through audio, a traditional GUI, or a combination thereof. We have also seen that, because of the wide variety of capabilities among mobile devices and the proliferation of the platforms, there are a great number of user interfaces that we may have to implement for a given application. Although we have looked at mobile GUIs and then VUIs individually, we have not looked at the discipline of building applications that may use more than one channel of communication with the network or interact with the user through more than one mode of their user interface. This is what we will be discussing in this chapter.

First, let us define what multichannel and multimodal mean for these two terms have been incorrectly used widely in the literature on mobile computing. To start, remember that multimodal and multichannel are not the same thing. Multichannel may have two different meetings. First, it can be used to imply a user interface that establishes more than one communication channel to the user. For example, a user interface may present an audio and a video channel to the user.

INTRODUCTION

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

Today, there are many programming languages, frameworks, and tools designed to develop server-based and desktop applications. These languages, frameworks, and tools have matured through the years, becoming more efficient and more reliable as they get tested in real environments by real users. Along with the maturation of these tools has come the maturation of the process of software design and implementation. Ideas such as OOP, design patterns, and de facto standard software development processes have been developed and have matured with the tools and frameworks in a symbiotic manner.

INTRODUCTION

In Chapter 16, we briefly look at five different architecture types: fully centralized, client–server and its variations of N-tier, mobile agents, and peer-to-peer. You may want to refer to this chapter intermittently or read it first. In this chapter, we will focus on the latter two, namely mobile agents and peer-to-peer systems, as relating to mobile application development.

We focus on these systems for two reasons. First, the application of mobile agents and peer-to-peer architectures in the mobile application realm is not well documented because both are fairly recent concepts. Second, both mobile agents and peer-to-peer architectures promise to play an integral role in mobile application development as it matures. We have already discussed the properties of these two architectures that make them more desirable for mobile application development. Furthermore, we have surveyed both of these technologies. Now, you may wonder why we are making an association between the peer-to-peer and mobile agent architectures. We can find the answer in looking at some of the properties of the two architectures and their contrasts with the client–server model.

Peer-to-peer and mobile applications are similar in the following ways:

1. Unlike the centralized and client–server architectures, there is no necessity for a centralized server. There is no inherent difference between the system-level participants of peer-to-peer and mobile agent architectures, respectively peers and hosts, within the confines of the respective architecture, as there is between the client and the server in the client–server environment.

2. The participants of the system can be interconnected to each other in any manner. Both peer-to-peer architectures and mobile agent architectures allow for self-organizing and ad hoc networks.

Four years ago, Reza and I were working together at eBuilt when he first stopped by my office to talk about frameworks for wireless application development. We were in the final months of the so-called “dot-com era,” when dreams of a new economy allowed just about anyone to get funding for a network-based application, particularly when it also involved some form of mobile computing device. Those people with ideas (and sometimes funding) would come to our company and ask us to implement their vision. Of course, they would also ask for a few miracles, such as a working prototype within a month and deployment across all devices in six months. Oddly enough, we could actually accomplish implementations like that, if it were not for one problem out of our control: mobile devices had a market lifetime of only about four months.

It was the year 2000, just a couple months after Y2K became a non-issue, and there was so much variance in the types of mobile devices, both in terms of their feature sets and in their application development environments, that an application developed for one device environment would be obsolete by the time it was ready to market. Reza had a solution in mind and was determined to get, which is why he was busy pacing in my office.

INTRODUCTION

In Chapter 5, we saw why and how to build generic user interfaces. The two types of interfaces that dominate computing today are Graphical User Interfaces (GUIs) and Voice User Interfaces (VUIs). So, when we specialize a generic user interface, we are typically specializing it to either a GUI (of which we will consider text-only user interfaces to be a subset) or a VUI. In this chapter, we will look at GUIs, in Chapter 7 we will look at VUIs, and in Chapter 8 we will see how to build multimodal user interfaces that use multiple channels to reach the user.

Let us remember our 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.

Networks of regular structure, such as the torus or the hypercube, usually have the links labeled with their direction. We now discuss some recent research evaluating the benefits of such a labeling, called Sense of Direction or SoD. The availability of sense of direction strengthens the model and allows processors to communicate more efficiently with each other, and to exploit topological properties of the network algorithmically.

Sense of direction has been shown to reduce the complexity of some problems, but the number of problems for which this applies is surprisingly small. Indeed, for many problems, more efficient or easier algorithms are known if the edge labeling can be exploited. However, in many non-trivial cases good lower bounds for the unlabeled case are not available, and moreover some surprisingly efficient algorithms exist in unlabeled graphs.

The chapter attempts to follow the scientific struggle, started by Santoro [San84], to establish cases in favor of sense of direction in two areas: broadcasting and election.

We shall define sense of direction for several specific classes of network, and show how the election problem on rings can be solved more efficiently if chords and a sense of direction are available. We shall show that elections can be performed with linear complexity in hypercubes and cliques if SoD is available, but also that a randomized algorithm can achieve the same complexity without using SoD. Algorithms to compute an SoD in networks where none is given will also be discussed.

This chapter discusses two protocols that are used for the reliable exchange of data between two computing stations. In the ideal case, data would simply be exchanged by sending and receiving messages. Unfortunately, the possibility of communication errors cannot always be ignored; the messages must be transported via a physical medium, which may lose, duplicate, reorder, or garble messages transmitted through it. These errors must be detected and corrected by supplementary mechanisms, traditionally referred to as protocols, implemented in the computing stations.

The main function of these protocols is data transmission, i.e., the accepting of the information at one station and its delivery at the other station. Reliable data transmission includes the repeated sending of messages that are lost, rejecting or correcting messages that are garbled, and discarding duplicates of messages. To do so the protocol maintains state information, recording which data has already been sent, which data has been certified to be received, and so on. The necessity of using state information raises the issue of connection management, i.e., the initialization and discarding of state information. The initialization is called opening the connection and its discarding is called closing the connection. The difficulty of connection management is due to the possibility that a message remains in the communication channels when the connection is closed. Such a message could be received when no connection exists or during a later connection, and its receipt must not disturb the correct operation of the current connection.