Introduction to Mobile Computing Principles and Designing Mobile Applications
Mobile computing systems involve computing capabilities that can be utilized while on the move, leveraging wireless connectivity, small size, and mobile-specific functionalities. The history of mobile computing traces back to military origins and has evolved with technologies like GPS and wireless telephony. The advancements in networks have transformed the way we interact with computing devices. This field presents unique opportunities and challenges for software developers aiming to create innovative mobile applications.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
E N D
Presentation Transcript
MOBILE COMPUTING PRINCIPLES DESIGNING AND DEVELOPING MOBILE APPLICATIONS WITH UML AND XML REZA B FAR 1
Introduction to Mobile Computing 1.1 Introduction 1.2 Added Dimensions of Mobile Computing 1.3 Condition of the Mobile 1.4 Architecture of Mobile Software Applications Android Development- the basics 2
Introduction Mobile computing systems are computing systems that may be easily moved physically and whose computing capabilities may be used while they are being moved. Examples are laptops, personal digital assistants (PDAs), and mobile phones. Among the distinguishing aspects of mobile computing systems are their prevalent wireless network connectivity, their small size, the mobile nature of their use, their power sources, and their functionalities that are particularly suited to the mobile user. Because of these features, mobile computing applications are inherently different than applications written for use on stationary computing systems. 3
Introduction Abacus 500 B.C. Electricity . 1800's First Computers .. . Mid 1900's Networking 1960 1970 Satellites 1970 1980 Cellular Technologies 1980 2000 In the next section , we will look at those things that make the functional nature of mobile applications different than their stationary counterparts, take a survey of various development techniques that can be used to address these differences, and look at various basic technologies that allow us, as software developers, to create meaningful mobile applications in an extensible, flexible, and scalable manner. 4
Introduction greatest Because communications originated in the military, it is no surprise that one of the first applications of wireless communication for mobile computing systems was in displaying terrain maps of the battlefield. From this, the global positioning system (GPS) evolved so that soldiers could know their locations at any given time. Portable military computers were provided to provide calculations, graphics, and other data in the field of battle. In recent years, wireless telephony has become the major provider of a revenue stream that is being invested into improving the infrastructure to support higher bandwidth data communications. the advances in mobile 5
Wireless Mobile Recently, computer networks have evolved by leaps and bounds. These networks have begun to fundamentally change the way we live. Today, it is difficult to imagine computing without network connectivity. Networking and distributed computing are two of the largest segments that are the focus of current efforts in computing. Networks and computing devices are becoming increasingly blended together. Most mobile computing systems today, through wired or wireless connections, can connect to the network. . Because of the nature of mobile computing systems, network connectivity of mobile systems is increasingly through wireless communication systems rather than wired ones. And this is quickly becoming somewhat of a nonmandatory distinguishing element between mobile and stationary systems. 6
Wireless Mobile There are four pieces to the mobile problem: the mobile user, the mobile device, the mobile application, and the mobile network. We will distinguish the mobile user from the stationary user by what we will call the mobile condition The set of properties that distinguishes the mobile user from the user of a typical, stationary computing system. We will wrap the differences between typical devices, applications, and networks with mobile devices, applications, and networks into a set of properties that we will call the dimensions of mobility: the set of propertiesthat distinguishes the mobile computing system from the stationary computingsystem. 7
ADDED DIMENSIONS OF MOBILE COMPUTING The dimensions of mobility (Figure 1.3) are as follows: 1. location awareness, 2. network connectivity quality of service (QOS), 3. limited device capabilities (particularly storage and CPU), 4. limited power supply, 5. support for a wide variety of user interfaces, 6. platform proliferation, and 7. active transactions 8
Location Location : There are two general categories: localization and location sensitivity. Localizationis the mere ability of the architecture of the mobile application to accommodate logic that allows the selection of different business logic, level of work flow, and interfaces based on a given set of location information commonly referred to as locales. Localization is not exclusive to mobile applications but takes a much more prominent role in mobile applications. Localization is often required in stationary applications where users at different geographical locations access a centralized system. For example, some point-of-sale (POS) systems and e-commerce Web sites are able to take into account the different taxation rules depending on the locale of the sale and the location of the purchase. Whereas localization is something that stationary applications can have, location sensitivity s something fairly exclusive to mobile applications. 10
Location 11
Location The most well known location sensing system today is GPS. GPS-enabled devices can obtain latitude and longitude with accuracy of about 1 5 m. GPS has its roots in the military; until recently, the military placed restrictions on the accuracy of GPS available for public use. Most of these restrictions have now been lifted. GPS devices use triangulation techniques by triangulating data points from the satellite constellation that covers the entire surface of the earth. If a device does not have GPS capabilities but uses a cellular network for wireless connectivity, signal strength and triangulation or other methods can be used to come up with some approximate location information, depending on the cellular network. 12
Location The most well known location sensing system today is GPS. GPS-enabled devices can obtain latitude and longitude with accuracy of about 1 5 m. GPS has its roots in the military; until recently, the military placed restrictions on the accuracy of GPS available for public use. Most of these restrictions have now been lifted. GPS devices use triangulation techniques by triangulating data points from the satellite constellation that covers the entire surface of the earth. If a device does not have GPS capabilities but uses a cellular network for wireless connectivity, signal strength and triangulation or other methods can be used to come up with some approximate location information, depending on the cellular network. 13
Quality of Service Whether wired or wireless connectivity is used, mobility means loss of network connectivity reliability. Moving from one physical location to another creates physical barriers that nearly guarantee some disconnected time from the network. If a mobile application is used on a wired mobile system, the mobile system must be disconnected between the times when it is connected to the wired docking ports to be moved. Of course, it is always a question whether a docking port is available when required let alone the quality and type of the available network connectivity at that docking port. In the case of wireless network connectivity, physical conditions can significantly affect the quality of service (QOS). For example, bad weather, solar flares, and a variety of other climate- related conditions can negatively affect the (QOS). 14
Quality of Service When it comes to taking into account the QOS in most applications, certain functionality is expected of most mobile applications. For example, almost all mobile applications should know how to stop working when the application suddenly disconnects from the network and then resume working when it connects again. Other functionality may be desired but not required. For example, often QOS data are measured and provided by the network operator. For example, the real-time bandwidth available may be part of the data provided and refreshed on some time interval. Such data can be utilized to design applications that dynamically adapt their features and functionality to the available bandwidth. 15
Limited Device Storage and CPU No one wants to carry around a large device, so most useful mobile devices are small. This physical size limitation imposes boundaries on volatile storage, nonvolatile storage, and CPU on mobile devices. Though solid-state engineers are working on putting more and more processing power and storage into smaller and smaller physical volumes, nevertheless, as most mobile applications today are very rudimentary, there will be more and more that we will want to do with them. Today s mobile applications are resource-starved. So, although the designers of modern applications designed to run on personal computers (PCs) and servers continue to care less and less about system resources such as memory and processing power, it is a sure bet that memory limitations will be around for a long time for mobile applications because when it comes to mobile systems and devices, smaller is nearly always better 16
Limited Device Storage and CPU Limitations of storage and CPU of mobile devices put yet another constraint on how we develop mobile applications. For example, a mobile calendaring application may store some of its data on another node on the network (a PC, server, etc.). The contacts stored on the device may be available at any time. However, the contact information that exists only on the network is not available while the device is disconnected from the network. But, because the amount of data that can be stored on each type of device varies depending on the device type, it is not possible to allocate this storage space statically. Also, some information may be used more frequently than others; for example, the two weeks surrounding the current time may be accessed more frequently in the calendar application or there may be some contacts that are used more frequently. Mobile applications must be designed to optimize the use of data storage and processing power of the device in terms of the application use by the user. 17
Limited Power Supply We have already seen that the size constraints of the devices limit their storage capabilities and that their physical mobility affects network connectivity. For the same set of reasons that wireless is the predominant method of network connectivity for mobile devices, batteries are the primary power source for mobile devices. Batteries are improving every day and it is tough to find environments where suitable AC power is not available. Yet, often the user is constantly moving and devices are consuming more and more power with processors that have more and more transistors packed into them. The desirability of using batteries instead of an AC power source combined with the size constraints creates yet another constraint, namely a limited power supply. This constraint must be balanced with the processing power, storage, and size constraints; the battery is typically the largest single source of weight in the mobile. The power supply has a direct or an indirect effect on everything in a mobile device . 18
Extra DIMENSIONS OF MOBILE COMPUTING Varying User Interfaces: Stationary users use nonmobile applications while working on a PC or a similar device. The keyboard, mouse, and monitor have proved to be fairly efficient user interfaces for such applications. This is not at all true for mobile applications. Platform Proliferation: Because mobile devices are small and there is much less hardware in them than in a PC, they are typically less costly to assemble for a manufacturer. This means that more manufacturers can compete in producing these devices. Active Transactions: Most of today s stationary applications have a restriction that can reduce the benefits of a mobile application system enormously: The user of the system must initiate all interactions with the system. We call such systems passive systems because they are in a passive state, waiting for some external signal from the user to tell them to start doing some particular thing. 19
ARCHITECTURE OF MOBILE SOFTWARE APPLICATIONS The first step in building a software application, after the process of gathering requirements, is to lay down a high- level plan of what the application will be like when it is finished. Mobile applications, like any other software application, require such a high-level plan . We call this high-level plan of the mobile application a mobile software architecture. Our approach to architecture in this text will be bottom up: we will introduce a variety of design patterns, application architectures, and processes with each addressing some specific problem with mobile applications (next Figure). 20
CHAPTER 2 Introduction to Mobile Development Frameworks and Tools At its most primitive level, software is a set of instructions for hardware written in machine language. At a higher level, there are assemblers and higher level programming languages. There are frameworks, tools, and other methods of abstracting various aspects of software design that help us achieve one central goal: to handle complexity of software more reliability and faster. The biggest problem with software design and implementation is complexity and it is this complexity that leads into buggy systems, high cost of development, and long development cycles, and the existence of programming languages, frameworks, and other development tools is primarily to solve this very problem of software complexity. In other words, as one of the most fundamental software abstraction reduces complexity (at least theoretically). design concepts, 22
Introduction to Mobile Development Frameworks and tools for mobile application development are evolving based on the growth of architectural techniques and innovations that accommodate the dimensions of mobility. Although the purpose of any significant tool and framework used in mobile application development should be to reduce the complexity of the mobile application, all tools, regardless of their implementations, attempt to address the same issues. However, depending on the architectures that each may support, their implementation and usage significantly vary. Therefore, it makes sense to create the taxonomy of these tools based on the architectures. Let us begin by looking at the frameworks and tools that address mobile application development in a fully centralized architecture. 23
FULLY CENTRALIZED FRAMEWORKS AND TOOLS Developing fully centralized mobile applications differs from other fully centralized applications by virtue of QOS, limited power supply, active transactions, and location awareness Fully centralized mobile applications typically have custom-designed clients to perform specific tasks. So, the user interface on the devices used to access the centralized system is optimized to the task being performed. The software on such devices is typically embedded in nature and is designed to do only one thing. Also, because of this embedded nature of fully centralized mobile systems, resources of the device are not a concern in software development: The abilities of the client are known beforehand. Platform proliferation, once again for the same reason, is not a concern: Software systems in fully centralized mobile systems are all about the software on the fully centralized host; the client devices are dumb with little or no ability to perform dynamic computing tasks and what little software exists on them is embedded. Therefore, three of the dimensions of mobility namely platform proliferation, limited device capabilities, and support for a variety of user interfaces do not apply to fully centralized applications 24
N-TIER CLIENTSERVER FRAMEWORKS AND TOOLS As we discussed in Chapter 1, client server architectures allow us to enable communication between two applications with one application acting as the server and the other acting as the client. For mobile applications, the server may have special needs, but it is typically powerful enough to run a wide range of applications. For mobile applications, there may be special logic that treats the dimensions of mobility. Client applications, in the case of mobile development, are typically those being run on mobile devices. Writing large applications for the devices to serve as the client is typically not possible, primarily because of the limited resources on the devices and the large variety of them. So, more often than not, mobile applications are distributed. The state of the art, as of the date of authoring this text, in proven distributed computing systems are the N-tier client server architectures. 25
N-TIER CLIENTSERVER FRAMEWORKS AND TOOLS One of basic problems of application development that is magnified in mobile environments is code portability and mobility. The varieties of the so-called platforms (combination of hardware and operating systems) have prompted the creation of tools and frameworks such as Sun s Java Virtual Machine and Microsoft s Common Language Run-time. The primary goal of these tools is to give code more portability across platforms. The problem is magnified when considering the added factors that the variety of mobile devices dwarfs the variety among PC and server operating systems, that virtual machines tend to be large and require lots of memory and CPU cycles, and that, once more, they are designed primarily with the primary task of designing applications for stationary computing systems. Here, there are two factors that are inherently opposite in nature. First, we need a layer of software, be it a virtual machine or otherwise, that abstracts us away from the specificity of hardware. 26
Mobile Operating Systems and Virtual Machines Although Java tries to solve the proliferation problem by making the code portable between different platforms, there are other plausible approaches. One of these approaches is to create tools that make the applications native to one platform. Microsoft s .NET framework deploys such a strategy. The tools provided by the .NET framework allow the programmer to develop the application in a variety of languages supported by the framework. The individual applications are then compiled to code that can be executed on the same platform. Microsoft s creation of the .NET platform is spurred by economic reasons, namely to keep Windows as the dominant computer operating system. However, this does not imply that the tools provided by the .NET framework are either superior or inferior. It is simply a different technical approach whose merit should be judged by the implementing developers and the users of applications that use this platform. 27
Hardware-Specific Tools and Frameworks One way to deal with device proliferation is to avoid it! Device manufacturers can programmers to develop code that directly takes advantage of the device features and functionality. The notion of an operating system, in such case, is much different than what we typically think of as an operating system. The services offered by the operating system are few and very low level. The downside here is a tight coupling to a platform that, in turn, can translate to heavy reliance on the manufacturer of that platform. This is the approach that Qualcomm offers in its BREW platform. BREW is a framework designed to allow application developers program applications for devices based on Qualcomm s CDMA technology.We will look at CDMAfurther in Chapter 9. It is a physical layer communication protocol that offers very efficient use of the bandwidth available in a segment of the spectrum. allow the application 28
JAVA Today, it is widely accepted that Java as a programming language offers the most portable commercial environment for writing software applications. The success of Java has been mostly in providing standard Application Program Interfaces (APIs), a very thoughtfully designed infrastructure for OOP that prohibits many bad design and implementation habits such as multiple inheritance. Standard and open APIs offer a process of evolving a language that is open to many vendors. Furthermore, there exist implementations of the virtual machine and the native dependencies of the APIs for most popular operating systems. There are three major categories of Java APIs and virtual machines, namely J2ME, J2SE, and J2EE. Java offers three distinct features as a mobile application platform: 1. Java is an object oriented programming language. As any other programming language, it can be used to write applications. 2. Java offers complete code mobility and weak mobile agent ability. Java allows for platform-independent programming. 3. Java is a platform. First, Java, as with any other programming language, is just that: a programming language. It allows us to program a set of instructions. Perhaps just as importantly Java is somewhat of a vendor-neutral language-based platform. Java seems to have solved the problem that has plagued many other programming languages in the past: the lack of standardizing libraries. 29
BREW Qualcomm s BREW (Binary Run-time Environment for Wireless) gives application developers a new and different approach in producing mobile applications. BREW is built directly into the hardware. It is offered as an API to access the CDMA, GSM/GPRS, or UMTS chip sets that provide the support for it. But, it is primarily intended for the variations of CDMA, a technology owned and licensed by Qualcomm. BREW applications can be written on a PC using the BREW Software Development application is developed, it must be tested, and then deployed. Deployment of BREW applications is a process done jointly telecommunications carriers and not just the developer. Kit (SDK). Once the by Qualcomm and 30
set of applications of BREW 1. BREW MIF Editor: Every BREW module, defined as the classes that make up one or more BREW applications, has an associated Module Information File (MIF). 2. BREW Device Configurator: This is a stand-alone application that allows developers to make up their own handset by configuring a vanilla mobile phone and specifying the behaviour of the keys, the look and feel of the screen, and other specifics of the device. 3. BREW Emulator: For those who have designed and implemented any mobile application, it is obvious that one of the most difficult steps in the development process is the incremental unit testing. 4. BREW Image Authoring Tool: There is an image authoring tool that allows creation of images for BREW. This tool can use PNG or BMP files. 5. BREW ARM Compiler: Many mobile devices are based on the ARM or Strong- ARM hardware platform (registered trademarks of ARM Corporation). 31
set of applications of BREW 6. Image Converter: The tool set provides an image converter to convert 4-bit bitmaps to 2-bit bitmaps as BREW only supports 2-bit bitmaps because of the limited resources on mobile devices 7. BREW Resource Editor: If you have worked with Java or C++ to build GUI client-side applications, then you are familiar with the concept of a resource bundle. Resource files in BREW are a collection of images, strings, and dialog look-and-feel components that allow changing the look and feel of the application for internationalization and similar purposes without changing the code base. The BREW Resource Editor gives the developers a GUI interface to manage the resource files. 8. BREW Pure Voice Converter: This command line utility allows the developers to convert wave files (audio) to Pure Voice files or vice versa. 9. BREW AppLoader: This tool allows the developer to deploy an application on a handset through a PC connector. This is a testing and not a deployment tool. 10. BREW Grinder: The Grinder generates a variety of inputs and tests the application. 11. BREW TestSig Generator and AppSigner: The TestSig tool provides the developer a mechanism to generate a test Class ID. 32
WINDOWS CE An operating system is the master control program that enables the hardware by abstracting it to the application via drivers [Development tools for Mobile and Embedded Applications 2002]. Microsoft s various products revolve around different versions of an operating system. The versions that concern us, the mobile application developers, most are Windows CE and Embedded Windows XP. Windows CE has been around since 1997 and Embedded Windows XP is being released at the time of authoring this text. These two operating systems are designed for two different purposes. There are different flavors of the Windows CE operating systems, of course, depending on the hardware platform. Some of these flavors are the Pocket PC, Windows CE .NET, and Pocket PC 2002. These flavors largely depend on the commercial bundling of different feature sets and hardware platforms with which they are shipped (such as Compaq s IPAQ). Embedded Windows XP, in contrast, is a subset of the desktop version of Windows XP components. Development for Embedded Windows XP is a bit more straightforward than developing for Windows CE. 33
Microsoft provides tools to build applications for each environment too. These are as follows 1. Embedded Visual C++:This is a tool set separate from Visual Studio, the typical development environment for PC-based Windows applications. It allows for authoring mobile applications in C++. 2. Embedded Visual Embedded Visual Basic: This tool provides the ability to write applications using Visual Basic. 3. Smart Device Extensions for .NETSmart Device Extensions for .NET: The .NET application programming platform, the newest set of tools for building Microsoft Windows-based applications, can be complemented with a set of extensions that allow developers to author .NET applications for mobile devices. 4. Microsoft Mobile Internet Toolkit: This is really a server-side frame work We will discuss it along with the other publishing tools later in this chapter. 34
WAP Wireless Application Protocol (WAP) is the single framework most used in building mobile applications today. Despite all of its initial high promises, its lack of meeting those promises, and being written off for dead, WAP seems to have survived the critics and continues to improve. WAP, which was initially intended to be as pervasive for wireless and mobile applications as HTTP has been for the Web, never achieved the level of success initially expected. However, to date, WAP has the largest install base of all open application development platforms (second to NTT Docomo s closed and proprietary i- mode system) on mobile phones, meaning that WAP is installed on more mobile phones than any other software. WAP shares some similarities to HTTP. From its inception to now, it has become more and more like HTTP. WAP 1.x and WAP 2.x are significantly different with WAP 1.x being the basis for nearly all the current installations in the market today and WAP 2.x being the target platform for WAP devices during 2003 and 2004. Let us go over some basics about WAP. 35
WAP 1. WAP is intended for thin clients. Much like HTTP, the designers of WAP 1.x were thinking about a thin-client technology: a case where nearly all logic is calculated on the server and very simple display instructions are bundled in some mark up language to be displayed by the client. 2. WAP is built on its own lower level communication protocol. Whereas HTTP assumes the existence of TCP/IP (which in turn provides persistent connections), WAP is built on its own set of communication protocols that wrap around TCP, UDP, or a variety of other possible protocol implementations. 3. Typical deployment of WAP includes a proxy or a gateway. Wireless carriers (also referred to as bearer networks) like to have control of every single incoming and outgoing bit of data that travels on their network. This is understandable as usage time is the typical mechanism for billing. 4. WAP is a complete framework for mobile applications. Whereas most tools created for development of applications treat a part of the mobile application chain, WAP treats, or at least attempts to treat, all parts of the mobile equation. 36
Chapter3.XML: The Document and Metadata Format for Mobile Computing The Extensible Markup Language XML is a subset of the Standard Generalize Markup Language (SGML) specified in ISO standard 8879. SGML was created to create and maintain complex and portable documents to be used in highly scalable systems in a non proprietary manner to any particular vendor. XML has become a key technology in the development of content for the World Wide Web. Today, with the birth of Web services, it is used for more than its original purpose of representing documents. 37
XML and Mobile Applications 1. Mobile applications should understand and be able to manipulate XML content. As content on the Internet, and other networks, moves into an XML format, it is very desirable that a given mobile application can handle XML. How the XML is handled is of particular interest. Although the task of parsing and interpreting the XML can be done on the mobile device itself, or some proxy such as an application server that processes all content for the device, issues such as performance become of paramount concern 2. Mobile applications use XML to facilitate their implementations. For example, XML documents can be used by mobile applications to exchange data; configuration of a device or a server may be encapsulated in an XML file; some protocols such as WAP use XML as the means for presentation. There are countless places where mobile applications and related frameworks can use XML internally. 39
DOM Parsing The Document Object Model (DOM) is the tree representation of all of the XML elements. Every element becomes a node and nodes. Nodes can have children to support nesting of nodes in the same way as an XML element can have other elements. The mapping of DOM to UML is very simple. Every node is an object, an instance of a class. The XML attributes are the object attributes and the children nodes are encapsulated data members. ADOM parser written in an object-oriented language such as Java, C++, or C# goes through the entire XML document and creates a tree of nodes, with the nodes being objects. DOM parsers are also required to preserve the order of elements. There may be meaning in the order of elements. The same is not required of attributes. 40
SAX Parsing SAX (Simple API for XML) creates a series of events as it parses through the XML document instead of creating an object model of the entire document in memory. There are two key advantages that SAX offers over DOM: 1. Most of the time, we do not need all of the information in the document. So, the object model desired does not have to have every element and attribute of the document. A custom object model in this case is more efficient. We can write a custom object model and a driver that catches the SAX events as the SAX parser reads through the document and emits them and fills up the custom object model. 2. We do not have to wait for the entire document to be processed before using the contents of the document. For very large documents, DOM becomes problematic as it has to load the entire document into memory before it makes its contents available. In contrast, as a SAX parser progresses through processing a document, it emits events; therefore, by nature, processing of the information it allows immediate 41
XML WEB SERVICES Web Services are a prime example of an organic, as opposed to a synthetic, evolution in technology. They exist because the HTTP protocol is ubiquitous: Just about everyone today has access to the Web. Web services build on the HTTP protocol methods, mostly GET and POST, to build an RPC (Remote Procedure Call) that allows two systems to exchange messages over HTTP. But, why not use CORBA, COM, JINI, or other distributed computing protocols? XML based Web services are not efficient: They convert binary to text to convert it back to binary again. This is a weak point of XML based Web services when it comes to dealing with mobile applications. However, there are work- arounds Web services are a text-based MMI (Machine-to-Machine Interface). However, they are simple to build and they take advantage of the ubiquity of the Web. Protocols such as CORBA have failed in becoming ubiquitous. Other protocols such as COM are proprietary to a platform. The platform of Web services is the Web. Regardless of level of efficiency, those two aspects alone create an economic reason for Web services to exist. Another consideration that accompanies the use of Web services (typically HTTP based though they can be based on other protocols such as SMTP) is security. 42
Web Services and Mobile Applications 1. Web Service Proxy: The infrastructure of mobile applications can use Web services for messaging. For example, a given system may allow mobile users to find someone s phone number through a directory service and subsequently get the driving directions to that person s place of residence. These two functions, finding the phone number and the driving directions, may be fulfilled by two different systems, each implemented in a different environment. So, the back end for our mobile system may use Web services to connect to each one of these systems and retrieve the information we need to return it to us. The interface between the back-end system and the device remains consistent and can be implemented through whatever communication protocol may be necessary. This is the more likely scenario for most systems. 43
Web Services and Mobile Applications 2. Direct Connection to Web Services: Mobile devices with more resources can directly access the network through the use of Web services (see Figure 3.4). Of course, this requires a considerably advanced mobile device as we have to have very efficient XML parsing as well as the ability to write substantial applications that application of XML that supports the particular Web service to which the mobile device must connect to. implement the 44
KEY XML TECHNOLOGIES FOR MOBILE COMPUTING Some standard applications of XML have been specifically designed with mobile applications in mind. Standardization of such applications of XML is required to provide interoperability between disparate systems. As we mentioned previously, mobile applications should be able to handle XML content. This may mean parsing the content to take some actions based on the content, transforming the content for various user interfaces, or using XML as the metadata for handling various types of content. There are a set of standards by W3C and proprietary recommendations by various vendors that apply for these cases. We will recommended by W3C as they are typically more encompassing than proprietary recommendations. focus on standards 45
XML-Based User Interface Technologies for Mobile Applications As we previously mentioned, one of the first markup languages to be pervasively used was HTML. Most of the Web documents today exist in HTML. HTML is an application of SGML, but it is not very clean. XHTML is an attempt at cleaning up the HTML syntax and providing a version of HTML that is an application of XML. XHTML will replace HTML past version 4.01 and it is an approved W3C standard. One of the biggest problems that HTML presented was that it was not designed to be used by a wide variety of user interface types. HTML was designed with minimum requirements of a color screen of 640 480 pixels and the PC in mind. Though some considerations were made for screens that did not display graphics, not much else was available to the developer. Also, HTML was not strict enough in enforcing syntax. So, programmatic changes to HTML to make it fit various devices was not possible without making assumptions (which in turn create bugs). 46
XML-Based User Interface Technologies for Mobile Applications XForms allows us to build user interfaces with a focus on the interactions and data exchanges between the user and the user interface as opposed to specific types of user interface. XForms allows us to separate concerns among presentation logic specific presentation logic specific to the device, the data exchanged between the user and the system, and the interaction flow. It is natural for XML to be the core of a user interface system infrastructure, mobile or not. XML is textual, structured, and document based. Those three elements are of utmost importance in building a human computer interface (HCI). There are other applications of XML for mobile application infrastructures as well. We will now briefly introduce some applications of XML that control flow of interactions. to the application, the 47
Putting XML to Work XML has already become the de facto document standard for exchange of human readable data. Whether such will be the case for machine-to-machine communication is questionable; nevertheless, such applications exist and their popularity is increasing. In this chapter, we looked at a variety of XML-based technologies and took an introductory glimpse at their use in mobile applications. Then, we looked at RDF, a part of the Semantic Web that is becoming pervasively more crucial to mobile applications. We followed this by discussions of CC/PP and UAProf as applications of RDF and XML for mobile applications and finished off the chapter by talking about XML to UML mapping. The significance of XML to mobile applications is twofold: First, it offers a well-formed and deterministically modifiable format for human-readable data, and second, it offers interoperability. 48
Chapt.5 Generic User Interface Development such as issues related to human factors are not well defined. In this text, we will use terminologies outlined by ECMA (European Association), W3C (World Wide Web Consortium), or similar non-commercial standards bodies. It is also important to note that user interface development for mobile applications is a new field; therefore, there will be occasions when these bodies have not decided on a standard way of addressing these problems. In such cases, we will build some logical vocabulary as built on top of the existing standards and as decided by the author of this book. The first step in moving forward is to ask ourselves, Why do we want to build generic user interfaces? First, mobile applications are typically used by a wider array of operating environments and systems than a PC. Because there is such a wide array of end clients for mobile applications, we need to be able to adapt the application quickly, if not in real time, with very little or no additional development effort. Computer Manufacturer 49
User Interface Development A software application is started by a person, another software application, application, or a combination thereof. A demon program may invoke a server application at a particular time; this is an example of a software application being invoked by another software application. The operating system itself is an application that may hardware/software driven application, turning the computer on, providing power to the CPU, and allowing the initialization software permanently stored on the hardware to invoke an operating system. Excluding artificially intelligent systems, all software applications, at some point and perhaps through a long line of succession, are either started or scheduled to start by a person a user. a hardware be started by a 50
