Programming mobile devices an introduction for practitioners

Although programming is really fundamentally the same, be a program targeted to a mobile device environment or to a desktop, resources available in the lattercan be considered a lot more

MOBILE DEVICES

West Sussex PO19 8SQ, England Telephone ( +44) 1243 779777 Email (for orders and customer service enquiries): cs-books@wiley.co.uk

Visit our Home Page on www.wileyeurope.com or www.wiley.com

All Rights Reserved No part of this publication may be reproduced, stored in a retrieval system or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning or otherwise, except under the terms of the Copyright, Designs and Patents Act 1988 or under the terms of a licence issued by the Copyright Licensing Agency Ltd, 90 Tottenham Court Road, London W1T 4LP, UK, without the permission in writing of the Publisher Requests to the Publisher should be addressed to the Permissions Department, John Wiley & Sons Ltd, The Atrium, Southern Gate, Chichester, West Sussex PO19 8SQ, England, or emailed to permreq@wiley.co.uk, or faxed to ( +44) 1243 770620.

This publication is designed to provide accurate and authoritative information in regard to the subject matter covered It is sold on the understanding that the Publisher is not engaged in rendering professional services If professional advice or other expert assistance is required, the services of a competent professional should be sought.

Other Wiley Editorial Offices

John Wiley & Sons Inc., 111 River Street, Hoboken, NJ 07030, USA

Jossey-Bass, 989 Market Street, San Francisco, CA 94103-1741, USA

Wiley-VCH Verlag GmbH, Boschstr 12, D-69469 Weinheim, Germany

John Wiley & Sons Australia Ltd, 42 McDougall Street, Milton, Queensland 4064, Australia

John Wiley & Sons (Asia) Pte Ltd, 2 Clementi Loop #02-01, Jin Xing Distripark, Singapore 129809

John Wiley & Sons Canada Ltd, 6045 Freemont Blvd, Mississauga, Ontario, L5R 4J3, Canada

Wiley also publishes its books in a variety of electronic formats Some content that appears

in print may not be available in electronic books.

Anniversary Logo Design: Richard J Pacifico

Library of Congress Cataloging-in-Publication Data:

Mikkonen, Tommi.

Programming mobile devices : an introduction for practitioners /

Tommi Mikkonen.

p cm.

Includes bibliographical references and index.

ISBN 978-0-470-05738-4 (cloth : alk paper)

1 Mobile computing 2 Wireless communication systems I Title.

QA76.59M54 2007

004.165 – dc22

2006036202

British Library Cataloguing in Publication Data

A catalogue record for this book is available from the British Library

ISBN 978-0-470-05738-4 (Hb)

Typeset in 10/12 Times by Laserwords Private Limited, Chennai, India

Printed and bound in Great Britain by Antony Rowe Ltd, Chippenham, Wiltshire

This book is printed on acid-free paper responsibly manufactured from sustainable forestry

in which at least two trees are planted for each one used for paper production.

Contents

2.4 Memory Management in Mobile Java 37

4.1.2 Release Definition Using Dynamically Linked Libraries 106

4.7.1 Standard Structure of Dynamically Linked Libraries 120

5.5 Symbian OS and Concurrency 135

7.5 Symbian OS and Bluetooth Facilities 189

Foreword by Jan Bosch

In 1968, a NATO-organized conference was held during which several terms central

to our field were introduced, including software component, software architectureand software engineering This conference can be viewed as a milestone in turningthe programming of software systems from a craft to a true engineering discipline.Although we have not yet reached a level of proficiency that is on par with theolder engineering disciplines, enormous progress has been made in the last fourdecades, allowing us to build software systems, even complete ecosystems, that gofar beyond the dreams of the first software engineers This book marks a similarmilestone where the construction of mobile systems is moving from a craft to anengineering discipline

A key characteristic of any engineering discipline is that its professionals havethe ability to build and evolve systems that a layman would either not be capable

of or can only construct at a productivity level that is one or several orders of nitude lower The software engineering professional combines a deep insight intothe fundamental principles underlying the discipline, such as modularity, compos-ability, architecture, quality and user experience, as well as a detailed knowledge

mag-of the strengths and limitations mag-of the mechanical and hardware systems for whichthe software is developed and the tools used to develop software

Since a few months ago, my oldest son, age 9, is the proud owner of a Series 60Nokia mobile phone Interested in mathematics and computer games, his immediatequestions assorted to the ability to download software, arguably not productivityapplications but rather games, as well as the possibility to develop software for thephone himself Although our joint programming efforts have been limited to Python,rather than Java and C++ as discussed in this book, reflecting on the discussionswith my son reinforced my realization to what extent and at what speed computing

is moving to the edge of the network, specifically to mobile devices It is of course

a clich´e, but that is because it’s true!

The trends of convergence and mobility have a profound impact on society Thetypical adoption pattern for new use cases, e.g making a phone call, taking apicture, listening to music or reading and sending email, consists of three phases

At first, some use case is simply not feasible when using an integrated mobiledevice During the second stage, the use case becomes possible using a mobile

device, but it is the second choice for the user, because the experience of use andthe associated cost are significantly behind the stationary or single purpose devices.During the third stage, the specific use case matures and becomes the preferredchoice An illustrative example is the basic phone call Not available at all in most

of the western world until the early 1990s, mobile phones were initially used whereaccess to fixed phones was lacking and the importance of communication warranted

no delay Today we see ubiquitous use of mobile phones and most would preferusing a mobile phone even while standing next to a fixed phone There are numeroususe cases going through the same three-staged adoption process including taking andwatching pictures as well as video, sending and receiving messages, including SMS,email and instant messaging, gaming, access to enterprise applications and businessprocesses, surfing and searching the internet, watching television, participating inonline communities and, in general, interacting with the increasingly fusing digitaland physical worlds

