INTRODUCTION

The unified modeling language (UML) is a standardized language for modeling software systems. Although small systems are easy for a single person or a small group to comprehend and develop, large systems are more difficult to design successfully, since there are often many people and entities controlling different aspects of the system and defining how they should work from their own professional specialty or prerogative. For example, a large company requesting a new piece of software might assign the job to a project manager who has a thorough understanding of the overall system requirements, whereas a software developer assigned to work on the system is likely to care more about the ways that individual portions of a system work on a detailed level and less about the practical requirements of users and management. Similarly, an end user of the system is likely to care about how the user interface is organized and that the software is built to facilitate ease of use for everyday users, rather than that a particular software component was designed exquisitely or that the project fulfills the stated requirements that its originator decided on.

INTRODUCTION

We have now seen the basic tools we will use for the development process in creating mobile applications. The next step is to begin defining a methodology for building real applications and to show the implementation of the methodology in building these real applications.

Through the first four chapters, we discovered that, because of the condition of the mobile user and nature of the mobile application, the mobile application may interface with the user through a variety of devices and channels. In this chapter, we will take a closer look at the fundamentals of user interfaces to software applications, primarily mobile applications. We will focus on changing a paradigm shift in the application developer's thinking, moving him or her from thinking that an application will be used using a mouse, keyboard, and a monitor to thinking that an application may be used by a subset of any system input and output channel through which the user may receive stimuli from a system and respond to it. Finally, we will look at how to create user interfaces in layers so that we apply the principal of separation of concerns to orthogonal aspects of user interfaces. For demonstration purposes, we will use the XForms standard of W3C as an example for an XML-based tool designed to create the proper abstractions in user interface design.

INTRODUCTION

Proper testing and quality control of software has been said to be one of the most neglected areas of software development. Whereas this streamlining of testing and quality control can reduce the budget and the time frame for delivery of projects, the quality of the delivered product is ultimately sacrificed. Although lack of testing and quality control can be the cause of failure, or at least customer dissatisfaction, of many software products, it has been tolerated in the world of PC applications. This is mostly due to the tolerance that the users have to buggy software with stability and functionality issues. However, this tolerance does not exist in the world of mobile application development. Mobile devices are always looked upon, even if they are not, as embedded devices. To the users, there is no difference between a way a PDA, a cell phone, and a VCR should operate: The user interface must be simple and there is zero tolerance for problems relating to security, stability, performance, and all of those other things that these same users have built an immunity toward during the usage of PCs.

INTRODUCTION

We have used the term active transactions in this text only for the lack of a better term that encapsulates the active participation of a computing system in interacting with the user. What we refer to as active transactions in this text includes all those behaviors exhibited by the system that are started autonomously by the application without the immediate and synchronous invocation of the software by the user. A subset of active transactions is often referred to as push-based technologies. Although the term “push” is better used in defining the implementation of the application, one part of the application could “poll” or “pull” and still exhibit active participation in interacting with the user.

What is important to note right away is that active transactions are not limited to push. Let us look at some examples of what we may mean by active transactions:

• An active mobile application that collects end-of-day field results can scan through the records of a salesperson's visits and if he or she has failed to fill out a time sheet with the appropriate visits, the application locates the salesperson by contacting him or her at all pertinent contact points. For example, the application may call the salesperson on the phone and ask him or her to say how many hours were worked and where the work was performed. The salesperson may have simply forgotten to log his or her hours; this process would not only contact the salesperson but also give the salesperson the opportunity to provide the required information during the same session. […]

INTRODUCTION

Security is always one of the biggest concerns when designing any application, but particularly distributed applications. Distributed applications operate over networks, involve multiple users, and have many other properties that make them more vulnerable to security breaches. Though there are stand-alone mobile applications, as we have discussed earlier in this text, most mobile applications, at their core, are distributed applications. Unfortunately, to date, there remain many unsolved problems with security concerns of mobile applications.

Our goal in this chapter will be to first introduce a taxonomy of mobile application security problems, look at few general approaches in solving these problems, and finally review those problems that remain unsolved. Security also tends to be a system-wide problem, not just an application problem, whether dealing with mobile or stationary applications. So, we are not out to show you sample code, standards, or specific techniques; such discussions are completely beyond the scope of our discussion. Our main purpose is to take a step back and look at the big picture of mobile application design and see where security concerns may be. Security is intimately bound to the design of the platform for which the mobile application is being built.

INTRODUCTION

The word replicate means “to produce a copy of itself” and originates from the Latin word replicates. The word synchronize is defined by the Webster dictionary to mean “to represent or arrange (events) to indicate coincidence or coexistence.” Synchronization and replication are two essential operations in distributed computing. Although synchronization can mean a variety of things, replication is typically used in reference to data. Like the literal definitions of synchronization and replication in the English language, their definitions within the field of computing are different but related. In this chapter, we will limit our discussion of synchronization and replication to data synchronization and data replication. As you may have already noted, we used the term synchronization, in Chapter 8, when synchronizing contents and actions transmitted across multiple communication channels. We are discussing synchronization in the context of data replication in this chapter.

Data replication, in its broadest sense, simply refers to copying data from one or more data storage locations to one or more other data storage locations. Note that these locations are virtual locations and not physical locations—it is not required for the virtual locations to be at different physical locations. The taxonomy of the types of replication technologies depends on the domain problem as well as the infrastructure on which replication is being performed. However, we can break nearly all data replication into two groups: complete replication and partial replication.

INTRODUCTION

Because of the depth of the design discussions in this text, we have had little chance of discussing coherent examples of mobile applications as applied to the various techniques introduced. The goal of this chapter will be to create a large fictitious project, based on a real project, define requirements for it, and then build the application using the techniques introduced. Obviously, we will not be able to use all of the techniques that we have discussed; there are far too many in this text. Nonetheless, we will aim at discussing as many as possible in reasonable detail.

The example we will be introducing will be in the field of automation. Namely, we will be creating an application to help an electrical repair crew with a variety of tasks in the field. We will start by working on the requirements, then create an architecture that satisfies the requirements, follow it up with a detailed level design, and work our way into implementation.

REQUIREMENTS DRIVING THE ARCHITECTURE

First, let us understand the basic needs of the customer for which we are building an application. The reader should know that this example is based on the needs of a real company, the Noor Electrical and Engineering Company, located in Costa Mesa, California.

INTRODUCTION

Much of what we have discussed in this text has been focused on design problems and high-level approaches to building mobile applications. We have intentionally stayed away from a more syntactical-driven approach because languages and tools are evolving rapidly in the space of mobile applications. We have looked at a variety of design patterns and architectural solutions that address the problems associated with mobile applications. In this chapter, we are going to take a step back, look at some very high level architectures, and discuss how we should use them in building our mobile applications.

In an abstract manner, a software system is to the domain problem it solves what the solution may be to a math problem. Through the years, mathematicians have refined “canonical” solutions to a wide variety of mathematical problems. “Canonical,” as defined by the Webster dictionary, is an adjective for something “conforming to a general rule or acceptable procedure.” Much of the purpose of various fields of engineering is to define these canonical “best practices and ways” of doing things for given problems. A large part of the field of software engineering involves defining canonical solutions for developing software applications so that every problem in building a software application does not have to be solved from scratch.

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.