Summarizing, we see convergence, i.e the integration of use cases earlier reservedfor single purpose devices, as a very strong trend set to continue Second, mobility,i.e transferring stationary and nomadic use cases to true mobile contexts, is freeingindividuals from the confines of specific locations, e.g an office desk, and specificcontexts, e.g sitting in an airport lounge with a laptop computer in, well, one’s lap.The ability to perform use cases when and wherever is not just good for productivity

in enterprise contexts, but also hugely satisfying from a personal perspective Thethird trend is that a mobile device is personal and defining the identity of its user to

an extent that goes far beyond desktop or laptop computers Consequently, we seemobile devices differ in size, form factor, input and output devices, available built-inhardware, e.g GPS, wireless LAN and Bluetooth, external accessories, interactionwith external devices, etc to extent far beyond traditional computing

In the discussion so far, I have tried to build a case for my conviction thatsoftware engineering has reached a next major milestone or perhaps even paradigmshift, to use Thomas Kuhn’s terminology, in the shift to mobile computing Eventhough there already is significant attention to the topic, we are only at the verybeginning of a major transformation in the information technology industry Thistransformation will require unprecedented degrees of adaptability, configurabilityand composability of software Already today, we can see that software developedfor mobile devices requires many versions in order to handle the variations betweendifferent mobile devices Second, as mobile software is used in many differentcontexts, software services and applications lack the ability to intelligently adjusttheir behaviour to the current context The simple example of a too loud ring tone

in a meeting or a too soft one while having a drink in a noisy bar illustrates this.Third, the user, being mobile, is constantly in the presence of a constantly changingset of stationary, nomadic or mobile devices that can be communicated with andused by the user’s mobile device to improve its user’s efficiency and ability toperform tasks Finally, mobile devices are personal and consequently require a highdegree of personalization that also affects the software on the device

The key activity central to the transformation to mobile computing is the ming of applications and services on mobile devices One can take three perspectives

program-to mobile software From the first perspective, nothing changes – software is ware and the same programming languages and basic principles apply From thesecond perspective, one could take the position that software for mobile devices is

soft-a step bsoft-ack from desktop softwsoft-are in thsoft-at the softwsoft-are engineer needs to consider,among others, resource constraints, user interaction, memory management and secu-rity solutions in a way that is similar to desktop software about a decade or moreago The third perspective that one can take, and that I feel is the more appropriateone, is that mobile software adds a unique and novel dimension to programmingthat has not been present before and that requires new programming practices andapproaches that, being early in this transformation, we are currently only starting

to explore and experiment with

The book that you are currently holding marks this milestone in the evolution

of software engineering in an exquisite manner The author, Tommi Mikkonen,has managed to strike the delicate balance between defining and discussing theprinciples that are fundamental to mobile software on the one hand and on the otherhand discuss the concrete details of programming languages, specifically mobileJava and Symbian C++, that can be used for programming Series 60 mobile devices.Since the Series 60 platform is the absolute market leader in open, mid- to high-endmobile devices, this book is a must-read for anyone interested in programming thesedevices The second advantage of the approach taken by the author is that the bookmanages to describe the details of specific releases of programming environmentswithout making the reader dependable on the specific version The principles helpprogrammers to easily evolve to subsequent versions, which appear at a very highrate, i.e multiple times per year

I warmly recommend this book to anyone interested in programming mobiledevices or interested in the state of the art and practice in this area We are at athe verge of a major transformation in the information technology industry towardsmobile computing and this book represents and outlines this future in clear anddetailed fashion that will leave the reader with a solid understanding of programmingfor mobile devices

Jan Bosch

Head of Software and Application Technologies Laboratory

Nokia Research Center

Helsinki, Finland

October 2006

Foreword by Antero Taivalsaari

I’ve known Tommi for several years, both as a colleague and as a friend Ever sincefirst meeting him, Tommi has been passionate about mobile devices and mobilesoftware development, not only as a professor and an academic researcher, but also

as an enthusiastic mobile software developer himself

Tommi has pioneered the teaching of mobile software development in Finland

He arranged the first university-level courses on mobile software development inFinland back in 2001, and in the past years he has instructed over a thousand students

to become proficient in this exciting and rapidly evolving field Unfortunately,the extensive lecture material that Tommi has prepared for his mobile softwaredevelopment courses has been available only in Finnish so far

In this book, Tommi makes his expertise in mobile software development able also to English-speaking software developers and students The book presents

avail-a comprehensive summavail-ary of avail-all the centravail-al avail-areavail-as in mobile softwavail-are development,ranging from fundamental topics such as memory and resource management toapplication design, networking, concurrency and security

Rather than focusing on specific technologies, devices or operating systems, thisbook takes a different approach and presents a summary of the component areasand issues that are common to all the mobile software platforms This should result

in a more “timeless” book that should stand the test of time well, unlike so manyother books that are outdated already by the time they come out of press

Knowing Tommi’s hectic schedule, this book represents a massive undertakingfrom Tommi’s part I am both impressed and envious about his ability to write such

a book, while working on so many other projects simultaneously I am confidentthat this book, for its part, will make the exciting area of mobile software develop-ment more approachable to a new generation of students and software developersworldwide

Dr Antero Taivalsaari

The original designer of the Java Platform, Micro Edition (Java ME)

Sun Microsystems Laboratories

The two latest decades have seen the introduction of more and more hand-heldgadgets being used for communication, as personal digital assistants, and simplyfor fun Personal digital assistants and mobile phones, followed by other types ofdevices, such as MP3 players, wrist-watches and the like, have been adopted forwide use in a relatively short period of time During the time frame of these decades,these devices have encountered a major change in their design; many devices werefirst fabricated predominantly with hardware, and they served a single purpose Morerecently, as the computing power in them has increased to the level of state-of-the-artdesktops only some years ago, the devices have become a programming environmentthat has emerged as a new domain of software development, to the extent that onecan even add new software developed by a designer independent of the devicemanufacturer Moreover, properly documented programming infrastructure has beenintroduced to allow one to introduce programming facilities to a proprietary systemwithout risking the features of the original device

The outcomes of improved facilities included in modern mobile devices are many.One can obviously introduce personalized features in devices, and thus create asystem that is best suited for some particular use Moreover, also mass customizationbecomes possible, as copying software once it has been completed is virtually free

In addition to personal use, also commercial use by enterprises becomes moretempting, as it is possible to create systems that extend from enterprises’ servers toall employees anywhere and any time Starting with email, already now a number

of enterprises are allowing more and more mobile personnel who can interact withcompany intranet and computing systems disregarding the restrictions of time andplace Moreover, the number of devices that forms the potential market for newapplications is huge, and being able to attract a fraction of it will lead to success.For a company implementing such devices, a major challenge is introduced in theform of transforming companies that develop hardware-based systems that includedsmall portions of software to predominantly software companies Firstly, software

in mobile devices should be robust and reliable to allow users to depend on it.Secondly, at the same time, software should be generic so that it can be used in

as many devices as possible to allow the largest user base possible to reduce theneed for new development Furthermore, changes that are evident due to evolving

hardware – more memory and processing power is regularly introduced in newerdevices, together with more sophisticated hardware features like a camera – shouldnot raise any compatibility issues but the same code should still run Finally, thesheer size of needed software has grown from a small portion to tens of megabytes

in some devices Managing this amount of software in a practical yet cost-effectivefashion is a grand challenge

Although programming is really fundamentally the same, be a program targeted

to a mobile device environment or to a desktop, resources available in the lattercan be considered a lot more forgiving in the sense that a smallish programmingerror resulting in garbaging some memory every now and then will probably nevercause a failure In contrast, a smallish error in a program targeted for a mobiledevice in a part that handles memory use can cause devastating effects due to therestricted resources of the device Therefore the quality of a design, including alsonon-functional properties, is even more important in the mobile setting As a result,designs will unfortunately be harder to compose Moreover, although the users ofmobile devices are often adopting usage patterns of embedded devices where theyexpect the device to react immediately, when using a programmable mobile device,delays in execution will inevitably occur as old applications are being shut down andnew ones started Luckily, when aiming at the development of a single application,ideally for a single device that one owns, the task is often not overly complex, butcan be performed with minor effort Moreover, people tend to be more forgivingwith regard to features specialized by and for themselves

Another way to look at programming of mobile devices is that in some ways

it is about putting together some pieces of embedded systems development In anembedded environment, one often has to compose programs in a memory-awarefashion, and take into account that the system can be active for a virtually unlim-ited time Moreover, in such settings, limited performance of hardware is commonlyassumed as a starting point In the workstation environment, on the other hand, long-living application development platforms are a commodity we have become used

to Furthermore, applications are designed with modifications and future additions

in mind An additional factor is the development time, which has led us to updateworkstation software on an almost daily basis; in fact, this can be automated Notsurprisingly, a similar need for constant management exists when considering theuse of mobile devices in a professional context However, there is an important dif-ference In the desktop setting, applications used by corporations can be managed

by an IT department that determines what kinds of applications can be allowed, aswell as the settings that can be used when running the application For a desktopenvironment, several systems are available for managing the application setting.However, such systems have become available for managing the applications inmobile devices only recently Furthermore, even when relying on device manage-ment, a user may still have full access to everything in the device, and even if thecorporation were able to install and configure an application, the user can remove

and reconfigure the application Overall, this can in fact be considered as a majorobstacle for using mobile applications in the corporate context.

Increasing dependability requirements of communication are also applicable tothe mobile setting It is obvious that mobile devices can already now run applica-tions that are extensions of existing systems benefiting from mobility In contrast,however, another perspective to using mobile devices as application environment is

to implement new, small, yet innovative systems that run only (or predominantly)

in mobile devices Currently, mobile games, which already now have established

a foothold as a major line of business, are probably the best representative of thisapproach Even with the current devices on the market, the number of potentialusers of such pieces of software is high, and therefore, the price of one downloadcan be relatively low The lower price of a sold application, say $10 per download,can be compensated with the larger number of downloads

Based on the above, programming of mobile devices differs from other domains inits characteristics This book is intended as a textbook on the principles of designingsoftware for mobile devices It is targeted at programmers who have experience inapplication development, but who have not worked with mobile devices before Thebook is based on experiences in working in the mobile devices industry as well asexperiences in teaching programming of mobile devices at Tampere University ofTechnology for several years Unlike many other textbooks on programming mobiledevices, the book is not intended to be used as a guide for immediately writingprograms or creating applications for a certain mobile platform Rather, the goal

is to introduce the main ideas and restrictions that are applicable in any mobileenvironment, thus enabling more generic use Moreover, the presentation does notbecome invalidated when a new version of a platform comes out that introducesdifferent facilities for some parts of the system Still, existing platforms are used

as examples on how to compose actual mobile software and on how the discussedprinciples are visible in practical implementations The discussion is structured as

an introduction to the mobile devices infrastructure in general, memory and itsuse, applications and their development, modularity based on dynamically linkedlibraries, concurrency, resources and their management, networking, and security.Each category will be addressed in a chapter of its own

Finally, let us consider a fundamental question: is there room for special practice

of mobile devices programming, or will it be similar to programming a desktop orlaptop computer? Even now, selecting a very computer-like mobile device for someparticular special-purpose application is an option Furthermore, with such devices,restrictions related to scarce resources can be relaxed, as it is possible to purchasemore memory in order to make the devices optimal for a particular application

In addition, also programming environments that are used in workstations havebeen proposed for the mobile environment, including Python and Visual Basic, forinstance A further option would be to use a system where an operating systemresembling those of PCs was available, like a restricted form of Windows andLinux, where application development can be more familiar Moreover, using for

example JavaScript inside a browser can also be considered yet another way tocompose programs for mobile devices in a fashion that does not differ much fromworkstation programming However, when aiming at the development of softwarethat can be used in practice in a maximum number of devices, it is more likelythat the restrictions remain, as the hardware forms a considerable cost factor andnot all phones include broadband connectivity, but only something more modest.Still they require software to operate Therefore, despite the advances in high-endphones and their connectivity features, as long as there is room for cost-effectivelymanufactured phones that are restricted in their performance, programming them in

a sophisticated fashion requires special skills

For being able to compose a book on programming mobile devices, I am grateful to

a number of people in my professional life I especially wish to express my sincerethanks to Dir Terho Niemi for putting me in charge of mobile device softwarearchitecture, which has initiated all this work; Prof Ilkka Haikala for convincing

me to apply for a professorship on mobile device programming; colleagues whohave enabled many inspiring discussions; a number of master and doctoral studentscomposing their theses on mobile systems programming; all the staff who haveparticipated in the class of mobile programming in one form or another; and all thestudents who have taken the class and thus contributed to improving the material

I also wish to thank a number of people who have reviewed different versions andparts of this book, including in particular Kari Syst¨a, Tino Pyssysalo, Antti Juustila,and Reino Kurki-Suonio Thanks to Symbian reviewers (Richard Harrison, RickMartin, Rahul Singh, Kostyantyn Lutsenko, Warren Day, Ioannis Dourus, AttilaVamos, Jonathan Yu, Leela Prasanna, Krishna Vasudevan, Kamal Singhania, KavitaKhatawate, Amit Shivnani, Kajal Ahuja) I also wish to thank Laserwords for theirhelp during the production process

Finally, I also have a personal life To this end, I wish to express my sincereapologies to my family Hopefully daddy will be around more often in the future

Tommi Mikkonen

Tampere, Finland

is becoming an option to aim at discussing the differences between workstation andembedded software and software that runs in mobile devices at a general rather than

at an implementation-specific level We believe that this leads to a longer lastingapproach, which will not be outdated when a new version of some particular mobileplatform is introduced, since the basic patterns and philosophy of a design are likely

to remain the same even if the platform version changes

Principally, the design of software that runs in a mobile device requires thatdevelopers combine the rules of thumb applicable in the embedded environment –memory awareness, turned on for an unlimited time, limited performance andresources in general, and security in the sense that the device should never mal-function to produce unanticipated costs or reveal confidential information even ifthe user behaves in an unanticipated fashion – with features that are needed inthe workstation environment – modifiability and adaptability, run-time extensions,and rapid application development For this combination, the designer must masterboth hardware-aware and application-level software, as well as the main principlesthat guide their design In order to compose designs where all these requirementsare satisfied, the designer is bound to use abstraction, which is the most powerfulweapon for dealing with complexity

1.1.1 Leaking Abstractions

Due to being such a powerful weapon for attacking software development, tion is also one of the most commonly used facilities in programming Systems we

abstrac-Programming Mobile Devices: An Introduction for Practitioners Tommi Mikkonen

 2007 John Wiley & Sons, Ltd

commonly use are full of abstractions, such as menus, databases, or file systems,

to name a few Moreover, we are good at managing abstractions we are familiarwith, and know how they should be used Therefore, the skill of programming in

a certain environment implies that one recognizes the basic abstractions applied inthe environment, and knows how the abstractions are intended to be used

Unfortunately, abstractions are not problem-free In particular, problems are nent when we face a new application domain or environment, such as mobiledevices Commonly used abstractions of programming may no longer be solid butthey can start to leak We will study this phenomenon in more detail in the following

immi-In principle, as argued by several authors, including Gannon et al (1981) andGabriel (1989) for instance, the user of an abstraction can overlook the details ofthe underlying implementation In practice, however, when composing programs,details of the underlying hardware and underlying infrastructure software used asthe implementation technique of a certain abstraction sometimes become visible

to the software developer or even to the user of the system We will call thisleaking abstraction.1However, without knowing the implementation, it is difficult tounderstand what happens when the program is executed and a sudden downgrade ofperformance occurs, for instance This makes the design more difficult, as revealingthe implementation can take alarming forms

As a sample leaking abstraction, we next consider null-terminated strings used inthe C programming language, for instance The following procedure can be used toconcatenate two such strings:

char * strcat(char * c1, char * c2)

{

int i, j;

while(i = 0; 0 != c1[i]; i++);

while(j = 0; 0 != c2[j]; j++, i++) c1[i] = c2[j];

From the functional viewpoint, using this kind of an operation appears perfect.However, from the practical viewpoint, the function is far from perfect, as in somecases the implementation of strings becomes visible to the user A problem isthat if we have to carry out one million concatenations to the same string, we

1 The term ‘leaking abstraction’ has been used in this meaning at least by Joel Spolsky (2004) Also the example

we use to demonstrate such abstractions originates from the same source.

will unnecessarily go through the same characters all over again as longer andlonger strings adopt the roles of c1 and c2 While the execution would result

in the correct outcome, the time needed for completing the execution would beconsiderably extended By observing this from a completed, running system, onemight be surprised since certain inputs would be slow to process, but by looking

at the actual design, one would immediately learn the obvious problem of thisimplementation

All non-trivial abstractions can be argued to leak to at least some extent (Spolsky2004) For instance, let us consider the TCP/IP protocol that provides an abstrac-tion of reliable communication; if the underlying communication infrastructure isterminally broken, there is no way the protocol can act in accordance to expecta-tions Similarly, although the SQL language is a powerful yet simple way to definedatabase queries, some queries can (and usually should) be optimized by takinginto account what takes place at the level of the implementation

Fundamentally, programming languages which are commonly available in themobile setting, such as C, C++, and Java, and their run-time infrastructures arealso non-trivial abstractions Therefore, they also have the potential to leak Inmany cases, leaking abstractions of programming languages and infrastructures thatare executed in mobile devices lead to problems in managing resources, memoryconsumption, and performance Therefore, in order to compose programs wherepotentially leaking abstractions form a minimal problem, the programmer musthave experience of working in a certain environment to create appropriate designs.Since expecting that all developers have experience is unrealistic, infrastructureshave been introduced where the most obvious traps will be automatically treated,

as well as tutorials and coding standards that aim at preventing the most obviousproblems associated with leaking abstractions

As already mentioned, mobile devices are restricted in terms of availableresources Therefore, in order to cope with leaking abstractions related to resources

of the device, implied by the used programming languages and execution ronments, the designer should understand what lies beneath the surface, becauseotherwise it is easy to use facilities of the language that are not well suited for such

envi-a restricted environment

1.1.2 Allocation Responsibility

Programming systems in mobile devices can treat complexity in two fundamentallydifferent ways On the one hand, the responsibility can be given to the program-mer, who then takes actions in order to manage resources, such as memory, diskspace, or communication bandwidth On the other hand, software infrastructure can

be defined for handling the resources without revealing the details to the mer, thus automating resource management from the programmer perspective Theabove strategies can be considered as white-box and black-box resource manage-ment approaches in the sense that white-box resource management is visible to the

program-developer in full, whereas black-box resource management hides its details fromthe programmer and aims at an automatic deallocation at an appropriate moment.

Programmer responsibility Fundamentally, making programmers responsible for

resource allocation results in a white-box approach to resource management that

is relying on programmers who are able to carry out designs in a fashion whereleaking of abstractions is not possible, or, at the very least, leaking is controlled

by them An obvious language where leaking of abstractions can be a problem inthe mobile environment is C++, as in many cases features of the language requirethorough knowledge of the underlying facilities and implementation techniques.Implementing programmer responsibility for potentially leaking abstractions cantake many forms On the one hand, one can define a coding standard that explainswhy certain types of designs should not be used, or are considered antipatterns,i.e., commonly applied solutions that bear some fundamental, well-known handicap(Brown et al 1998) On the other hand, one can introduce a coding standard thatdefines design guidelines for managing cases where leaking of abstractions is con-sidered most harmful or likely Moreover, in addition to knowing the guidelines,the programmer should also understand what kinds of problems the guidelines solveand why This usually calls for understanding of what happens at compilation andhow run-time infrastructure works

Infrastructure responsibility A black-box approach to resource management

means that the underlying programming infrastructure is supposed to liberate thedeveloper from considering potentially leaking abstractions Examples of environ-ments that operate in this way include Java and C#, which both can be used forprogramming mobile devices However, in practice the developer is still able to usethe properties of the infrastructure better, provided that she knows how the infras-tructure works and takes this into account when composing a design For instance,being able to compose designs that do not overly complicate the work of a garbagecollector in a virtual machine environment is helpful, as garbage collecting canseemingly stop the execution of a program for a short period of time in certainvirtual machine environments Thus, while the black-box approach hides resourcemanagement from the developer and the user, this abstraction leaks when garbagecollection is performed, as its side-effects may become observable by the user

To summarize, no matter whether the programmer or the infrastructure managesresources, the way programs are designed and written has an effect on their perfor-mance and resource consumption In the following, we discuss the most commonhardware-related issues that the developer is exposed to when designing applicationsfor mobile devices

1.2 Commonly Used Hardware and Software

To summarize the above discussion, programming languages and their run-timeinfrastructures can be considered as at least potentially leaking abstractions Suchleaks mean that the properties of hardware and lower-level software are revealed to

an application programmer in some cases Therefore, understanding their basics is

a prerequisite for considering how applications should be designed for the mobileenvironment

In the following, we give an overview to commonly used hardware and softwarefacilities inside a mobile device, whose restrictions can be considered as the maintechnical contributors of mobility (Satyanarayanan 1997) The subsections addresshardware, operating system concepts, application software, and the stack of softwarecomponents that often forms the run-time environment of a mobile device

1.2.1 Computing Hardware

The computing hardware of mobile devices can be expected to become more andmore standardized One important driver for this is the need to integrate all thesubsystems into one chip This saves development costs as well as energy con-sumption of the completed devices Figure 1.1 illustrates the main elements that aresignificant within the scope of this presentation

Processors and Accelerators

Fundamentally, a computer is a system that executes a program stored in memory.The processor loads instructions out of which the program is composed, and per-forms the tasks indicated by them Instructions are low-level commands that discussthe execution in terms of hardware available in the system For instance, loading thecontents of a memory location to a processor’s internal memory location, so-calledregister, adding the contents of two registers and storing the result in a third, and

Processor

Accelerator

Memory

CacheCachePeripherals

Figure 1.1 Commonly used hardware

int factor9() {

int index, result = 1;

for (index = 1; index < 10; index++)

Figure 1.2 Sample source code

storing the value in a register to a particular location in memory, are commonlyused instructions

Processors have different instruction sets, i.e., primitive operations that sors are capable of executing, and their properties can vary Probably the mostcommonly used main processor2 in mobile devices follows ARM (Acorn RISCmachine) design (Furber 2000) The ARM design is based on a 32-bit RISC3 pro-cessor that is produced by several vendors, and which has been integrated intomany more complex pieces of hardware, such as OMAP architecture by TexasInstruments On the software side, for instance Symbian OS runs on top of ARM,although also other processor alternatives have been considered in the design of theoperating system

proces-As an example, consider the following The piece of code given in Figure 1.2computes the factor of 9 When it is fed to a compiler, which in this case is a GCCcompiler for Symbian OS, the resulting assembly output is as listed in Figure 1.3.Similarly to most, if not all, assemblers, the output includes individual references tolocations in memory and to registers, as well as load and store instructions, whichform the low-level representation of any program

In addition to the main processor that is responsible for controlling the device

as a whole, many mobile devices include different types of accelerators and iliary processors, which in terms of hardware can be considered similar to otherprocessors, but they play a different role in the final system They are used forcoding and decoding of radio transmissions, and, more recently, to enable moresophisticated features such as three-dimensional graphics, for instance Moreover,

aux-in some cases a proprietary phone implementation can be extended with an cation processor that is to be used by additional applications without risking thefunctions of the proprietary phone Further possible processors include an accessprocessor (or a modem) that is dedicated for executing routines associated withtelecommunications

appli-2 In the terminology assumed here, the main processor is the processor that controls other parts of the system.

3 RISC stands for Reduced Instruction Set Computer, where only a restricted number of relatively simple and quickly executable instructions are offered In contrast, CISC, Complex Instruction Set Computer, refers to a more complex instruction set where also the execution times of different instructions can vary considerably.

@ Generated by gcc 2.9-psion-98r2 (Symbian build 540) for ARM/pe file "test.cpp"

Figure 1.3 Sample ARM code

Accelerators can be implemented using two different mechanisms, which areusing multi-purpose hardware, such as a digital signal processor (DSP), and single-purpose hardware Using the former is a more general design choice, as the hardwarecan be used for several tasks, whereas single-purpose hardware can only be usedfor the task it is designed for However, a DSP is usually a bigger design block

to be fitted in the device, and it requires more energy to run than a single-purposepiece of hardware Still, in general, DSPs have superior power consumption to

performance rate over general purpose processors in tasks that are well-suited forthem As an example, a study has shown that a typical signal processing task on

a RISC machine (StrongARM, ARM9E) requires three times as many cycles as aC55x DSP while consuming more than twice the power (Chaoui et al 2002) Thedownsides of DSPs are being solved by introducing more elaborated integrationschemes for off-the-shelf hardware Such integrated systems typically include amain processor, auxiliary DSP, memory, and additional interfaces While systemsexist where everything is integrated into a single chip, it is common that devices withnew features include several chips, each of which is dedicated for a certain purpose

A continuous trend is that an increasing number of features and improved gration techniques lead to more complex designs in the sense of architecture Inaddition, many hardware and platform manufacturers have been emphasizing mech-anisms related to power management, which also bear an effect on the complexity

inte-of the final design Moreover, such features are becoming more important, as readyand use times of mobile devices are meaningful properties for the consumer.When more and more advanced features that require more processing power areintroduced, clock frequency of the main processor must be increased Unfortunately,this leads to problems due to heat generation Therefore, one can consider that thecurrent approach, where there is a master processor and a small number of auxil-iaries, may need to be reconsidered As a solution, two contradicting approacheshave been proposed One is symmetric multiprocessing, which injects the complex-ity of programming to the operating system, and the other is the introduction of moreand more specialized auxiliaries that manage their internal executions themselves.Presented in Figure 1.4, both approaches can be justified with solid arguments, asdiscussed in the following

Symmetric multiprocessing (SMP) A system based on symmetric multiprocessing

consists of a number of similar processors that usually work in intimate connection

A common implementation is to hide them in the same operating system core,which allows them to balance load between each other This scheme gives anopportunity to save energy by shutting down some of the processors when the load

is low, and keeping all processors active when processor-intensive tasks are beingperformed Moreover, as all the processors can be hidden behind the same operatingsystem interface and have similar characteristics, a programmer can be offered anabstraction that can be conveniently used On the downside, multiprocessing can

be a relatively complex solution, when assuming that fundamentally the devicecan actually be a mobile phone, which by nature is a very specialized system.Moreover, the adequateness of the processor-level granularity as the basis of energymanagement can be questioned

Asymmetric multiprocessing The other alternative, the introduction of multiple

specialized pieces of hardware, also offers an increased performance Furthermore,the design of individual pieces of equipment can be eased, as they all perform someparticular tasks However, allocating tasks to different pieces of equipment cannot

be implemented in a straightforward fashion as with symmetric multiprocessing

App1Video

MCU1

App2AudioMCU2

Video

AuxP1

AudioAuxP2

App1App2MCU

Figure 1.4 Symmetric and asymmetric multiprocessor schemes

Instead, the programmer may be forced to participate in the allocation for adequateresults As a consequence, different devices relying on different sets of auxiliaryequipment must be supported Moreover, some devices may implement some equip-ment with additional software running on the main processor One possible resultfor this is to introduce abstractions that hide the complexity of hardware config-uration in a standard fashion Then, hardware support can be used whenever it isavailable, and software emulation will be used in devices that do not implementhardware acceleration Still, a considerable development effort must be invested inthe definition of interfaces that can be used with different implementations Fur-thermore, standardization is required to enable interoperability At present, the use

of accelerators can be seen as a step in this direction

Memory and Related Hardware

In current mobile devices, memory is usually internally constructed so that 32-bitmemory words are used Each word can be further decomposed to 4 bytes of 8 bits

In most cases, words are the main elements of memory in the sense that even if lessthan a word would be enough for a certain variable, a full word is still allocated

in practice for performance reasons There is, however, a possibility to allocateseveral variables to the same word, for instance Unfortunately, this may result indegraded performance, as it is usually faster to access memory when respectingmemory word boundaries Respecting the word boundary is commonly referred to

as (word) alignment

Several types of memory are used First, there is RAM (random access memory),which is used during the execution of programs for storing the loaded programs,and the state of the execution and variables related to it This type of memorycan be read and written The typical amount of RAM in a mobile device has beenincreasing rapidly, with typical figures reaching up to 64 or even 128 Mb Differenttypes of RAM can be considered, including static RAM (SRAM) and dynamicRAM (DRAM) SRAM preserves its state but is unfortunately usually expensive,and it is commonly used only in memory that is to be accessed quickly, such ascache, which can be considered as an intermediate storage used for storing memorylocations that the processor frequently accesses DRAM, on the other hand, is based

on transistors requiring constant attention from the rest of the system to preservetheir state, which consumes some energy DRAM is commonly used in the mobileenvironment, where probably the most common implementations rely on SDRAM(static DRAM) A benefit of this type of memory is that it can be run using thesame clock speed as the processor

Second, there is ROM (read only memory), which can be read but not rewritten.For instance, programs that are permanently stored in the device can be located

in ROM For execution, programs are usually first loaded to RAM for execution,although depending on the used chip set it is sometimes possible to execute pro-grams directly from ROM using so-called in-place execution In a mobile device,the amount of ROM can be 64 Mb or more, although flash memory, discussed inthe following, can also be used for a similar role

Third, many devices also contain permanent storage, although ROM and RAMwould be sufficient for many purposes The rationale is that if the battery is removed,

it is helpful that the data stored in the device remains unaltered Permanent storagecan be implemented in terms of a hard drive or as flash memory which maintaintheir information even if power is switched off Obviously, accessing disk is at least

a magnitude slower than accessing RAM or ROM Also physical characteristics

of hard drives have couraged the use of flash memory, as it is not as prone tomechanical failures

As already mentioned, flash memory is commonly used in mobile devices ing flash memory can be implemented such that it is relatively fast to read frommemory, but writing is usually slow The reason is that it is possible to turn singlebits from 1 to 0, but turning 0 to 1 can only be performed in groups of 64 kbfor instance, depending on the hardware implementation As a result, even a smallchange in a file can result in a complete rewrite of the whole file Two types offlash memory are to be considered, NOR and NAND flash memories NOR flashcan be used as direct memory space, and as ROM or RAM The latter is differ-ent from SDRAM in the sense that while an access to flash-based RAM can beslower, SDRAM requires constant attention of the processor to maintain the mem-ory active, which consumes energy In contrast to NOR flash, NAND flash behavesanalogously to a hard disk, and requires loading of code to memory before running

Access-it In comparison to other types of memory and hard disk, an additional restriction

Processor’s internal memory locations

CacheMain memoryDisk/flash memory for permanent dataRemote storage accessible via network

Figure 1.5 Memory hierarchy

is that only a very limited number of writes, say 100 000–1 000 000 rewrites, can

be performed on flash due to its exhaustion Similarly to hard disks, the use of flashrequires the management of memory usage, which can consume a considerableamount of memory in a large flash file system (Chang and Kuo 2004)

The memory types discussed above create a hierarchy of memories (Figure 1.5),where the size of the memory and access times vary; at the bottom of the hierarchy(processor’s internal registers or even cache) access is rapid and can be calculated

in some nanoseconds, but only a limited amount of such storage space is offered Incontrast, accessing main memory takes place on the order of tens of nanoseconds,and accessing a value in disk is even slower, up to the order of tens of milliseconds.Furthermore, using some memory available in the network is slow, but a virtuallyunrestricted amount of memory can be offered

In addition to the memory hierarchy, there is a special piece of hardware that

is associated with memory, although it is not directly included in memory Thememory management unit (MMU, omitted from the figure for simplicity) is moreconveniently implemented within the processor chip The purpose of this piece ofhardware is to enable using free locations in the memory for programs, disregardingtheir physical location The MMU then manipulates the memory shown to the pro-cessor such that the memory image is simplified in the sense that programs usuallyappear to be in continuous locations in the memory even if they are distributed inthe memory Similarly, programs can be located in different parts of the memoryduring different execution instances of programs MMU is also used for imple-menting memory protection enabled for processes, which we will discuss later inthis chapter Furthermore, MMU can also be used for implementing virtual mem-ory, where some parts of the system are saved to disk in terms of memory pageswhen additional memory is needed, and when the pages are used again, they can berestored from the disk As flash memory is not very convenient for such a purposedue to slow write operations and restricted number of write accesses, this scheme

is not commonly implemented in mobile devices However, the ability to freely

Free memory slots

Finally, two phenomena commonly associated with memory and its use are to beconsidered when composing programs for mobile devices These are fragmentationand garbaging The former means that memory is reserved such that some freememory remains unused between reserved blocks of memory (Figure 1.6) Whilefragmentation can in principle be handled by conjoining available free slices ofmemory to a bigger memory area, managing the lists of free and reserved slicescan become a burden for the operating system, and superfluously consume preciousmemory and processing time The latter refers to a situation where some dataallocated to the memory can no longer be deallocated by the program that hasallocated them, potentially reserving the memory locations until the execution ofthe program terminates, or, even worse, until the system is shut down

Subsystems

In addition to the hardware described above, several types of auxiliary subsystemscan be available, that require support from the hardware:

• Bluetooth is a short-range radio link that is used for cable replacement

• Radio interface is used for communicating with the mobile network Several widths and protocols can be used, including for instance GSM, GPRS, WCDMA,and WLAN, to name a few

band-• Keyboard (or touch screen) allows the user to input data and commands to thedevice

• Screen enables the user to read the information stored inside the device

• Additional memory for switching data between mobile devices using a memorystick that can be attached to a USB port or some other interface.

• Battery interface is used for managing the status of the energy source

The above list is by no means exhaustive, and additional hardware is easy to ine In principle, anything that can be connected to a mobile device can form a newsubsystem Moreover, whether the connection is permanent or dynamic via a localarea radio link, for instance, is becoming less important, as the capacity of connec-tions is becoming comparable due to the increased coverage and bandwidth Thisresults in an option to use implementations where a number of devices cooperate toperform some higher-level tasks At a lower level of abstraction, implementing thisrequires support from hardware in terms of I/O interfaces or the use of universalasynchronous receiver transmitters (UART), for instance

imag-In general, the characteristics of different subsystems are not directly visible

to the application software running in the device as such but via different types ofprogramming interfaces (or APIs, application programming interface), which makes

it possible to run the same software even if the hardware is upgraded or modified

in the design of a different type of device, which is common in the development

of product families However, lowest-level software must be adapted in order tobenefit from the new hardware

1.2.2 Low-Level Software Infrastructure

Kernel forms the core of an operating system Fundamentally, it is a machine that

is designed to manage the relationship of the underlying hardware and software thatuses its resources

For accessing hardware, kernels usually implement special modules called devicedrivers that can be used for creating a connection to the underlying subsystems andcommunicating with external equipment The usual way to implement such drivers isthat they send a request to the external subsystem, and the subsystem is responsiblefor serving the request When the request is served, the subsystem responds with aninterrupt that the kernel will acknowledge and serve with a corresponding interrupthandler, which contains the procedure for managing interrupts Device drivers can

be implemented in a layered fashion, where a physical layer handles the details ofthe actual hardware A logical level can then be introduced for handling the partsthat are common for all similar subsystems

When considering the connection between the kernel and other software, theresources of the former are a necessity to create applications Commonly usedterms are processes and threads, which we will address in the following

Processes can be considered as the units of resource reservation This allowsdesigns where the different resources allocated by programs are kept in isolationfrom one another This, however, requires support from the hardware in the form

of an MMU, which is usually included in processors used in mobile devices that

can be extended with new applications For devices that do not allow this and onlyinclude proprietary software, this may not be an option; instead, all processes canrun in the same memory space, when they can interfere with each other’s execution.Examples of resources that are managed by processes include memory in particular.

In addition, threads that are run within the memory space of the process are resourcesowned by the process In systems where threads could not be created separately,they were commonly associated with each other

Threads can be taken as units of execution Each thread can be considered as aconventional program that has a control flow, and some piece of code it executes.Threads belong to processes, and they can share resources and data structures withother threads inside the same process When the thread that is being executed ischanged to another by a special part of the kernel, the scheduler, the event is called acontext switch If the operating system can force a context switch even if the thread isnot ready for it, the scheduler is called pre-emptive, and if the thread must explicitlypause its execution, the scheduler is referred to as non-pre-emptive A pre-emptivescheduling policy is more flexible, but its performance ratio is usually recommended

to be kept at maximum 70% as otherwise some operations that are important for theuser can be delayed in favor of other operations Moreover, context switching canalso be executed repeatedly, if the performance ratio is increased In contrast, for anon-pre-emptive scheduler, a fixed order of executions is usually defined, which isless flexible but whose performance ratio can be close to 100% Two types of contextswitches can be considered; one takes place when a thread is changed to another butthe process hosting the threads remains the same, and the other when also the hostingprocess is altered The former is usually a lighter operation, but even this operation can

be considered expensive in the sense of performance The reason is that all the workperformed for pausing one thread and selecting and starting the other is overhead

1.2.3 Run-Time Infrastructure

In this subsection, we connect run-time infrastructure of programming languagesused in the mobile setting to the facilities of the underlying hardware and operatingsystem software

Allocating Memory for Programs and Variables

Perhaps the most straightforward consumers of memory are constants, which canusually be saved in ROM This saves some valuable RAM for other use

For variables, two locations can be imagined When a program is being run, itsmodifiable data must be stored in RAM, as the program can constantly alter thedata In contrast, when the execution is completed (or interrupted) data can be saved

to disk for further use in some later execution Saving data to disk is not simple,however Disk (or flash memory) access can be slow, which can be problematic forthe user Furthermore, it can be difficult for the user to realize when all data hasbeen saved and it is safe to turn off the device Therefore, the design of programs

Previous activation record

Next activation recordReturn addressReturn valueParametersLocal variablesOther information

Activationrecord

Figure 1.7 Activation record in a stack

should ensure timely saving of data in a fashion that is straightforward from the userperspective In many mobile devices, this has been implemented using a practicewhere dialogs imitate transactions of database systems, offering for instance ‘Done’selection for committing to the transaction in a fashion that is clear for the user.Inside RAM, two fundamentally different locations can be used for storing vari-ables, execution stack and heap Execution stack is a memory structure that managesthe control flow of a thread Every method call made by a thread results in an activa-tion record or a stack frame associated with the stack The structure of an activationrecord is illustrated in Figure 1.7 This data structure includes information related

to the management of the control flow, such as where to return once the execution

of the called method is finished and what method made the call.4 In addition, eachactivation record contains method parameters, the return value (if applicable), andvariables that are local to a method, which in some systems are called automaticvariables that are defined within the scope of the method As the stack is intimatelyassociated with the thread using it, the execution stack is usually local to a thread

In contrast to stack, which is structured in accordance to the execution of a gram in terms of activation records, heap is an unstructured memory pool fromwhich threads can allocate memory Unlike memory allocated from stack, wherethe execution flow manages memory consumption, memory allocated from the heap

pro-is under the responsibility of the programmer The accumulation of heap-allocatedmemory areas that are no longer accessible due to a programming error for instance

is a common cause of garbaging; then, a programmer allocates memory, but neverdeallocates it

4 Exact details of activation records differ slightly in different systems However, the principal idea remains the same.

The fashion in which the programmer composes programs determines where datastructures are allocated As an example on memory allocation from stack and fromheap, consider the allocation of the following data structure:

int SInStack() {Sample s;

}

int SInHeap() {Sample * s;

s = new Sample;

}

s.is.c

s

s.is.c

Stack HeapStack

Figure 1.8 Allocating memory for an object from stack and from heap

return address

heap(RAM)

Compilationand download

Figure 1.9 A program and associated infrastructural memory consumption

implicit allocations from heap even if a programmer assumes stack-based ment Such cases can lead to hard-to-trace errors that only become visible after anextended execution

treat-Programs are most commonly stored in ROM, flash, or disk, if such a facility isavailable in the device When a program is run, it is usually loaded from its location

in the storage to RAM for execution This enables the use of updates for fixing bugs

as well as the use of user-installed applications Figure 1.9 demonstrates one way

to allocate program and associated data in different memory locations

For ROM-based programs, in-place execution can be used This saves RAM, asthere is no need to create an additional copy of the program into it Usually thistype of approach is used when a program is located in ROM, and it is beneficial toalways run the program unaltered For instance, in-place execution could be used forthe introduction of a safety feature that enables (emergency) calls even if a mobiledevice is otherwise infected with a virus or some other malicious software For flashmemory, the type of flash used defines whether in-place execution can be used ornot As NOR flash can be used as direct memory space, programs stored to this type

of memory are candidates for in-place execution, but because NAND flash behavesanalogously to a hard disk, programs must always be loaded to RAM There are alsodownsides to using in-place execution First, it is impossible to upgrade the systemusing software modules that are downloaded after the installation Second, it isnot possible to use compression or encryption techniques, as the code must be exe-cutable as such Therefore, in-place execution is becoming less favorable than it was

in mobile devices where the option to download new applications was not available