![2 Programming Mobile Devices
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 familiar
with, and know how they should be used. Therefore, the skill of programming in
a certain environment implies that one recognizes the basic abstractions applied in
the environment, and knows how the abstractions are intended to be used.
Unfortunately, abstractions are not problem-free. In particular, problems are immi-
nent when we face a new application domain or environment, such as mobile
devices. Commonly used abstractions of programming may no longer be solid but
they can start to leak. We will study this phenomenon in more detail in the following.
In principle, as argued by several authors, including Gannon et al. (1981) and
Gabriel (1989) for instance, the user of an abstraction can overlook the details of
the underlying implementation. In practice, however, when composing programs,
details of the underlying hardware and underlying infrastructure software used as
the implementation technique of a certain abstraction sometimes become visible
to the software developer or even to the user of the system. We will call this
leaking abstraction.1
However, without knowing the implementation, it is difficult to
understand what happens when the program is executed and a sudden downgrade of
performance occurs, for instance. This makes the design more difficult, as revealing
the implementation can take alarming forms.
As a sample leaking abstraction, we next consider null-terminated strings used in
the C programming language, for instance. The following procedure can be used to
concatenate 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];
c1[i+1] = 0;
return c1;
}
The logic of the operation is that first, we browse all the characters of string c1,
and then copy all the characters of string c2 to its end. Moreover, it is assumed
that c1 is large enough to host also the characters of c2, which is not explicitly
expressed in the procedure but is an obvious built-in assumption.
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 some
cases the implementation of strings becomes visible to the user. A problem is
that 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.](https://image.slidesharecdn.com/489937-250521213754-c36335f2/85/Programming-Mobile-Devices-An-Introduction-For-Practitioners-Tommi-Mikkonen-31-320.jpg)
![Introduction 7
@ Generated by gcc 2.9-psion-98r2 (Symbian build 540) for ARM/pe
.file "test.cpp"
.gcc2_compiled.:
.text
.align 0
.global factor9__Fv
factor9__Fv:
@ args = 0, pretend = 0, frame = 8
@ frame_needed = 1, current_function_anonymous_args = 0
mov ip, sp
stmfd sp!, {fp, ip, lr, pc}
sub fp, ip, #4
sub sp, sp, #8
mov r3, #1
str r3, [fp, #-20]
mov r3, #1
str r3, [fp, #-16]
.L2:
ldr r3, [fp, #-16]
cmp r3, #9
ble .L5
b .L3
.L5:
ldr r3, [fp, #-20]
ldr r2, [fp, #-16]
mul r3, r2, r3
str r3, [fp, #-20]
.L4:
ldr r3, [fp, #-16]
add r2, r3, #1
str r2, [fp, #-16]
b .L2
.L3:
ldr r3, [fp, #-20]
mov r0, r3
b .L1
.L1:
ldmea fp, {fp, sp, lr}
bx lr
Figure 1.3 Sample ARM code
Accelerators can be implemented using two different mechanisms, which are
using 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 hardware
can be used for several tasks, whereas single-purpose hardware can only be used
for 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-purpose
piece of hardware. Still, in general, DSPs have superior power consumption to](https://image.slidesharecdn.com/489937-250521213754-c36335f2/85/Programming-Mobile-Devices-An-Introduction-For-Practitioners-Tommi-Mikkonen-36-320.jpg)
![adjectives. In Japanese the adjective is frankly part of the inflection of the
verb, a special mood, so that every verb is also an adjective. This brings
us close to nature, because everywhere the quality is only a power of
action regarded as having an abstract inherence. Green is only a certain
rapidity of vibration, hardness a degree of tenseness in cohering. In
Chinese the adjective always retains a substratum of verbal meaning. We
should try to render this in translation, not be content with some
bloodless adjectival abstraction plus "is."
Still more interesting are the Chinese "prepositions," they are often post-
positions. Prepositions are so important, so pivotal in European speech
only because we have weakly yielded up the force of our intransitive
verbs. We have to add small supernumerary words to bring back the
original power. We still say "I see a horse," but with the weak verb "look,"
we have to add the directive particle "at" before we can restore the
natural transitiveness.[5]
Prepositions represent a few simple ways in which incomplete verbs
complete themselves. Pointing toward nouns as a limit they bring force to
bear upon them. That is to say, they are naturally verbs, of generalized or
condensed use. In Aryan languages it is often difficult to trace the verbal
origins of simple prepositions. Only in "off" do we see a fragment of the
thought "to throw off." In Chinese the preposition is frankly a verb,
specially used in a generalized sense. These verbs are often used in their
specially verbal sense, and it greatly weakens an English translation if
they are systematically rendered by colorless prepositions.
Thus in Chinese: By = to cause; to = to fall toward; in = to remain, to
dwell; from = to follow; and so on.
Conjunctions are similarly derivative, they usually serve to mediate
actions between verbs, and therefore they are necessarily themselves
actions. Thus in Chinese: Because = to use; and = to be included under
one; another form of "and" = to be parallel; or = to partake; if = to let
one do, to permit. The same is true of a host of other particles, no longer
traceable in the Aryan tongues.
Pronouns appear a thorn in our evolution theory, since they have been
taken as unanalyzable expressions of personality. In Chinese even they
yield up their striking secrets of verbal metaphor. They are a constant
source of weakness if colorlessly translated. Take, for example, the five](https://image.slidesharecdn.com/489937-250521213754-c36335f2/85/Programming-Mobile-Devices-An-Introduction-For-Practitioners-Tommi-Mikkonen-57-320.jpg)
![forms of "I." There is the sign of a "spear in the hand" = a very emphatic
I; five and a mouth = a weak and defensive I, holding off a crowd by
speaking; to conceal = a selfish and private I; self (the cocoon sign) and
a mouth = an egoistic I, one who takes pleasure in his own speaking; the
self presented is used only when one is speaking to one's self.
I trust that this digression concerning parts of speech may have justified
itself. It proves, first, the enormous interest of the Chinese language in
throwing light upon our forgotten mental processes, and thus furnishes a
new chapter in the philosophy of language. Secondly, it is indispensable
for understanding the poetical raw material which the Chinese language
affords. Poetry differs from prose in the concrete colors of its diction. It is
not enough for it to furnish a meaning to philosophers. It must appeal to
emotions with the charm of direct impression, flashing through regions
where the intellect can only grope.[6] Poetry must render what is said, not
what is merely meant. Abstract meaning gives little vividness, and fullness
of imagination gives all. Chinese poetry demands that we abandon our
narrow grammatical categories, that we follow the original text with a
wealth of concrete verbs.
But this is only the beginning of the matter. So far we have exhibited the
Chinese characters and the Chinese sentence chiefly as vivid shorthand
pictures of actions and processes in nature. These embody true poetry as
far as they go. Such actions are seen, but Chinese would be a poor
language and Chinese poetry but a narrow art, could they not go on to
represent also what is unseen. The best poetry deals not only with
natural images but with lofty thoughts, spiritual suggestions and obscure
relations. The greater part of natural truth is hidden in processes too
minute for vision and in harmonies too large, in vibrations, cohesions and
in affinities. The Chinese compass these also, and with great power and
beauty.
You will ask, how could the Chinese have built up a great intellectual
fabric from mere picture writing? To the ordinary western mind, which
believes that thought is concerned with logical categories and which
rather condemns the faculty of direct imagination, this feat seems quite
impossible. Yet the Chinese language with its peculiar materials has
passed over from the seen to the unseen by exactly the same process](https://image.slidesharecdn.com/489937-250521213754-c36335f2/85/Programming-Mobile-Devices-An-Introduction-For-Practitioners-Tommi-Mikkonen-58-320.jpg)
![which all ancient races employed. This process is metaphor, the use of
material images to suggest immaterial relations.[7]
The whole delicate substance of speech is built upon substrata of
metaphor. Abstract terms, pressed by etymology, reveal their ancient
roots still embedded in direct action. But the primitive metaphors do not
spring from arbitrary subjective processes. They are possible only
because they follow objective lines of relations in nature herself. Relations
are more real and more important than the things which they relate. The
forces which produce the branch-angles of an oak lay potent in the acorn.
Similar lines of resistance, half curbing the out-pressing vitalities, govern
the branching of rivers and of nations. Thus a nerve, a wire, a roadway,
and a clearing-house are only varying channels which communication
forces for itself. This is more than analogy, it is identity of structure.
Nature furnishes her own clues. Had the world not been full of
homologies, sympathies, and identities, thought would have been starved
and language chained to the obvious. There would have been no bridge
whereby to cross from the minor truth of the seen to the major truth of
the unseen. Not more than a few hundred roots out of our large
vocabularies could have dealt directly with physical processes. These we
can fairly well identify in primitive Sanskrit. They are, almost without
exception, vivid verbs. The wealth of European speech grew, following
slowly the intricate maze of nature's suggestions and affinities. Metaphor
was piled upon metaphor in quasi-geological strata.
Metaphor, the revealer of nature, is the very substance of poetry. The
known interprets the obscure, the universe is alive with myth. The beauty
and freedom of the observed world furnish a model, and life is pregnant
with art. It is a mistake to suppose, with some philosophers of æsthetics,
that art and poetry aim to deal with the general and the abstract. This
misconception has been foisted upon us by mediæval logic. Art and
poetry deal with the concrete of nature, not with rows of separate
"particulars," for such rows do not exist. Poetry is finer than prose
because it gives us more concrete truth in the same compass of words.
Metaphor, its chief device, is at once the substance of nature and of
language. Poetry only does consciously[8] what the primitive races did
unconsciously. The chief work of literary men in dealing with language,
and of poets especially, lies in feeling back along the ancient lines of
advance.[9] He must do this so that he may keep his words enriched by](https://image.slidesharecdn.com/489937-250521213754-c36335f2/85/Programming-Mobile-Devices-An-Introduction-For-Practitioners-Tommi-Mikkonen-59-320.jpg)
![does. Its correlated verbs compose it. At bottom these verbs are
transitive. Such verbs may be almost infinite in number.
In diction and in grammatical form science is utterly opposed to logic.
Primitive men who created language agreed with science and not with
logic. Logic has abused the language which they left to her mercy. Poetry
agrees with science and not with logic.
The moment we use the copula, the moment we express subjective
inclusions, poetry evaporates. The more concretely and vividly we express
the interactions of things the better the poetry. We need in poetry
thousands of active words, each doing its utmost to show forth the
motive and vital forces. We can not exhibit the wealth of nature by mere
summation, by the piling of sentences. Poetic thought works by
suggestion, crowding maximum meaning into the single phrase pregnant,
charged, and luminous from within.
In Chinese character each work accumulated this sort of energy in itself.
Should we pass formally to the study of Chinese poetry, we should warn
ourselves against logicianized pitfalls. We should beware of modern
narrow utilitarian meanings ascribed to the words in commercial
dictionaries. We should try to preserve the metaphoric overtones. We
should beware of English grammar, its hard parts of speech, and its lazy
satisfaction with nouns and adjectives. We should seek and at least bear
in mind the verbal undertone of each noun. We should avoid "is" and
bring in a wealth of neglected English verbs. Most of the existing
translations violate all of these rules.[10]
The development of the normal transitive sentence rests upon the fact
that one action in nature promotes another; thus the agent and the
object are secretly verbs. For example, our sentence, "Reading promotes
writing," would be expressed in Chinese by three full verbs. Such a form
is the equivalent of three expanded clauses and can be drawn out into
adjectival, participial, infinitive, relative or conditional members. One of
many possible examples is, "If one reads it teaches him how to write."
Another is, "One who reads becomes one who writes." But in the first
condensed form a Chinese would write, "Read promote write." The
dominance of the verb and its power to obliterate all other parts of
speech give us the model of terse fine style.](https://image.slidesharecdn.com/489937-250521213754-c36335f2/85/Programming-Mobile-Devices-An-Introduction-For-Practitioners-Tommi-Mikkonen-63-320.jpg)
![I have seldom seen our rhetoricians dwell on the fact that the great
strength of our language lies in its splendid array of transitive verbs,
drawn both from Anglo-Saxon and from Latin sources. These give us the
most individual characterizations of force. Their power lies in their
recognition of nature as a vast storehouse of forces. We do not say in
English that things seem, or appear, or eventuate, or even that they are;
but that they do. Will is the foundation of our speech.[11] We catch the
Demiurge in the act. I had to discover for myself why Shakespeare's
English was so immeasurably superior to all others. I found that it was his
persistent, natural, and magnificent use of hundreds of transitive verbs.
Rarely will you find an "is" in his sentences. "Is" weakly lends itself to the
uses of our rhythm, in the unaccented syllables; yet he sternly discards it.
A study of Shakespeare's verbs should underlie all exercises in style.
We find in poetical Chinese a wealth of transitive verbs, in some way
greater even than in the English of Shakespeare. This springs from their
power of combining several pictorial elements in a single character. We
have in English no verb for what two things, say the sun and moon, both
do together. Prefixes and affixes merely direct and qualify. In Chinese the
verb can be more minutely qualified. We find a hundred variants
clustering about a single idea. Thus "to sail a boat for purposes of
pleasure" would be an entirely different verb from "to sail for purposes of
commerce." Dozens of Chinese verbs express various shades of grieving,
yet in English translations they are usually reduced to one mediocrity.
Many of them can be expressed only by periphrasis, but what right has
the translator to neglect the overtones? There are subtle shadings. We
should strain our resources in English.
It is true that the pictorial clue of many Chinese ideographs can not now
be traced, and even Chinese lexicographers admit that combinations
frequently contribute only a phonetic value. But I find it incredible that
any such minute subdivision of the idea could have ever existed alone as
abstract sound without the concrete character. It contradicts the law of
evolution. Complex ideas arise only gradually, as the power of holding
them together arises. The paucity of Chinese sound could not so hold
them. Neither is it conceivable that the whole list was made at once, as
commercial codes of cipher are compiled. Therefore we must believe that
the phonetic theory is in large part unsound. The metaphor once existed
in many cases where we can not now trace it. Many of our own](https://image.slidesharecdn.com/489937-250521213754-c36335f2/85/Programming-Mobile-Devices-An-Introduction-For-Practitioners-Tommi-Mikkonen-64-320.jpg)
![etymologies have been lost. It is futile to take the ignorance of the Han
dynasty for omniscience.[12] It is not true, as Legge said, that the original
picture characters could never have gone far in building up abstract
thought. This is a vital mistake. We have seen that our own languages
have all sprung from a few hundred vivid phonetic verbs by figurative
derivation. A fabric more vast could have been built up in Chinese by
metaphorical composition. No attenuated idea exists which it might not
have reached more vividly and more permanently than we could have
been expected to reach with phonetic roots. Such a pictorial method,
whether the Chinese exemplified it or not, would be the ideal language of
the world.
Still, is it not enough to show that Chinese poetry gets back near to the
processes of nature by means of its vivid figure, its wealth of such figure?
If we attempt to follow it in English we must use words highly charged,
words whose vital suggestion shall interplay as nature interplays.
Sentences must be like the mingling of the fringes of feathered banners,
or as the colors of many flowers blended into the single sheen of a
meadow.
The poet can never see too much or feel too much. His metaphors are
only ways of getting rid of the dead white plaster of the copula. He
resolves its indifference into a thousand tints of verb. His figures flood
things with jets of various light, like the sudden upblaze of fountains. The
prehistoric poets who created language discovered the whole harmonious
framework of nature, they sang out her processes in their hymns. And
this diffused poetry which they created, Shakespeare has condensed into
a more tangible substance. Thus in all poetry a word is like a sun, with its
corona and chromosphere; words crowd upon words, and enwrap each
other in their luminous envelopes until sentences become clear,
continuous light-bands.
Now we are in condition to appreciate the full splendor of certain lines of
Chinese verse. Poetry surpasses prose especially in that the poet selects
for juxtaposition those words whose overtones blend into a delicate and
lucid harmony. All arts follow the same law; refined harmony lies in the
delicate balance of overtones. In music the whole possibility and theory of
harmony is based on the overtones. In this sense poetry seems a more
difficult art.](https://image.slidesharecdn.com/489937-250521213754-c36335f2/85/Programming-Mobile-Devices-An-Introduction-For-Practitioners-Tommi-Mikkonen-65-320.jpg)
![How shall we determine the metaphorical overtones of neighboring
words? We can avoid flagrant breaches like mixed metaphor. We can find
the concord or harmonizing at its intensest, as in Romeo's speech over
the dead Juliet.
Here also the Chinese ideography has its advantage, in even a simple
line, for example, "The sun rises in the east."
The overtones vibrate against the eye. The wealth of composition in
characters makes possible a choice of words in which a single dominant
overtone colors every plane of meaning. That is perhaps the most
conspicuous quality of Chinese poetry. Let us examine our line.
Sun Rises (in the) East.
The sun, the shining, on one side, on the other the sign of the east,
which is the sun entangled in the branches of a tree. And in the middle
sign, the verb "rise," we have further homology; the sun is above the
horizon, but beyond that the single upright line is like the growing trunk-
line of the tree sign. This is but a beginning, but it points a way to the
method, and to the method of intelligent reading.
[1] The apology was unnecessary, but Professor Fenollosa saw fit to make it, and I
therefore transcribe his words.—E.P.
[2] Style, that is to say, limpidity, as opposed to rhetoric.—E.P.
[3] Even Latin, living Latin had not the network of rules they foist upon unfortunate
school-children. These are borrowed sometimes from Greek grammarians, even as I
have seen English grammars borrowing oblique cases from Latin grammars. Sometimes
they sprang from the grammatizing or categorizing passion of pedants. Living Latin had
only the feel of the cases: the ablative and dative emotion.—E.P.
[4] A good writer would use "shine" (i.e., to shine), shining, and "the shine" or "sheen",
possibly thinking of the German "schöne" and "Schönheit"; but this does not invalidate
Prof. Fenollosa's next contention.—E.P.
[5] This is a bad example. We can say "I look a fool", "look", transitive, now means
resemble. The main contention is however correct. We tend to abandon specific words](https://image.slidesharecdn.com/489937-250521213754-c36335f2/85/Programming-Mobile-Devices-An-Introduction-For-Practitioners-Tommi-Mikkonen-66-320.jpg)
![like resemble and substitute, for them, vague verbs with prepositional directors, or
riders.—E.P.
[6] Cf. principle of Primary apparition, "Spirit of Romance".—E.P.
[7] Compare Aristotle's Poetics.—E.P.
[8] Vide also an article on "Vorticism" in the Fortnightly Review for September, 1914.
"The language of exploration" now in my "Gaudier-Brzeska."—E.P.
[9] I would submit in all humility that this applies in the rendering of ancient texts. The
poet in dealing with his own time, must also see to it that language does not petrify on
his hands. He must prepare for new advances along the lines of true metaphor that is
interpretative metaphor, or image, as diametrically opposed to untrue, or ornamental
metaphor.—E.P.
[10] These precautions should be broadly conceived. It is not so much their letter, as the
underlying feeling of objectification and activity, that matters.—E.P.
[11] Compare Dante's definition of "rectitudo" as the direction of the will, probably taken
from Aquinas.—E.P.
[12] Professor Fenollosa is well borne out by chance evidence. The vorticist sculptor
Gaudier-Brzeska sat in my room before he went off to the war. He was able to read the
Chinese radicals and many compound signs almost at pleasure. He was of course, used
to consider all life and nature in the terms of planes and of bounding lines. Nevertheless
he had spent only a fortnight in the museum studying the Chinese characters. He was
amazed at the stupidity of lexicographers who could not discern for all their learning the
pictorial values which were to him perfectly obvious and apparent. Curiously enough, a
few weeks later Edmond Dulac, who is of a totally different tradition, sat here, giving an
impromptu panegyric on the elements of Chinese art, on the units of composition, drawn
from the written characters. He did not use Professor Fenollosa's own words, he said
"bamboo" instead of "rice". He said the essence of the bamboo is in a certain way it
grows, they have this in their sign for bamboo, all designs of bamboo proceed from it.
Then he went on rather to disparage vorticism, on the grounds that it could not hope to
do for the Occident, in one life-time, what had required centuries of development in
China.—E.P.](https://image.slidesharecdn.com/489937-250521213754-c36335f2/85/Programming-Mobile-Devices-An-Introduction-For-Practitioners-Tommi-Mikkonen-67-320.jpg)
Programming Mobile Devices An Introduction For Practitioners Tommi Mikkonen
- 1. Programming Mobile Devices An Introduction For Practitioners Tommi Mikkonen download https://ebookbell.com/product/programming-mobile-devices-an- introduction-for-practitioners-tommi-mikkonen-979874 Explore and download more ebooks at ebookbell.com
- 2. Here are some recommended products that we believe you will be interested in. You can click the link to download. Mobile Javascript Application Development Bringing Web Programming To Mobile Devices Adrian Kosmaczewski https://ebookbell.com/product/mobile-javascript-application- development-bringing-web-programming-to-mobile-devices-adrian- kosmaczewski-2587164 Programming Android Java Programming For The New Generation Of Mobile Devices Second Edition 20120926 Zigurd Mednieks https://ebookbell.com/product/programming-android-java-programming- for-the-new-generation-of-mobile-devices-second- edition-20120926-zigurd-mednieks-2611638 Programming With 64bit Arm Assembly Language Single Board Computer Development For Raspberry Pi And Mobile Devices Stephen Smith https://ebookbell.com/product/programming-with-64bit-arm-assembly- language-single-board-computer-development-for-raspberry-pi-and- mobile-devices-stephen-smith-11144382 Programming Mobile Robots With Aria And Player A Guide To C Objectoriented Control 1st Edition Amanda Whitbrook Auth https://ebookbell.com/product/programming-mobile-robots-with-aria-and- player-a-guide-to-c-objectoriented-control-1st-edition-amanda- whitbrook-auth-4194488
- 3. Programming The Mobile Web 1st Edition Maximiliano Firtman https://ebookbell.com/product/programming-the-mobile-web-1st-edition- maximiliano-firtman-2530694 Programming The Mobile Web 2nd Edition Maximiliano Firtman https://ebookbell.com/product/programming-the-mobile-web-2nd-edition- maximiliano-firtman-4139520 Programming With Mobile Applications Android Ios And Windows Phone 7 1st Thomas J Duffy https://ebookbell.com/product/programming-with-mobile-applications- android-ios-and-windows-phone-7-1st-thomas-j-duffy-4981184 Programming The Mobile Web Maximiliano Firtman https://ebookbell.com/product/programming-the-mobile-web-maximiliano- firtman-42302740 Programming The Mobile Web M Flirtman https://ebookbell.com/product/programming-the-mobile-web-m- flirtman-4093816
- 10. PROGRAMMING MOBILE DEVICES AN INTRODUCTION FOR PRACTITIONERS Tommi Mikkonen Tampere University of Technology, Finland
- 11. Copyright 2007 John Wiley & Sons Ltd, The Atrium, Southern Gate, Chichester, 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.
- 12. Contents Foreword by Jan Bosch xi Foreword by Antero Taivalsaari xv Preface xvii Acknowledgments xxi 1 Introduction 1 1.1 Motivation 1 1.1.1 Leaking Abstractions 1 1.1.2 Allocation Responsibility 3 1.2 Commonly Used Hardware and Software 4 1.2.1 Computing Hardware 5 1.2.2 Low-Level Software Infrastructure 13 1.2.3 Run-Time Infrastructure 14 1.2.4 Software Stack 20 1.3 Development Process 21 1.4 Chapter Overview 23 1.5 Summary 25 1.6 Exercises 25 2 Memory Management 27 2.1 Overview 27 2.2 Strategies for Allocating Variables to Memory 27 2.2.1 Static Allocation 28 2.2.2 Stack 28 2.2.3 Heap 30 2.3 Design Patterns for Limited Memory 31 2.3.1 Linear Data Structures 31 2.3.2 Basic Design Decisions 32 2.3.3 Data Packing 34 2.3.4 Discussion 36
- 13. vi Contents 2.4 Memory Management in Mobile Java 37 2.4.1 Motivation 37 2.4.2 Rules of Thumb for Mobile Java 39 2.5 Symbian OS Memory Management 42 2.5.1 Naming Conventions 43 2.5.2 Descriptors 45 2.5.3 Exceptions 46 2.5.4 Combining Exceptions and Allocation 48 2.5.5 Cleanup Stack 49 2.5.6 Two-Phase Construction 52 2.5.7 Factory Methods for Two-Phase Construction 54 2.5.8 Using Symbian Conventions 55 2.6 Summary 57 2.7 Exercises 58 3 Applications 61 3.1 What Constitutes an Application? 61 3.2 Workflow for Application Development 62 3.2.1 Scoping 63 3.2.2 Performance Considerations 63 3.2.3 User Interface Design 64 3.2.4 Data Model and Memory Concerns 65 3.2.5 Communications and I/O 65 3.3 Techniques for Composing Applications 66 3.3.1 Event-Based Programming 67 3.3.2 Model-View-Controller as the Application Architecture 68 3.3.3 Auxiliary Files 70 3.3.4 Managing Applications 71 3.3.5 Practicalities 73 3.4 Application Models in Mobile Java 73 3.4.1 Configurations 74 3.4.2 Profiles 76 3.4.3 Sample MIDP Java Application 80 3.5 Symbian OS Application Infrastructure 84 3.5.1 Overview 85 3.5.2 Resource File 86 3.5.3 Attaching Application to Run-Time Infrastructure 88 3.5.4 Application 89 3.5.5 Document 91 3.5.6 User Interface 93 3.5.7 View 96
- 14. Contents vii 3.5.8 Engine 98 3.5.9 Generating Installation Package 102 3.6 Summary 102 3.7 Exercises 103 4 Dynamic Linking 105 4.1 Overview 105 4.1.1 Motivation 105 4.1.2 Release Definition Using Dynamically Linked Libraries 106 4.1.3 Required Implementation Facilities 107 4.1.4 Static versus Dynamic DLLs 107 4.1.5 Challenges with Using DLLs 108 4.2 Implementation Techniques 109 4.3 Implementing Plugins 111 4.3.1 Plugin Principles 111 4.3.2 Implementation-Level Concerns 113 4.4 Managing Memory Consumption Related to Dynamically Linked Libraries 114 4.4.1 Memory Limit 114 4.4.2 Interface Design Principles 115 4.4.3 Merging Elements 117 4.5 Rules of Thumb for Using Dynamically Loaded Libraries 118 4.6 Mobile Java and Dynamic Linking 118 4.7 Symbian OS Dynamic Libraries 120 4.7.1 Standard Structure of Dynamically Linked Libraries 120 4.7.2 Managing Binary Compatibility 122 4.7.3 ECOM Component Model 124 4.8 Summary 125 4.9 Exercises 126 5 Concurrency 127 5.1 Motivation 127 5.2 Infrastructure for Concurrent Programming 127 5.2.1 Threading 128 5.2.2 Inter-Thread Communication 128 5.2.3 Common Problems 129 5.3 Faking Concurrency 130 5.4 MIDP Java and Concurrency 132 5.4.1 Threading in Virtual Machine 132 5.4.2 Using Threads in Mobile Java 132 5.4.3 Problems with Java Threading 135
- 15. viii Contents 5.5 Symbian OS and Concurrency 135 5.5.1 Overview 135 5.5.2 Sample Active Object 141 5.5.3 Active Objects and Applications 145 5.5.4 Problems with Active Objects 145 5.6 Summary 146 5.7 Exercises 147 6 Managing Resources 149 6.1 Resource-Related Concerns in Mobile Devices 149 6.1.1 Overview 149 6.1.2 Grouping Resource Managers 151 6.1.3 Separating Resource Managers 152 6.1.4 Resource-Hosting Virtual Machine 155 6.2 Common Concerns 156 6.2.1 Overview 156 6.2.2 Extension and Adaptation 156 6.2.3 Performance 158 6.2.4 Energy Management 159 6.2.5 Internal Resource Management 160 6.3 MIDP Java 161 6.3.1 Basic Elements 162 6.3.2 Compatibility between Different Devices 164 6.4 Symbian OS 165 6.4.1 Servers as a Mechanism of Resource Management 165 6.4.2 Implementing Servers 167 6.4.3 Adapting Servers to Hardware 171 6.4.4 Problems with Servers 173 6.5 Summary 173 6.6 Exercises 174 7 Networking 177 7.1 Introduction 177 7.1.1 Basic Connectivity 177 7.1.2 Stateful and Stateless Systems 178 7.1.3 Infrastructure Assisted or Ad-hoc Networking? 180 7.2 Design Patterns for Networking Environment 181 7.3 Problems with Networking Facilities and Implementations 184 7.4 MIDP Java and Web Services 185 7.4.1 Web Services Overview 185 7.4.2 Using Web Services with Mobile Java 187
- 16. Contents ix 7.5 Symbian OS and Bluetooth Facilities 189 7.5.1 Bluetooth Introduction 189 7.5.2 Bluetooth in Symbian 191 7.6 Summary 194 7.7 Exercises 194 8 Security 197 8.1 Overview 197 8.2 Secure Coding and Design 198 8.2.1 Mindset for Secure Design 198 8.2.2 Sample Security-Related Design Patterns 199 8.3 Infrastructure for Enabling Secured Execution 201 8.3.1 Goals for Security Features 201 8.3.2 Supporting Hardware and Software Facilities 203 8.4 Security Features in MIDP Java 205 8.4.1 Low-Level Security 205 8.4.2 Application-Level Security 206 8.4.3 End-to-End Security 208 8.4.4 Problems 208 8.5 Symbian OS Security Features 208 8.5.1 Low-Level Security 209 8.5.2 Application-Level Security 209 8.5.3 End-to-End Security 211 8.5.4 Problems with Symbian OS Security Features 212 8.6 Summary 212 8.7 Exercises 213 References 215 Index 219
- 18. 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 architecture and software engineering. This conference can be viewed as a milestone in turning the 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 the older engineering disciplines, enormous progress has been made in the last four decades, allowing us to build software systems, even complete ecosystems, that go far beyond the dreams of the first software engineers. This book marks a similar milestone where the construction of mobile systems is moving from a craft to an engineering discipline. A key characteristic of any engineering discipline is that its professionals have the 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 mag- nitude lower. The software engineering professional combines a deep insight into the fundamental principles underlying the discipline, such as modularity, compos- ability, architecture, quality and user experience, as well as a detailed knowledge of the strengths and limitations of the mechanical and hardware systems for which the 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 60 Nokia mobile phone. Interested in mathematics and computer games, his immediate questions assorted to the ability to download software, arguably not productivity applications but rather games, as well as the possibility to develop software for the phone himself. Although our joint programming efforts have been limited to Python, rather than Java and C++ as discussed in this book, reflecting on the discussions with 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é, but that is because it’s true! The trends of convergence and mobility have a profound impact on society. The typical adoption pattern for new use cases, e.g. making a phone call, taking a picture, 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 mobile device. During the second stage, the use case becomes possible using a mobile
- 19. xii Foreword by Jan Bosch device, but it is the second choice for the user, because the experience of use and the associated cost are significantly behind the stationary or single purpose devices. During the third stage, the specific use case matures and becomes the preferred choice. 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 where access to fixed phones was lacking and the importance of communication warranted no delay. Today we see ubiquitous use of mobile phones and most would prefer using a mobile phone even while standing next to a fixed phone. There are numerous use cases going through the same three-staged adoption process including taking and watching pictures as well as video, sending and receiving messages, including SMS, email and instant messaging, gaming, access to enterprise applications and business processes, surfing and searching the internet, watching television, participating in online communities and, in general, interacting with the increasingly fusing digital and physical worlds. Summarizing, we see convergence, i.e. the integration of use cases earlier reserved for 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 freeing individuals from the confines of specific locations, e.g. an office desk, and specific contexts, 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. The third 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 see mobile devices differ in size, form factor, input and output devices, available built-in hardware, e.g. GPS, wireless LAN and Bluetooth, external accessories, interaction with external devices, etc. to extent far beyond traditional computing. In the discussion so far, I have tried to build a case for my conviction that software engineering has reached a next major milestone or perhaps even paradigm shift, to use Thomas Kuhn’s terminology, in the shift to mobile computing. Even though there already is significant attention to the topic, we are only at the very beginning of a major transformation in the information technology industry. This transformation will require unprecedented degrees of adaptability, configurability and composability of software. Already today, we can see that software developed for mobile devices requires many versions in order to handle the variations between different mobile devices. Second, as mobile software is used in many different contexts, software services and applications lack the ability to intelligently adjust their 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 changing set of stationary, nomadic or mobile devices that can be communicated with and used by the user’s mobile device to improve its user’s efficiency and ability to perform tasks. Finally, mobile devices are personal and consequently require a high degree of personalization that also affects the software on the device.
- 20. Foreword by Jan Bosch xiii The key activity central to the transformation to mobile computing is the program- ming of applications and services on mobile devices. One can take three perspectives to mobile software. From the first perspective, nothing changes – software is soft- ware and the same programming languages and basic principles apply. From the second perspective, one could take the position that software for mobile devices is a step back from desktop software in that the software 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 more ago. The third perspective that one can take, and that I feel is the more appropriate one, is that mobile software adds a unique and novel dimension to programming that has not been present before and that requires new programming practices and approaches 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 the principles that are fundamental to mobile software on the one hand and on the other hand discuss the concrete details of programming languages, specifically mobile Java 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-end mobile devices, this book is a must-read for anyone interested in programming these devices. The second advantage of the approach taken by the author is that the book manages to describe the details of specific releases of programming environments without making the reader dependable on the specific version. The principles help programmers to easily evolve to subsequent versions, which appear at a very high rate, i.e. multiple times per year. I warmly recommend this book to anyone interested in programming mobile devices or interested in the state of the art and practice in this area. We are at a the verge of a major transformation in the information technology industry towards mobile computing and this book represents and outlines this future in clear and detailed fashion that will leave the reader with a solid understanding of programming for mobile devices. Jan Bosch Head of Software and Application Technologies Laboratory Nokia Research Center Helsinki, Finland. October 2006
- 22. Foreword by Antero Taivalsaari I’ve known Tommi for several years, both as a colleague and as a friend. Ever since first meeting him, Tommi has been passionate about mobile devices and mobile software 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 in Finland 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 software development courses has been available only in Finnish so far. In this book, Tommi makes his expertise in mobile software development avail- able also to English-speaking software developers and students. The book presents a comprehensive summary of all the central areas in mobile software development, ranging from fundamental topics such as memory and resource management to application design, networking, concurrency and security. Rather than focusing on specific technologies, devices or operating systems, this book takes a different approach and presents a summary of the component areas and 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 many other books that are outdated already by the time they come out of press. Knowing Tommi’s hectic schedule, this book represents a massive undertaking from 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 confident that 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 developers worldwide. Dr. Antero Taivalsaari The original designer of the Java Platform, Micro Edition (Java ME) Sun Microsystems Laboratories
- 24. Preface The two latest decades have seen the introduction of more and more hand-held gadgets being used for communication, as personal digital assistants, and simply for fun. Personal digital assistants and mobile phones, followed by other types of devices, such as MP3 players, wrist-watches and the like, have been adopted for wide 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 were first fabricated predominantly with hardware, and they served a single purpose. More recently, as the computing power in them has increased to the level of state-of-the-art desktops only some years ago, the devices have become a programming environment that has emerged as a new domain of software development, to the extent that one can even add new software developed by a designer independent of the device manufacturer. Moreover, properly documented programming infrastructure has been introduced to allow one to introduce programming facilities to a proprietary system without 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 a system that is best suited for some particular use. Moreover, also mass customization becomes possible, as copying software once it has been completed is virtually free. In addition to personal use, also commercial use by enterprises becomes more tempting, as it is possible to create systems that extend from enterprises’ servers to all employees anywhere and any time. Starting with email, already now a number of enterprises are allowing more and more mobile personnel who can interact with company intranet and computing systems disregarding the restrictions of time and place. Moreover, the number of devices that forms the potential market for new applications 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 the form of transforming companies that develop hardware-based systems that included small 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 the need for new development. Furthermore, changes that are evident due to evolving
- 25. xviii Preface hardware – more memory and processing power is regularly introduced in newer devices, together with more sophisticated hardware features like a camera – should not raise any compatibility issues but the same code should still run. Finally, the sheer 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-effective fashion 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 latter can be considered a lot more forgiving in the sense that a smallish programming error resulting in garbaging some memory every now and then will probably never cause a failure. In contrast, a smallish error in a program targeted for a mobile device in a part that handles memory use can cause devastating effects due to the restricted resources of the device. Therefore the quality of a design, including also non-functional properties, is even more important in the mobile setting. As a result, designs will unfortunately be harder to compose. Moreover, although the users of mobile devices are often adopting usage patterns of embedded devices where they expect the device to react immediately, when using a programmable mobile device, delays in execution will inevitably occur as old applications are being shut down and new 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, but can be performed with minor effort. Moreover, people tend to be more forgiving with 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 an embedded environment, one often has to compose programs in a memory-aware fashion, 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 commonly assumed 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 update workstation software on an almost daily basis; in fact, this can be automated. Not surprisingly, a similar need for constant management exists when considering the use 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, as well as the settings that can be used when running the application. For a desktop environment, several systems are available for managing the application setting. However, such systems have become available for managing the applications in mobile 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 the corporation were able to install and configure an application, the user can remove
- 26. Preface xix and reconfigure the application. Overall, this can in fact be considered as a major obstacle for using mobile applications in the corporate context. Increasing dependability requirements of communication are also applicable to the 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 this approach. Even with the current devices on the market, the number of potential users of such pieces of software is high, and therefore, the price of one download can 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 in its characteristics. This book is intended as a textbook on the principles of designing software for mobile devices. It is targeted at programmers who have experience in application development, but who have not worked with mobile devices before. The book is based on experiences in working in the mobile devices industry as well as experiences in teaching programming of mobile devices at Tampere University of Technology for several years. Unlike many other textbooks on programming mobile devices, the book is not intended to be used as a guide for immediately writing programs or creating applications for a certain mobile platform. Rather, the goal is to introduce the main ideas and restrictions that are applicable in any mobile environment, thus enabling more generic use. Moreover, the presentation does not become invalidated when a new version of a platform comes out that introduces different 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 discussed principles are visible in practical implementations. The discussion is structured as an introduction to the mobile devices infrastructure in general, memory and its use, applications and their development, modularity based on dynamically linked libraries, 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 or laptop computer? Even now, selecting a very computer-like mobile device for some particular special-purpose application is an option. Furthermore, with such devices, restrictions related to scarce resources can be relaxed, as it is possible to purchase more memory in order to make the devices optimal for a particular application. In addition, also programming environments that are used in workstations have been proposed for the mobile environment, including Python and Visual Basic, for instance. A further option would be to use a system where an operating system resembling those of PCs was available, like a restricted form of Windows and Linux, where application development can be more familiar. Moreover, using for
- 27. xx Preface example JavaScript inside a browser can also be considered yet another way to compose programs for mobile devices in a fashion that does not differ much from workstation programming. However, when aiming at the development of software that can be used in practice in a maximum number of devices, it is more likely that the restrictions remain, as the hardware forms a considerable cost factor and not all phones include broadband connectivity, but only something more modest. Still they require software to operate. Therefore, despite the advances in high-end phones and their connectivity features, as long as there is room for cost-effectively manufactured phones that are restricted in their performance, programming them in a sophisticated fashion requires special skills.
- 28. Acknowledgments 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 sincere thanks to Dir. Terho Niemi for putting me in charge of mobile device software architecture, which has initiated all this work; Prof. Ilkka Haikala for convincing me to apply for a professorship on mobile device programming; colleagues who have enabled many inspiring discussions; a number of master and doctoral students composing their theses on mobile systems programming; all the staff who have participated in the class of mobile programming in one form or another; and all the students 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 and parts of this book, including in particular Kari Systä, Tino Pyssysalo, Antti Juustila, and Reino Kurki-Suonio. Thanks to Symbian reviewers (Richard Harrison, Rick Martin, Rahul Singh, Kostyantyn Lutsenko, Warren Day, Ioannis Dourus, Attila Vamos, Jonathan Yu, Leela Prasanna, Krishna Vasudevan, Kamal Singhania, Kavita Khatawate, Amit Shivnani, Kajal Ahuja). I also wish to thank Laserwords for their help during the production process. Finally, I also have a personal life. To this end, I wish to express my sincere apologies to my family. Hopefully daddy will be around more often in the future. Tommi Mikkonen Tampere, Finland.
- 30. 1 Introduction 1.1 Motivation The development of mobile software has often been addressed in a fashion that focuses on using some particular technologies. While this type of approach can be easily justified for the introduction of a mobile platform that is to be used as the basis of an implementation, long-term issues are harder to embed into such an introduction. Furthermore, as the number of mobile platforms has been increasing, it is becoming an option to aim at discussing the differences between workstation and embedded 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 lasting approach, which will not be outdated when a new version of some particular mobile platform 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 that developers combine the rules of thumb applicable in the embedded environment – memory awareness, turned on for an unlimited time, limited performance and resources in general, and security in the sense that the device should never mal- function to produce unanticipated costs or reveal confidential information even if the user behaves in an unanticipated fashion – with features that are needed in the workstation environment – modifiability and adaptability, run-time extensions, and rapid application development. For this combination, the designer must master both hardware-aware and application-level software, as well as the main principles that guide their design. In order to compose designs where all these requirements are satisfied, the designer is bound to use abstraction, which is the most powerful weapon for dealing with complexity. 1.1.1 Leaking Abstractions Due to being such a powerful weapon for attacking software development, abstrac- tion is also one of the most commonly used facilities in programming. Systems we Programming Mobile Devices: An Introduction for Practitioners Tommi Mikkonen 2007 John Wiley & Sons, Ltd
- 31. 2 Programming Mobile Devices 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 familiar with, and know how they should be used. Therefore, the skill of programming in a certain environment implies that one recognizes the basic abstractions applied in the environment, and knows how the abstractions are intended to be used. Unfortunately, abstractions are not problem-free. In particular, problems are immi- nent when we face a new application domain or environment, such as mobile devices. Commonly used abstractions of programming may no longer be solid but they can start to leak. We will study this phenomenon in more detail in the following. In principle, as argued by several authors, including Gannon et al. (1981) and Gabriel (1989) for instance, the user of an abstraction can overlook the details of the underlying implementation. In practice, however, when composing programs, details of the underlying hardware and underlying infrastructure software used as the implementation technique of a certain abstraction sometimes become visible to the software developer or even to the user of the system. We will call this leaking abstraction.1 However, without knowing the implementation, it is difficult to understand what happens when the program is executed and a sudden downgrade of performance occurs, for instance. This makes the design more difficult, as revealing the implementation can take alarming forms. As a sample leaking abstraction, we next consider null-terminated strings used in the C programming language, for instance. The following procedure can be used to concatenate 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]; c1[i+1] = 0; return c1; } The logic of the operation is that first, we browse all the characters of string c1, and then copy all the characters of string c2 to its end. Moreover, it is assumed that c1 is large enough to host also the characters of c2, which is not explicitly expressed in the procedure but is an obvious built-in assumption. 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 some cases the implementation of strings becomes visible to the user. A problem is that 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.
- 32. Introduction 3 will unnecessarily go through the same characters all over again as longer and longer 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 be considerably extended. By observing this from a completed, running system, one might 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 this implementation. All non-trivial abstractions can be argued to leak to at least some extent (Spolsky 2004). For instance, let us consider the TCP/IP protocol that provides an abstrac- tion of reliable communication; if the underlying communication infrastructure is terminally 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 define database queries, some queries can (and usually should) be optimized by taking into account what takes place at the level of the implementation. Fundamentally, programming languages which are commonly available in the mobile setting, such as C, C++, and Java, and their run-time infrastructures are also non-trivial abstractions. Therefore, they also have the potential to leak. In many cases, leaking abstractions of programming languages and infrastructures that are executed in mobile devices lead to problems in managing resources, memory consumption, and performance. Therefore, in order to compose programs where potentially leaking abstractions form a minimal problem, the programmer must have experience of working in a certain environment to create appropriate designs. Since expecting that all developers have experience is unrealistic, infrastructures have been introduced where the most obvious traps will be automatically treated, as well as tutorials and coding standards that aim at preventing the most obvious problems associated with leaking abstractions. As already mentioned, mobile devices are restricted in terms of available resources. Therefore, in order to cope with leaking abstractions related to resources of the device, implied by the used programming languages and execution envi- ronments, the designer should understand what lies beneath the surface, because otherwise it is easy to use facilities of the language that are not well suited for such a restricted environment. 1.1.2 Allocation Responsibility Programming systems in mobile devices can treat complexity in two fundamentally different 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, disk space, or communication bandwidth. On the other hand, software infrastructure can be defined for handling the resources without revealing the details to the program- mer, thus automating resource management from the programmer perspective. The above 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
- 33. 4 Programming Mobile Devices developer in full, whereas black-box resource management hides its details from the 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 where leaking 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 in the mobile environment is C++, as in many cases features of the language require thorough knowledge of the underlying facilities and implementation techniques. Implementing programmer responsibility for potentially leaking abstractions can take many forms. On the one hand, one can define a coding standard that explains why 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 that defines 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 solve and why. This usually calls for understanding of what happens at compilation and how run-time infrastructure works. Infrastructure responsibility. A black-box approach to resource management means that the underlying programming infrastructure is supposed to liberate the developer from considering potentially leaking abstractions. Examples of environ- ments that operate in this way include Java and C#, which both can be used for programming mobile devices. However, in practice the developer is still able to use the 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 garbage collector in a virtual machine environment is helpful, as garbage collecting can seemingly stop the execution of a program for a short period of time in certain virtual machine environments. Thus, while the black-box approach hides resource management from the developer and the user, this abstraction leaks when garbage collection is performed, as its side-effects may become observable by the user. To summarize, no matter whether the programmer or the infrastructure manages resources, the way programs are designed and written has an effect on their perfor- mance and resource consumption. In the following, we discuss the most common hardware-related issues that the developer is exposed to when designing applications for mobile devices. 1.2 Commonly Used Hardware and Software To summarize the above discussion, programming languages and their run-time infrastructures can be considered as at least potentially leaking abstractions. Such leaks mean that the properties of hardware and lower-level software are revealed to
- 34. Introduction 5 an application programmer in some cases. Therefore, understanding their basics is a prerequisite for considering how applications should be designed for the mobile environment. In the following, we give an overview to commonly used hardware and software facilities inside a mobile device, whose restrictions can be considered as the main technical contributors of mobility (Satyanarayanan 1997). The subsections address hardware, operating system concepts, application software, and the stack of software components 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 and more standardized. One important driver for this is the need to integrate all the subsystems 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 are significant 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 discuss the execution in terms of hardware available in the system. For instance, loading the contents of a memory location to a processor’s internal memory location, so-called register, adding the contents of two registers and storing the result in a third, and Processor Accelerator Memory Cache Cache Peripherals Figure 1.1 Commonly used hardware
- 35. 6 Programming Mobile Devices int factor9() { int index, result = 1; for (index = 1; index < 10; index++) { result = result * index; } return result; } Figure 1.2 Sample source code storing the value in a register to a particular location in memory, are commonly used instructions. Processors have different instruction sets, i.e., primitive operations that proces- sors are capable of executing, and their properties can vary. Probably the most commonly used main processor2 in mobile devices follows ARM (Acorn RISC machine) 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 into many more complex pieces of hardware, such as OMAP architecture by Texas Instruments. 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 the operating system. As an example, consider the following. The piece of code given in Figure 1.2 computes the factor of 9. When it is fed to a compiler, which in this case is a GCC compiler 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 to locations in memory and to registers, as well as load and store instructions, which form 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 aux- iliary processors, which in terms of hardware can be considered similar to other processors, but they play a different role in the final system. They are used for coding and decoding of radio transmissions, and, more recently, to enable more sophisticated features such as three-dimensional graphics, for instance. Moreover, in some cases a proprietary phone implementation can be extended with an appli- cation processor that is to be used by additional applications without risking the functions of the proprietary phone. Further possible processors include an access processor (or a modem) that is dedicated for executing routines associated with telecommunications. 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.
- 36. Introduction 7 @ Generated by gcc 2.9-psion-98r2 (Symbian build 540) for ARM/pe .file "test.cpp" .gcc2_compiled.: .text .align 0 .global factor9__Fv factor9__Fv: @ args = 0, pretend = 0, frame = 8 @ frame_needed = 1, current_function_anonymous_args = 0 mov ip, sp stmfd sp!, {fp, ip, lr, pc} sub fp, ip, #4 sub sp, sp, #8 mov r3, #1 str r3, [fp, #-20] mov r3, #1 str r3, [fp, #-16] .L2: ldr r3, [fp, #-16] cmp r3, #9 ble .L5 b .L3 .L5: ldr r3, [fp, #-20] ldr r2, [fp, #-16] mul r3, r2, r3 str r3, [fp, #-20] .L4: ldr r3, [fp, #-16] add r2, r3, #1 str r2, [fp, #-16] b .L2 .L3: ldr r3, [fp, #-20] mov r0, r3 b .L1 .L1: ldmea fp, {fp, sp, lr} bx lr Figure 1.3 Sample ARM code Accelerators can be implemented using two different mechanisms, which are using 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 hardware can be used for several tasks, whereas single-purpose hardware can only be used for 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-purpose piece of hardware. Still, in general, DSPs have superior power consumption to
- 37. 8 Programming Mobile Devices performance rate over general purpose processors in tasks that are well-suited for them. 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 a C55x DSP while consuming more than twice the power (Chaoui et al. 2002). The downsides of DSPs are being solved by introducing more elaborated integration schemes for off-the-shelf hardware. Such integrated systems typically include a main processor, auxiliary DSP, memory, and additional interfaces. While systems exist where everything is integrated into a single chip, it is common that devices with new 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 inte- gration techniques lead to more complex designs in the sense of architecture. In addition, many hardware and platform manufacturers have been emphasizing mech- anisms related to power management, which also bear an effect on the complexity of the final design. Moreover, such features are becoming more important, as ready and use times of mobile devices are meaningful properties for the consumer. When more and more advanced features that require more processing power are introduced, clock frequency of the main processor must be increased. Unfortunately, this leads to problems due to heat generation. Therefore, one can consider that the current approach, where there is a master processor and a small number of auxil- iaries, may need to be reconsidered. As a solution, two contradicting approaches have been proposed. One is symmetric multiprocessing, which injects the complex- ity of programming to the operating system, and the other is the introduction of more and more specialized auxiliaries that manage their internal executions themselves. Presented in Figure 1.4, both approaches can be justified with solid arguments, as discussed 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 an opportunity 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 being performed. Moreover, as all the processors can be hidden behind the same operating system interface and have similar characteristics, a programmer can be offered an abstraction that can be conveniently used. On the downside, multiprocessing can be a relatively complex solution, when assuming that fundamentally the device can 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 energy management 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 some particular tasks. However, allocating tasks to different pieces of equipment cannot be implemented in a straightforward fashion as with symmetric multiprocessing.
- 38. Introduction 9 Single processor Multi- processor Symmetric Asymmetric App1 App2 Video Audio MCU App1 Video MCU1 App2 Audio MCU2 Video AuxP1 Audio AuxP2 App1 App2 MCU Figure 1.4 Symmetric and asymmetric multiprocessor schemes Instead, the programmer may be forced to participate in the allocation for adequate results. As a consequence, different devices relying on different sets of auxiliary equipment must be supported. Moreover, some devices may implement some equip- ment with additional software running on the main processor. One possible result for 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 is available, and software emulation will be used in devices that do not implement hardware acceleration. Still, a considerable development effort must be invested in the 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-bit memory 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 less than 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 allocate several variables to the same word, for instance. Unfortunately, this may result in degraded performance, as it is usually faster to access memory when respecting memory word boundaries. Respecting the word boundary is commonly referred to as (word) alignment.
- 39. 10 Programming Mobile Devices 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 memory can be read and written. The typical amount of RAM in a mobile device has been increasing rapidly, with typical figures reaching up to 64 or even 128 Mb. Different types of RAM can be considered, including static RAM (SRAM) and dynamic RAM (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 as cache, which can be considered as an intermediate storage used for storing memory locations that the processor frequently accesses. DRAM, on the other hand, is based on transistors requiring constant attention from the rest of the system to preserve their state, which consumes some energy. DRAM is commonly used in the mobile environment, 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 the same 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 in the following, can also be used for a similar role. Third, many devices also contain permanent storage, although ROM and RAM would 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 storage can be implemented in terms of a hard drive or as flash memory which maintain their 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 to mechanical failures. As already mentioned, flash memory is commonly used in mobile devices. Access- ing flash memory can be implemented such that it is relatively fast to read from memory, but writing is usually slow. The reason is that it is possible to turn single bits from 1 to 0, but turning 0 to 1 can only be performed in groups of 64 kb for instance, depending on the hardware implementation. As a result, even a small change in a file can result in a complete rewrite of the whole file. Two types of flash memory are to be considered, NOR and NAND flash memories. NOR flash can 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 be slower, SDRAM requires constant attention of the processor to maintain the mem- ory active, which consumes energy. In contrast to NOR flash, NAND flash behaves analogously to a hard disk, and requires loading of code to memory before running it. In comparison to other types of memory and hard disk, an additional restriction
- 40. Introduction 11 Processor’s internal memory locations Cache Main memory Disk/flash memory for permanent data Remote 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 flash requires the management of memory usage, which can consume a considerable amount 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. In contrast, 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 virtually unrestricted 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. The memory management unit (MMU, omitted from the figure for simplicity) is more conveniently implemented within the processor chip. The purpose of this piece of hardware is to enable using free locations in the memory for programs, disregarding their 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 usually appear to be in continuous locations in the memory even if they are distributed in the memory. Similarly, programs can be located in different parts of the memory during different execution instances of programs. MMU is also used for imple- menting memory protection enabled for processes, which we will discuss later in this 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 pages when additional memory is needed, and when the pages are used again, they can be restored from the disk. As flash memory is not very convenient for such a purpose due to slow write operations and restricted number of write accesses, this scheme is not commonly implemented in mobile devices. However, the ability to freely
- 41. 12 Programming Mobile Devices Free memory slots Reserved memory ... ... Figure 1.6 Fragmentation locate programs in different parts of the memory as well as memory protection are appreciated, and therefore many mobile devices include an MMU. Still, there is no technical barrier to implementing a full virtual memory system. Finally, two phenomena commonly associated with memory and its use are to be considered when composing programs for mobile devices. These are fragmentation and garbaging. The former means that memory is reserved such that some free memory remains unused between reserved blocks of memory (Figure 1.6). While fragmentation can in principle be handled by conjoining available free slices of memory to a bigger memory area, managing the lists of free and reserved slices can become a burden for the operating system, and superfluously consume precious memory and processing time. The latter refers to a situation where some data allocated to the memory can no longer be deallocated by the program that has allocated them, potentially reserving the memory locations until the execution of the program terminates, or, even worse, until the system is shut down. Subsystems In addition to the hardware described above, several types of auxiliary subsystems can 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 band- widths and protocols can be used, including for instance GSM, GPRS, WCDMA, and WLAN, to name a few. • Keyboard (or touch screen) allows the user to input data and commands to the device. • Screen enables the user to read the information stored inside the device.
- 42. Introduction 13 • Additional memory for switching data between mobile devices using a memory stick 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 imag- ine. In principle, anything that can be connected to a mobile device can form a new subsystem. Moreover, whether the connection is permanent or dynamic via a local area radio link, for instance, is becoming less important, as the capacity of connec- tions is becoming comparable due to the increased coverage and bandwidth. This results in an option to use implementations where a number of devices cooperate to perform some higher-level tasks. At a lower level of abstraction, implementing this requires support from hardware in terms of I/O interfaces or the use of universal asynchronous receiver transmitters (UART), for instance. 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 of programming 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 to benefit 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 that uses its resources. For accessing hardware, kernels usually implement special modules called device drivers that can be used for creating a connection to the underlying subsystems and communicating with external equipment. The usual way to implement such drivers is that they send a request to the external subsystem, and the subsystem is responsible for serving the request. When the request is served, the subsystem responds with an interrupt that the kernel will acknowledge and serve with a corresponding interrupt handler, which contains the procedure for managing interrupts. Device drivers can be implemented in a layered fashion, where a physical layer handles the details of the actual hardware. A logical level can then be introduced for handling the parts that are common for all similar subsystems. When considering the connection between the kernel and other software, the resources of the former are a necessity to create applications. Commonly used terms are processes and threads, which we will address in the following. Processes can be considered as the units of resource reservation. This allows designs where the different resources allocated by programs are kept in isolation from 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
- 43. 14 Programming Mobile Devices can be extended with new applications. For devices that do not allow this and only include proprietary software, this may not be an option; instead, all processes can run 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 resources owned 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 a conventional 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 with other threads inside the same process. When the thread that is being executed is changed to another by a special part of the kernel, the scheduler, the event is called a context switch. If the operating system can force a context switch even if the thread is not ready for it, the scheduler is called pre-emptive, and if the thread must explicitly pause its execution, the scheduler is referred to as non-pre-emptive. A pre-emptive scheduling 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 the user can be delayed in favor of other operations. Moreover, context switching can also be executed repeatedly, if the performance ratio is increased. In contrast, for a non-pre-emptive scheduler, a fixed order of executions is usually defined, which is less flexible but whose performance ratio can be close to 100%. Two types of context switches can be considered; one takes place when a thread is changed to another but the process hosting the threads remains the same, and the other when also the hosting process 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 work performed 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 languages used in the mobile setting to the facilities of the underlying hardware and operating system software. Allocating Memory for Programs and Variables Perhaps the most straightforward consumers of memory are constants, which can usually 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, its modifiable data must be stored in RAM, as the program can constantly alter the data. 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 for the user. Furthermore, it can be difficult for the user to realize when all data has been saved and it is safe to turn off the device. Therefore, the design of programs
- 44. Introduction 15 Previous activation record Next activation record Return address Return value Parameters Local variables Other information Activation record Figure 1.7 Activation record in a stack should ensure timely saving of data in a fashion that is straightforward from the user perspective. In many mobile devices, this has been implemented using a practice where 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 manages the 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 activation record 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, each activation record contains method parameters, the return value (if applicable), and variables that are local to a method, which in some systems are called automatic variables that are defined within the scope of the method. As the stack is intimately associated 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 pro- gram in terms of activation records, heap is an unstructured memory pool from which threads can allocate memory. Unlike memory allocated from stack, where the execution flow manages memory consumption, memory allocated from the heap is under the responsibility of the programmer. The accumulation of heap-allocated memory 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 never deallocates it. 4 Exact details of activation records differ slightly in different systems. However, the principal idea remains the same.
- 45. 16 Programming Mobile Devices The fashion in which the programmer composes programs determines where data structures are allocated. As an example on memory allocation from stack and from heap, consider the allocation of the following data structure: struct Sample { int i; char c; }; This data structure is most likely allocated to memory in a fashion where each variable takes a different memory location in terms of words, resulting in the con- sumption of two 32-bit memory words, one for i and the other for c. While the actual size of the memory allocation is usually handled by the compiler and associ- ated run-time environment, its location in the program defines how data structures are partitioned between the stack and the heap. Automatic variables, i.e., those that are local to a method or procedure, are allocated from stack, and explicitly allo- cated data structures, using, say, malloc or new, are placed in the heap. Figure 1.8 represents two different ways to locate the above data structure to memory using stack and heap as the locations. As already discussed, the location that is allocated for a data structure affects the way memory is to be managed; stack-based variables are automatically created as the execution advances whereas heap-based variables require explicit allocation and deletion, assuming that no special infrastructure for garbage collection is introduced. Unfortunately, in some cases compilers perform int SInStack() { Sample s; .... } int SInHeap() { Sample * s; s = new Sample; .... } s.i s.c ... ... s ... ... s.i s.c ... ... Stack Heap Stack Figure 1.8 Allocating memory for an object from stack and from heap
- 46. Introduction 17 int todo { return 1; }; int main() { todo(); } main() todo() stack (RAM) Program memory (ROM, RAM) todo main Source code Allocation to memory return address heap (RAM) Compilation and download Figure 1.9 A program and associated infrastructural memory consumption implicit allocations from heap even if a programmer assumes stack-based treat- ment. Such cases can lead to hard-to-trace errors that only become visible after an extended execution. Programs are most commonly stored in ROM, flash, or disk, if such a facility is available 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, as there is no need to create an additional copy of the program into it. Usually this type of approach is used when a program is located in ROM, and it is beneficial to always run the program unaltered. For instance, in-place execution could be used for the introduction of a safety feature that enables (emergency) calls even if a mobile device is otherwise infected with a virus or some other malicious software. For flash memory, the type of flash used defines whether in-place execution can be used or not. 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 behaves analogously to a hard disk, programs must always be loaded to RAM. There are also downsides to using in-place execution. First, it is impossible to upgrade the system using software modules that are downloaded after the installation. Second, it is not 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.
- 47. 18 Programming Mobile Devices Generated Run-Time Elements As already discussed, all programs and variables in them are allocated to mem- ory locations when a program is executed. In addition to the basic cases, more sophisticated software structures introduce additional memory consumption. Such structures include infrastructure for inheritance and virtual machines, which we will discuss in the following. In association with inheritance, an auxiliary data structure called a virtual function table is commonly generated. Its goal is to manage dynamic binding (Figure 1.10). When referring to a method during the execution of a program, dynamic binding does not refer to the method directly, but via a reference to the methods of the associated class and an offset that identifies the exact method to be called. Effec- tively, this implies that for all classes where dynamic binding can be used, a table is created where the cells of the table refer to different functions of the class. Then, when a program runs to a virtual function call, object type is used to select the right virtual function, and an offset included in the generated code is used to select the right function. As the outcome, all classes that potentially use dynamic binding require additional memory for the virtual function table, and, furthermore, add one extra memory word in each object for the type tag, which in reality often is a reference (or pointer) to the right virtual function table. A virtual machine can be taken as a processor (or interpreter) implemented with software. This eases porting of programs implemented on top of the virtual machine, as the same (or similarly instructed) virtual machine can be used in dif- ferent hardware environments. Fundamentally, two types of virtual machines can be considered. One is such that an interpreter is used that executes programs by simply interpreting each instruction as such. The other approach is that once the program to be run is fed to the virtual machine, the virtual machine compiles it into class C { int i; char c; virtual void v(); virtual double d(); }; i c ID Stack/Heap (object instantiated in memory) d-id Virtual function table (program memory, RAM) v-id C.v code C.d code Method code (program memory, RAM) Figure 1.10 Virtual function table
- 48. Introduction 19 an executable form that is closer to the actual machine code and can therefore be executed faster. Also a combination of the two is possible. Then, some commonly executed parts of the program for instance are compiled, whereas parts that are only executed seldomly are interpreted every time. This technique is referred to as hotspot compilation. A further issue worth considering is that since programs can be interpreted as data that are fed to a virtual machine, the machine can impose additional restrictions on programs. Moreover, it can control resource usage of pro- grams, and manage loading of programs, an important facility to centralize in the mobile setting, to execution. A sample virtual machine, which reflects the features of a Java virtual machine, is illustrated in Figure 1.11 (Hartikainen, 2005). The roles of the different components of a virtual machine are listed in the following. • Class loader is a component responsible for loading programs, given in terms of classes in our reference system. • Run-time data is a container for loaded programs. It includes elements similar to those used in native executions for the purposes of the virtual machine. • Execution engine contains a scheduler, which is responsible for selecting a thread for execution, a memory manager, which ensures that no illegal memory refer- ences are made and that memory is deallocated when it is no longer needed, and a bytecode interpreter, which executes the actual programs. Garbage collection, i.e., freeing of resources that are still reserved but are known to be abandoned, can be implemented in two different ways using a virtual machine. Usually, a simple way is to implement garbage collection in cooperative (or stop- the-world) fashion, which stops the application while garbage is being collected. Therefore, only the garbage collector has access to data, and it can perform its task without a risk of modifying the same variables as the application at the same time. In contrast, parallel garbage collection can also be implemented, but this requires Class loader *.class *.class *.class *.class loads Run-time data App. area* Class area Stack Heap * App. area includes e.g. Program Counter loads classes into Execution engine Bytecode interpreter Scheduler Memory manager calls use garbage collection Figure 1.11 Elements of a Java virtual machine
- 49. 20 Programming Mobile Devices a more complex design because the garbage collector and the application being executed operate on the same data structures. In general, garbage collection is a wide topic with dedicated books (Jones 1999), and its detailed introduction at the level of individual algorithms, such as reference counting, mark-and-sweep, heap compaction, or more recent generational garbage collectors, falls beyond the scope of this book. 1.2.4 Software Stack Building on top of kernel and other low level facilities, software used in mobile devices can be characterized using three different categories of software: appli- cations and related facilities, middleware, and low-level software. The reason for separating these layers is that it is often desirable to consider that such levels of abstraction can evolve independently of each other, i.e., it is preferable that applica- tions are independent of middleware version, and that middleware in general is not tied to a particular version of low-level software but can be used over several gen- erations. Furthermore, maintained and relatively static interfaces are often defined to separate the layers. In the following, we address these categories one by one. 1. Application-level software is about the development of meaningful applications for an end user. In mobile devices, common application development rules of workstation software apply to a great extent, as it is often the intention of the device manufacturer to allow the introduction of additional applications. Imple- mentation of other software components can benefit from using the provided interfaces of the lower-level components, but their implementations should not be relied on because different versions of software can be used in different devices. Moreover, a characteristic property of application-level development is usability, as otherwise users may reject the application. 2. Middleware software offers facilities that ease the development of applications. This often includes libraries such as support for using certain communication protocols. While an application developer is usually only using already existing systems, in some cases it is a necessity to define some new application-specific components. Then, it is common that the implementations must follow some predefined interfaces. In many ways, rules introduced for communications pro- gramming by Sridhar (2003) can be followed in the implementation of such components. The emphasis is often placed on portability in the sense that the details of the underlying hardware are not always benefited from even if this would result in improved performance. Despite this, characteristic properties include performance and memory awareness at this level of abstraction in prac- tice despite device- and platform-specific features. 3. Low-level software covers kernel and device drivers, and virtual machines when applicable. Usually all such software is fixed by the device manufacturer. When developing such software, guidelines of Barr (1999) can be benefited from due
- 50. Introduction 21 to the fact that in many ways the development of low-level software resem- bles the development of deeply embedded systems, with close connection to the underlying hardware. However, even at this level of abstraction, some precau- tions can be taken for reusability in future hardware environment, for instance. A characteristic property at this level is hardware awareness in general, but in a fashion that does not impose too harsh restrictions. In general, software asso- ciated with this level of abstraction is managed by a device manufacturer or platform developer. To summarize the above discussion, the lower one goes in the sense of abstrac- tion, the more one must understand the properties and restrictions of the platform and the hardware environment. Unfortunately, even at the application level, some properties of the environment remain visible, making applications a leaking abstrac- tion. Moreover, when aiming at applications that can be used in multiple devices, also device variance can be considered as a main issue in the development. A further problem results from the fact that the levels are seldom static but evolve as more and more devices are implemented on top of the same set of software components, often referred to as a platform.5 In this setting, it is common that upgrades take place and introduce new features to the platform as more hardware and processing facilities are introduced, as well as standardization advances. If performed in a careless fashion, the introduction of a new version of some low- level feature can lead to invalidation of some applications. Therefore, extra care should be paid for maintaining (binary) compatibility when composing new versions of middleware and low-level software. Otherwise, the platform can corrupt to a collection of devices in which one cannot run the same software, but must make device-specific modifications for all software that takes into account specifics of devices that are to be used for running the application. For practical reasons, the development of a platform and the development of an application may have different concerns. For instance, for a particular application, many concerns related to variability to different types of devices – essential aspects of platform development – become irrelevant, if the application is targeted to only one type of device. Similarly, tailoring applications to run on as many platforms as possible often becomes relevant for an application developer only when the first running version is available, whereas tailoring a platform such that it will run all the applications constructed in accordance to some guidelines must be taken into account at the very beginning of the development as a compatibility requirement. 1.3 Development Process The development process of a piece of software intended for a mobile device dif- fers from that of conventional workstation software. The main reason is that first, 5 Strictly speaking one can consider that all the above levels constitute different platforms: OS platform, middleware platform, and application platform. Also other categories have been proposed.
- 51. 22 Programming Mobile Devices the developed software is often tested in the development environment, usually a PC, with an emulator. Only when the software runs is it downloaded to an actual mobile device for testing, as depicted in Figure 1.12. The development worksta- tion is commonly referred to as a host, and the final execution environment as the target. The software tested with the emulator and the software downloaded to a mobile device can be identical, but they need not be. If the same programming infrastruc- ture is available in both environments, like a common virtual machine for instance, the software can obviously be the same, as the case can be with Java. However, if there is no infrastructure that would enable the use of the same software, differ- ent compilations are needed. The process where a workstation is used to compile an executable which is downloaded to a different system is referred to as cross- compilation. While it is possible to emulate the low-level behavior of a system, differences in available environment sometimes lead to early use of the actual device even in the development phase. Obviously, being able to run the same version in the development and the final execution environment eases debugging, as only one tool-chain is needed. In the best case, downloading the application to the final environment is trivial. However, if cross-compilation is needed, the phase where software runs in the emulator can be only the beginning of debugging and testing activities that are necessary until the program is completed. For instance, there can be additional requirements regarding compilation, if the mobile device does not support all the features of the emulator. For example, older versions of Symbian OS (before v.9.0) were unable to handle Mobile device Emulator Development workstation Emulator runnable Emulator compilation Device runnable Cross- compilation Device installable Device runnable Source code Packing Download Figure 1.12 Development process and software download
- 52. Introduction 23 global variables in dynamically loaded libraries in devices,6 but forced one to use a platform-specific feature called thread local storage (TLS), where thread imple- mentation was piggy-backed with global variables (Tasker et al. 2000). However, this problem only arises in the cross-compilation phase, as it is related to the final execution environment, not to C++ that is used as the programming language or emulator, which runs on the development workstation and can deal with global variables without problems. In addition to the actual cross-compilation, many environments require the use of installation files. In addition to plain compiled programs, such files can often be extended with additional data, which can be auxiliary data files, or sound or graphics extensions for a certain program, for instance. When a package containing all these files is fed to the installer application residing on the mobile device, the installer then unpacks the files and places them to convenient locations as defined by the package. 1.4 Chapter Overview The chapters of this book introduce the main concerns of the design of software for mobile devices. Unlike many other introductions, we have organized the presenta- tion in accordance to concerns, which are memory usage, concept of applications, modularity and available mechanisms, concurrency, generic resource management, networking, and security. Individual chapters and their contents are listed in the following. Chapter 1 has introduced the basics of mobile devices in terms of underlying hardware and software. The goal of the chapter is to introduce the basic concepts on top of which further chapters will build on. Chapter 2 discusses memory management, which a designer must master in the mobile setting. As memory is one of the restricted elements of a mobile system, it is important to understand the basic principles of managing its use. The chapter introduces some design patterns, i.e., reusable design decisions that solve certain problems in a predefined context (Gamma et al. 1995), for memory-aware software, and gives examples on memory management in mobile devices. Similar topics have already been addressed by Noble and Weir (2001), although their focus is been wider. Chapter 3 introduces the concept of an application. While in principle, all software can be implemented from ground up, mobile software platforms usually introduce a prescribed architecture for applications. Furthermore, another important issue is packaging applications for delivery to a device. 6 The reason for not using global variables in dynamically linked libraries lies in the fact that at least one additional memory page, i.e., memory allocation unit, would be reserved for the library if global variables were allowed. This would lead to a considerable overhead.
- 53. 24 Programming Mobile Devices In Chapter 4 we discuss the use of dynamically linked libraries, and demonstrate how available implementation techniques become visible to a programmer in a mobile environment. Again, the purpose is to address how the selected design and implementation decisions are unveiled to programmers. Chapter 5 introduces the most important mechanisms of concurrency applicable in the mobile setting. The chapter addresses issues like whether to use threads, which are a common technique when programming desktop systems, or to use other means of serialization, which can offer less resource consuming solutions. Moreover, the chapter considers reusability of such designs. Chapter 6 integrates concurrency with the management of different resources that must be handled in a mobile device. The chapter also discusses problems associated with the fact that it is not uncommon that even seemingly similar devices can include some differences in their hardware, which can sometimes lead to complications in the development of associated software. Chapter 7 defines how a mobile device can interact with networks. The goal is to describe how mobile devices can be used in a networking application, and how software residing in a mobile device should be designed, and general topics associated with distributed systems and their implementation are mainly overlooked. Furthermore, the chapter also discusses two cases, one on using Web Services with a mobile device, and another on ad-hoc networking over short-range wireless protocols using Bluetooth as an example. Chapter 8 is dedicated to security properties of a mobile platform. The chapter discusses both design patterns for secure designs as well as approaches adapted in existing platforms. The rationale of locating this important topic towards the end of the discussion is that security is an issue that contributes to all the previous techniques in a fundamental fashion. Without first discussing the basic implementa- tion, it would be impossible to introduce a suitable security concept for the different issues. In each chapter, we will use mobile Java (Riggs et al. 2001; Topley 2002) and Symbian Operating System (Edwards et al. 2004; Harrison 2003; Tasker et al. 2000) as examples on real-life mobile platforms. The reason for using these systems is that in many ways they contradict each other. In mobile Java, the underlying mindset is that it can be introduced as an external facility to all proprietary phones, and that the run-time infrastructure will adopt a major portion of the complexity of dealing with scarce resources. In contrast, in Symbian OS, the complexity is explicitly made visible to the programmer, together with certain patterns and idioms that are to be used when dealing with resources. When used with care, this in principle yields improved performance, because the whole power of the device’s hardware can be used. In addition, we also give some exercises on the topic discussed in the chapter. However, the purpose is not to focus on these particular platforms but to maintain a more abstract approach, but examples merely characterize some design solutions made in real platforms.
- 54. Introduction 25 1.5 Summary • Programming of mobile devices is fundamentally the same as programming of desktops. However, design flaws are more prone to cause problems, as resources are scarce in mobile devices. Moreover, available facilities are usually not as advanced as when programming a workstation, but developers must sometimes rely on practices more commonly associated with programming of embedded systems. • Understanding the characteristics of the underlying hardware and software infras- tructure is a practical necessity for dealing with leaking abstractions in the mobile setting. • While there are several types of devices, they share the same basic architecture. – Processor, a hierarchy of memory facilities, and auxiliary subsystems for inter- acting with the environment and enhanced features. – Operating system, middleware, and applications, whose reliability requirements may differ. This has implications for software development as well. – Ability to reuse existing infrastructure as a common platform in multiple devices is preferable. • A fundamental design decision of future mobile devices is whether to use sym- metric multiprocessing versus a collection of specialized pieces of hardware. – Symmetric architecture eases the development of applications in the sense that all facilities appear similar to the programmer. – Asymmetric architecture can be more specialized in its resource use, which often hardens design and adequate use of available facilities. • Run-time software infrastructure can introduce overhead; examples of such over- head include virtual function table used for implementing dynamic binding asso- ciated with inheritance, and virtual machines. 1.6 Exercises 1. What solutions would be applicable for defining an abstraction that does not leak for strings? Which programming infrastructures (languages, operating systems, etc.) use them? 2. What properties of applications have potential for leaking in the mobile environ- ment, assuming that a programming language familiar to you is available? How should the developer address these properties? 3. What differences can you find in your own software programs when considering the way in which they use stack and heap? Why? 4. Consider a calendar application running in a mobile device. Which services does it use from low-level, middleware-level, and application-level components? 5. Which features of programming languages, such as C++ or Java, can be problem- atic when programming mobile devices? What kinds of coding rules or idioms
- 55. Exploring the Variety of Random Documents with Different Content
- 56. to our ideas, it should be something extremely abstract, too intangible for use. The Chinese have one word, ming or mei. Its ideograph is the sign of the sun together with the sign of the moon. It serves as verb, noun, adjective. Thus you write literally, "the sun and moon of the cup" for "the cup's brightness." Placed as a verb, you write "the cup sun-and-moons," actually "cup sun-and-moon," or in a weakened thought, "is like sun," i.e., shines. "Sun-and-moon cup" is naturally a bright cup. There is no possible confusion of the real meaning, though a stupid scholar may spend a week trying to decide what "part of speech" he should use in translating a very simple and direct thought from Chinese to English. The fact is that almost every written Chinese word is properly just such an underlying word, and yet it is not abstract. It is not exclusive of parts of speech, but comprehensive; not something which is neither a noun, verb, or adjective, but something which is all of them at once and at all times. Usage may incline the full meaning now a little more to one side, now to another, according to the point of view, but through all cases the poet is free to deal with it richly and concretely, as does nature. In the derivation of nouns from verbs, the Chinese language is forestalled by the Aryan. Almost all the Sanskrit roots, which seem to underlie European languages, are primitive verbs, which express characteristic actions of visible nature. The verb must be the primary fact of nature, since motion and change are all that we can recognize in her. In the primitive transitive sentence, such as "Farmer pounds rice," the agent and the object are nouns only in so far as they limit a unit of action. "Farmer" and "rice" are mere hard terms which define the extremes of the pounding. But in themselves, apart from this sentence-function, they are naturally verbs. The farmer is one who tills the ground, and the rice is a plant which grows in a special way. This is indicated in the Chinese characters. And this probably exemplifies the ordinary derivation of nouns from verbs. In all languages, Chinese included, a noun is originally "that which does something," that which performs the verbal action. Thus the moon comes from the root ma, and means "the measurer." The sun means that which begets. The derivation of adjectives from the verb need hardly be exemplified. Even with us, to-day, we can still watch participles passing over into
- 57. adjectives. In Japanese the adjective is frankly part of the inflection of the verb, a special mood, so that every verb is also an adjective. This brings us close to nature, because everywhere the quality is only a power of action regarded as having an abstract inherence. Green is only a certain rapidity of vibration, hardness a degree of tenseness in cohering. In Chinese the adjective always retains a substratum of verbal meaning. We should try to render this in translation, not be content with some bloodless adjectival abstraction plus "is." Still more interesting are the Chinese "prepositions," they are often post- positions. Prepositions are so important, so pivotal in European speech only because we have weakly yielded up the force of our intransitive verbs. We have to add small supernumerary words to bring back the original power. We still say "I see a horse," but with the weak verb "look," we have to add the directive particle "at" before we can restore the natural transitiveness.[5] Prepositions represent a few simple ways in which incomplete verbs complete themselves. Pointing toward nouns as a limit they bring force to bear upon them. That is to say, they are naturally verbs, of generalized or condensed use. In Aryan languages it is often difficult to trace the verbal origins of simple prepositions. Only in "off" do we see a fragment of the thought "to throw off." In Chinese the preposition is frankly a verb, specially used in a generalized sense. These verbs are often used in their specially verbal sense, and it greatly weakens an English translation if they are systematically rendered by colorless prepositions. Thus in Chinese: By = to cause; to = to fall toward; in = to remain, to dwell; from = to follow; and so on. Conjunctions are similarly derivative, they usually serve to mediate actions between verbs, and therefore they are necessarily themselves actions. Thus in Chinese: Because = to use; and = to be included under one; another form of "and" = to be parallel; or = to partake; if = to let one do, to permit. The same is true of a host of other particles, no longer traceable in the Aryan tongues. Pronouns appear a thorn in our evolution theory, since they have been taken as unanalyzable expressions of personality. In Chinese even they yield up their striking secrets of verbal metaphor. They are a constant source of weakness if colorlessly translated. Take, for example, the five
- 58. forms of "I." There is the sign of a "spear in the hand" = a very emphatic I; five and a mouth = a weak and defensive I, holding off a crowd by speaking; to conceal = a selfish and private I; self (the cocoon sign) and a mouth = an egoistic I, one who takes pleasure in his own speaking; the self presented is used only when one is speaking to one's self. I trust that this digression concerning parts of speech may have justified itself. It proves, first, the enormous interest of the Chinese language in throwing light upon our forgotten mental processes, and thus furnishes a new chapter in the philosophy of language. Secondly, it is indispensable for understanding the poetical raw material which the Chinese language affords. Poetry differs from prose in the concrete colors of its diction. It is not enough for it to furnish a meaning to philosophers. It must appeal to emotions with the charm of direct impression, flashing through regions where the intellect can only grope.[6] Poetry must render what is said, not what is merely meant. Abstract meaning gives little vividness, and fullness of imagination gives all. Chinese poetry demands that we abandon our narrow grammatical categories, that we follow the original text with a wealth of concrete verbs. But this is only the beginning of the matter. So far we have exhibited the Chinese characters and the Chinese sentence chiefly as vivid shorthand pictures of actions and processes in nature. These embody true poetry as far as they go. Such actions are seen, but Chinese would be a poor language and Chinese poetry but a narrow art, could they not go on to represent also what is unseen. The best poetry deals not only with natural images but with lofty thoughts, spiritual suggestions and obscure relations. The greater part of natural truth is hidden in processes too minute for vision and in harmonies too large, in vibrations, cohesions and in affinities. The Chinese compass these also, and with great power and beauty. You will ask, how could the Chinese have built up a great intellectual fabric from mere picture writing? To the ordinary western mind, which believes that thought is concerned with logical categories and which rather condemns the faculty of direct imagination, this feat seems quite impossible. Yet the Chinese language with its peculiar materials has passed over from the seen to the unseen by exactly the same process
- 59. which all ancient races employed. This process is metaphor, the use of material images to suggest immaterial relations.[7] The whole delicate substance of speech is built upon substrata of metaphor. Abstract terms, pressed by etymology, reveal their ancient roots still embedded in direct action. But the primitive metaphors do not spring from arbitrary subjective processes. They are possible only because they follow objective lines of relations in nature herself. Relations are more real and more important than the things which they relate. The forces which produce the branch-angles of an oak lay potent in the acorn. Similar lines of resistance, half curbing the out-pressing vitalities, govern the branching of rivers and of nations. Thus a nerve, a wire, a roadway, and a clearing-house are only varying channels which communication forces for itself. This is more than analogy, it is identity of structure. Nature furnishes her own clues. Had the world not been full of homologies, sympathies, and identities, thought would have been starved and language chained to the obvious. There would have been no bridge whereby to cross from the minor truth of the seen to the major truth of the unseen. Not more than a few hundred roots out of our large vocabularies could have dealt directly with physical processes. These we can fairly well identify in primitive Sanskrit. They are, almost without exception, vivid verbs. The wealth of European speech grew, following slowly the intricate maze of nature's suggestions and affinities. Metaphor was piled upon metaphor in quasi-geological strata. Metaphor, the revealer of nature, is the very substance of poetry. The known interprets the obscure, the universe is alive with myth. The beauty and freedom of the observed world furnish a model, and life is pregnant with art. It is a mistake to suppose, with some philosophers of æsthetics, that art and poetry aim to deal with the general and the abstract. This misconception has been foisted upon us by mediæval logic. Art and poetry deal with the concrete of nature, not with rows of separate "particulars," for such rows do not exist. Poetry is finer than prose because it gives us more concrete truth in the same compass of words. Metaphor, its chief device, is at once the substance of nature and of language. Poetry only does consciously[8] what the primitive races did unconsciously. The chief work of literary men in dealing with language, and of poets especially, lies in feeling back along the ancient lines of advance.[9] He must do this so that he may keep his words enriched by
- 60. all their subtle undertones of meaning. The original metaphors stand as a kind of luminous background, giving color and vitality, forcing them closer to the concreteness of natural processes. Shakespeare everywhere teems with examples. For these reasons poetry was the earliest of the world arts; poetry, language and the care of myth grew up together. I have alleged all this because it enables me to show clearly why I believe that the Chinese written language has not only absorbed the poetic substance of nature and built with it a second world of metaphor, but has, through its very pictorial visibility, been able to retain its original creative poetry with far more vigor and vividness than any phonetic tongue. Let us first see how near it is to the heart of nature in its metaphors. We can watch it passing from the seen to the unseen, as we saw it passing from verb to pronoun. It retains the primitive sap, it is not cut and dried like a walking-stick. We have been told that these people are cold, practical, mechanical, literal, and without a trace of imaginative genius. That is nonsense. Our ancestors built the accumulations of metaphor into structures of language and into systems of thought. Languages to-day are thin and cold because we think less and less into them. We are forced, for the sake of quickness and sharpness, to file down each word to its narrowest edge of meaning. Nature would seem to have become less like a paradise and more and more like a factory. We are content to accept the vulgar misuse of the moment. A late stage of decay is arrested and embalmed in the dictionary. Only scholars and poets feel painfully back along the thread of our etymologies and piece together our diction, as best they may, from forgotten fragments. This anemia of modern speech is only too well encouraged by the feeble cohesive force of our phonetic symbols. There is little or nothing in a phonetic word to exhibit the embryonic stages of its growth. It does not bear its metaphor on its face. We forget that personality once meant, not the soul, but the soul's mask. This is the sort of thing one can not possibly forget in using the Chinese symbols. In this Chinese shows its advantage. Its etymology is constantly visible. It retains the creative impulse and process, visible and at work. After thousands of years the lines of metaphoric advance are still shown, and in many cases actually retained in the meaning. Thus a word, instead of growing gradually poorer and poorer as with us, becomes richer and still more rich from age to age, almost consciously luminous. Its uses in
- 61. national philosophy and history, in biography and in poetry, throw about it a nimbus of meanings. These centre about the graphic symbol. The memory can hold them and use them. The very soil of Chinese life seems entangled in the roots of its speech. The manifold illustrations which crowd its annals of personal experience, the lines of tendency which converge upon a tragic climax, moral character as the very core of the principle—all these are flashed at once on the mind as reinforcing values with an accumulation of meaning which a phonetic language can hardly hope to attain. Their ideographs are like blood-stained battle flags to an old campaigner. With us, the poet is the only one for whom the accumulated treasures of the race-words are real and active. Poetic language is always vibrant with fold on fold of overtones, and with natural affinities, but in Chinese the visibility of the metaphor tends to raise this quality to its intensest power. I have mentioned the tyranny of mediæval logic. According to this European logic thought is a kind of brick-yard. It is baked into little hard units or concepts. These are piled in rows according to size and then labeled with words for future use. This use consists in picking out a few bricks, each by its convenient label, and sticking them together into a sort of wall called a sentence by the use either of white mortar for the positive copula "is," or of black mortar for the negative copula "is not." In this way we produce such admirable propositions as "A ring-tailed baboon is not a constitutional assembly." Let us consider a row of cherry trees. From each of these in turn we proceed to take an "abstract," as the phrase is, a certain common lump of qualities which we may express together by the name cherry or cherry- ness. Next we place in a second table several such characteristic concepts: cherry, rose, sunset, iron-rust, flamingo. From these we abstract some further common quality, dilutation or mediocrity, and label it "red" or "redness." It is evident that this process of abstraction may be carried on indefinitely and with all sorts of material. We may go on forever building pyramids of attenuated concept until we reach the apex "being." But we have done enough to illustrate the characteristic process. At the base of the pyramid lie things, but stunned, as it were. They can never know themselves for things until they pass up and down among the layers of the pyramids. The way of passing up and down the pyramid may
- 62. be exemplified as follows: We take a concept of lower attenuation, such as "cherry"; we see that it is contained under one higher, such as "redness." Then we are permitted to say in sentence form, "Cherryness is contained under redness," or for short, "(the) cherry is red." If, on the other hand, we do not find our chosen subject under a given predicate we use the black copula and say, for example, "(The) cherry is not liquid." From this point we might go on to the theory of the syllogism, but we refrain. It is enough to note that the practised logician finds it convenient to store his mind with long lists of nouns and adjectives, for these are naturally the names of classes. Most text-books on language begin with such lists. The study of verbs is meagre, for in such a system there is only one real working verb, to-wit, the quasi-verb "is." All other verbs can be transformed into participles and gerunds. For example, "to run" practically becomes a case of "running." Instead of thinking directly, "The man runs," our logician makes two subjective equations, namely: The individual in question is contained under the class "man"; and the class "man" is contained under the class of "running things." The sheer loss and weakness of this method is apparent and flagrant. Even in its own sphere it can not think half of what it wants to think. It has no way of bringing together any two concepts which do not happen to stand one under the other and in the same pyramid. It is impossible to represent change in this system or any kind of growth. This is probably why the conception of evolution came so late in Europe. It could not make way until it was prepared to destroy the inveterate logic of classification. Far worse than this, such logic can not deal with any kind of interaction or with any multiplicity of function. According to it, the function of my muscles is as isolated from the function of my nerves, as from an earthquake in the moon. For it the poor neglected things at the bases of the pyramids are only so many particulars or pawns. Science fought till she got at the things. All her work has been done from the base of the pyramids, not from the apex. She has discovered how functions cohere in things. She expresses her results in grouped sentences which embody no nouns or adjectives but verbs of special character. The true formula for thought is: The cherry tree is all that it
- 63. does. Its correlated verbs compose it. At bottom these verbs are transitive. Such verbs may be almost infinite in number. In diction and in grammatical form science is utterly opposed to logic. Primitive men who created language agreed with science and not with logic. Logic has abused the language which they left to her mercy. Poetry agrees with science and not with logic. The moment we use the copula, the moment we express subjective inclusions, poetry evaporates. The more concretely and vividly we express the interactions of things the better the poetry. We need in poetry thousands of active words, each doing its utmost to show forth the motive and vital forces. We can not exhibit the wealth of nature by mere summation, by the piling of sentences. Poetic thought works by suggestion, crowding maximum meaning into the single phrase pregnant, charged, and luminous from within. In Chinese character each work accumulated this sort of energy in itself. Should we pass formally to the study of Chinese poetry, we should warn ourselves against logicianized pitfalls. We should beware of modern narrow utilitarian meanings ascribed to the words in commercial dictionaries. We should try to preserve the metaphoric overtones. We should beware of English grammar, its hard parts of speech, and its lazy satisfaction with nouns and adjectives. We should seek and at least bear in mind the verbal undertone of each noun. We should avoid "is" and bring in a wealth of neglected English verbs. Most of the existing translations violate all of these rules.[10] The development of the normal transitive sentence rests upon the fact that one action in nature promotes another; thus the agent and the object are secretly verbs. For example, our sentence, "Reading promotes writing," would be expressed in Chinese by three full verbs. Such a form is the equivalent of three expanded clauses and can be drawn out into adjectival, participial, infinitive, relative or conditional members. One of many possible examples is, "If one reads it teaches him how to write." Another is, "One who reads becomes one who writes." But in the first condensed form a Chinese would write, "Read promote write." The dominance of the verb and its power to obliterate all other parts of speech give us the model of terse fine style.
- 64. I have seldom seen our rhetoricians dwell on the fact that the great strength of our language lies in its splendid array of transitive verbs, drawn both from Anglo-Saxon and from Latin sources. These give us the most individual characterizations of force. Their power lies in their recognition of nature as a vast storehouse of forces. We do not say in English that things seem, or appear, or eventuate, or even that they are; but that they do. Will is the foundation of our speech.[11] We catch the Demiurge in the act. I had to discover for myself why Shakespeare's English was so immeasurably superior to all others. I found that it was his persistent, natural, and magnificent use of hundreds of transitive verbs. Rarely will you find an "is" in his sentences. "Is" weakly lends itself to the uses of our rhythm, in the unaccented syllables; yet he sternly discards it. A study of Shakespeare's verbs should underlie all exercises in style. We find in poetical Chinese a wealth of transitive verbs, in some way greater even than in the English of Shakespeare. This springs from their power of combining several pictorial elements in a single character. We have in English no verb for what two things, say the sun and moon, both do together. Prefixes and affixes merely direct and qualify. In Chinese the verb can be more minutely qualified. We find a hundred variants clustering about a single idea. Thus "to sail a boat for purposes of pleasure" would be an entirely different verb from "to sail for purposes of commerce." Dozens of Chinese verbs express various shades of grieving, yet in English translations they are usually reduced to one mediocrity. Many of them can be expressed only by periphrasis, but what right has the translator to neglect the overtones? There are subtle shadings. We should strain our resources in English. It is true that the pictorial clue of many Chinese ideographs can not now be traced, and even Chinese lexicographers admit that combinations frequently contribute only a phonetic value. But I find it incredible that any such minute subdivision of the idea could have ever existed alone as abstract sound without the concrete character. It contradicts the law of evolution. Complex ideas arise only gradually, as the power of holding them together arises. The paucity of Chinese sound could not so hold them. Neither is it conceivable that the whole list was made at once, as commercial codes of cipher are compiled. Therefore we must believe that the phonetic theory is in large part unsound. The metaphor once existed in many cases where we can not now trace it. Many of our own
- 65. etymologies have been lost. It is futile to take the ignorance of the Han dynasty for omniscience.[12] It is not true, as Legge said, that the original picture characters could never have gone far in building up abstract thought. This is a vital mistake. We have seen that our own languages have all sprung from a few hundred vivid phonetic verbs by figurative derivation. A fabric more vast could have been built up in Chinese by metaphorical composition. No attenuated idea exists which it might not have reached more vividly and more permanently than we could have been expected to reach with phonetic roots. Such a pictorial method, whether the Chinese exemplified it or not, would be the ideal language of the world. Still, is it not enough to show that Chinese poetry gets back near to the processes of nature by means of its vivid figure, its wealth of such figure? If we attempt to follow it in English we must use words highly charged, words whose vital suggestion shall interplay as nature interplays. Sentences must be like the mingling of the fringes of feathered banners, or as the colors of many flowers blended into the single sheen of a meadow. The poet can never see too much or feel too much. His metaphors are only ways of getting rid of the dead white plaster of the copula. He resolves its indifference into a thousand tints of verb. His figures flood things with jets of various light, like the sudden upblaze of fountains. The prehistoric poets who created language discovered the whole harmonious framework of nature, they sang out her processes in their hymns. And this diffused poetry which they created, Shakespeare has condensed into a more tangible substance. Thus in all poetry a word is like a sun, with its corona and chromosphere; words crowd upon words, and enwrap each other in their luminous envelopes until sentences become clear, continuous light-bands. Now we are in condition to appreciate the full splendor of certain lines of Chinese verse. Poetry surpasses prose especially in that the poet selects for juxtaposition those words whose overtones blend into a delicate and lucid harmony. All arts follow the same law; refined harmony lies in the delicate balance of overtones. In music the whole possibility and theory of harmony is based on the overtones. In this sense poetry seems a more difficult art.
- 66. How shall we determine the metaphorical overtones of neighboring words? We can avoid flagrant breaches like mixed metaphor. We can find the concord or harmonizing at its intensest, as in Romeo's speech over the dead Juliet. Here also the Chinese ideography has its advantage, in even a simple line, for example, "The sun rises in the east." The overtones vibrate against the eye. The wealth of composition in characters makes possible a choice of words in which a single dominant overtone colors every plane of meaning. That is perhaps the most conspicuous quality of Chinese poetry. Let us examine our line. Sun Rises (in the) East. The sun, the shining, on one side, on the other the sign of the east, which is the sun entangled in the branches of a tree. And in the middle sign, the verb "rise," we have further homology; the sun is above the horizon, but beyond that the single upright line is like the growing trunk- line of the tree sign. This is but a beginning, but it points a way to the method, and to the method of intelligent reading. [1] The apology was unnecessary, but Professor Fenollosa saw fit to make it, and I therefore transcribe his words.—E.P. [2] Style, that is to say, limpidity, as opposed to rhetoric.—E.P. [3] Even Latin, living Latin had not the network of rules they foist upon unfortunate school-children. These are borrowed sometimes from Greek grammarians, even as I have seen English grammars borrowing oblique cases from Latin grammars. Sometimes they sprang from the grammatizing or categorizing passion of pedants. Living Latin had only the feel of the cases: the ablative and dative emotion.—E.P. [4] A good writer would use "shine" (i.e., to shine), shining, and "the shine" or "sheen", possibly thinking of the German "schöne" and "Schönheit"; but this does not invalidate Prof. Fenollosa's next contention.—E.P. [5] This is a bad example. We can say "I look a fool", "look", transitive, now means resemble. The main contention is however correct. We tend to abandon specific words
- 67. like resemble and substitute, for them, vague verbs with prepositional directors, or riders.—E.P. [6] Cf. principle of Primary apparition, "Spirit of Romance".—E.P. [7] Compare Aristotle's Poetics.—E.P. [8] Vide also an article on "Vorticism" in the Fortnightly Review for September, 1914. "The language of exploration" now in my "Gaudier-Brzeska."—E.P. [9] I would submit in all humility that this applies in the rendering of ancient texts. The poet in dealing with his own time, must also see to it that language does not petrify on his hands. He must prepare for new advances along the lines of true metaphor that is interpretative metaphor, or image, as diametrically opposed to untrue, or ornamental metaphor.—E.P. [10] These precautions should be broadly conceived. It is not so much their letter, as the underlying feeling of objectification and activity, that matters.—E.P. [11] Compare Dante's definition of "rectitudo" as the direction of the will, probably taken from Aquinas.—E.P. [12] Professor Fenollosa is well borne out by chance evidence. The vorticist sculptor Gaudier-Brzeska sat in my room before he went off to the war. He was able to read the Chinese radicals and many compound signs almost at pleasure. He was of course, used to consider all life and nature in the terms of planes and of bounding lines. Nevertheless he had spent only a fortnight in the museum studying the Chinese characters. He was amazed at the stupidity of lexicographers who could not discern for all their learning the pictorial values which were to him perfectly obvious and apparent. Curiously enough, a few weeks later Edmond Dulac, who is of a totally different tradition, sat here, giving an impromptu panegyric on the elements of Chinese art, on the units of composition, drawn from the written characters. He did not use Professor Fenollosa's own words, he said "bamboo" instead of "rice". He said the essence of the bamboo is in a certain way it grows, they have this in their sign for bamboo, all designs of bamboo proceed from it. Then he went on rather to disparage vorticism, on the grounds that it could not hope to do for the Occident, in one life-time, what had required centuries of development in China.—E.P.
- 68. *** END OF THE PROJECT GUTENBERG EBOOK INSTIGATIONS *** Updated editions will replace the previous one—the old editions will be renamed. Creating the works from print editions not protected by U.S. copyright law means that no one owns a United States copyright in these works, so the Foundation (and you!) can copy and distribute it in the United States without permission and without paying copyright royalties. Special rules, set forth in the General Terms of Use part of this license, apply to copying and distributing Project Gutenberg™ electronic works to protect the PROJECT GUTENBERG™ concept and trademark. Project Gutenberg is a registered trademark, and may not be used if you charge for an eBook, except by following the terms of the trademark license, including paying royalties for use of the Project Gutenberg trademark. If you do not charge anything for copies of this eBook, complying with the trademark license is very easy. You may use this eBook for nearly any purpose such as creation of derivative works, reports, performances and research. Project Gutenberg eBooks may be modified and printed and given away—you may do practically ANYTHING in the United States with eBooks not protected by U.S. copyright law. Redistribution is subject to the trademark license, especially commercial redistribution. START: FULL LICENSE
- 69. THE FULL PROJECT GUTENBERG LICENSE
- 70. PLEASE READ THIS BEFORE YOU DISTRIBUTE OR USE THIS WORK To protect the Project Gutenberg™ mission of promoting the free distribution of electronic works, by using or distributing this work (or any other work associated in any way with the phrase “Project Gutenberg”), you agree to comply with all the terms of the Full Project Gutenberg™ License available with this file or online at www.gutenberg.org/license. Section 1. General Terms of Use and Redistributing Project Gutenberg™ electronic works 1.A. By reading or using any part of this Project Gutenberg™ electronic work, you indicate that you have read, understand, agree to and accept all the terms of this license and intellectual property (trademark/copyright) agreement. If you do not agree to abide by all the terms of this agreement, you must cease using and return or destroy all copies of Project Gutenberg™ electronic works in your possession. If you paid a fee for obtaining a copy of or access to a Project Gutenberg™ electronic work and you do not agree to be bound by the terms of this agreement, you may obtain a refund from the person or entity to whom you paid the fee as set forth in paragraph 1.E.8. 1.B. “Project Gutenberg” is a registered trademark. It may only be used on or associated in any way with an electronic work by people who agree to be bound by the terms of this agreement. There are a few things that you can do with most Project Gutenberg™ electronic works even without complying with the full terms of this agreement. See paragraph 1.C below. There are a lot of things you can do with Project Gutenberg™ electronic works if you follow the terms of this agreement and help preserve free future access to Project Gutenberg™ electronic works. See paragraph 1.E below.
- 71. 1.C. The Project Gutenberg Literary Archive Foundation (“the Foundation” or PGLAF), owns a compilation copyright in the collection of Project Gutenberg™ electronic works. Nearly all the individual works in the collection are in the public domain in the United States. If an individual work is unprotected by copyright law in the United States and you are located in the United States, we do not claim a right to prevent you from copying, distributing, performing, displaying or creating derivative works based on the work as long as all references to Project Gutenberg are removed. Of course, we hope that you will support the Project Gutenberg™ mission of promoting free access to electronic works by freely sharing Project Gutenberg™ works in compliance with the terms of this agreement for keeping the Project Gutenberg™ name associated with the work. You can easily comply with the terms of this agreement by keeping this work in the same format with its attached full Project Gutenberg™ License when you share it without charge with others. 1.D. The copyright laws of the place where you are located also govern what you can do with this work. Copyright laws in most countries are in a constant state of change. If you are outside the United States, check the laws of your country in addition to the terms of this agreement before downloading, copying, displaying, performing, distributing or creating derivative works based on this work or any other Project Gutenberg™ work. The Foundation makes no representations concerning the copyright status of any work in any country other than the United States. 1.E. Unless you have removed all references to Project Gutenberg: 1.E.1. The following sentence, with active links to, or other immediate access to, the full Project Gutenberg™ License must appear prominently whenever any copy of a Project Gutenberg™ work (any work on which the phrase “Project
- 72. Gutenberg” appears, or with which the phrase “Project Gutenberg” is associated) is accessed, displayed, performed, viewed, copied or distributed: This eBook is for the use of anyone anywhere in the United States and most other parts of the world at no cost and with almost no restrictions whatsoever. You may copy it, give it away or re-use it under the terms of the Project Gutenberg License included with this eBook or online at www.gutenberg.org. If you are not located in the United States, you will have to check the laws of the country where you are located before using this eBook. 1.E.2. If an individual Project Gutenberg™ electronic work is derived from texts not protected by U.S. copyright law (does not contain a notice indicating that it is posted with permission of the copyright holder), the work can be copied and distributed to anyone in the United States without paying any fees or charges. If you are redistributing or providing access to a work with the phrase “Project Gutenberg” associated with or appearing on the work, you must comply either with the requirements of paragraphs 1.E.1 through 1.E.7 or obtain permission for the use of the work and the Project Gutenberg™ trademark as set forth in paragraphs 1.E.8 or 1.E.9. 1.E.3. If an individual Project Gutenberg™ electronic work is posted with the permission of the copyright holder, your use and distribution must comply with both paragraphs 1.E.1 through 1.E.7 and any additional terms imposed by the copyright holder. Additional terms will be linked to the Project Gutenberg™ License for all works posted with the permission of the copyright holder found at the beginning of this work. 1.E.4. Do not unlink or detach or remove the full Project Gutenberg™ License terms from this work, or any files
- 73. containing a part of this work or any other work associated with Project Gutenberg™. 1.E.5. Do not copy, display, perform, distribute or redistribute this electronic work, or any part of this electronic work, without prominently displaying the sentence set forth in paragraph 1.E.1 with active links or immediate access to the full terms of the Project Gutenberg™ License. 1.E.6. You may convert to and distribute this work in any binary, compressed, marked up, nonproprietary or proprietary form, including any word processing or hypertext form. However, if you provide access to or distribute copies of a Project Gutenberg™ work in a format other than “Plain Vanilla ASCII” or other format used in the official version posted on the official Project Gutenberg™ website (www.gutenberg.org), you must, at no additional cost, fee or expense to the user, provide a copy, a means of exporting a copy, or a means of obtaining a copy upon request, of the work in its original “Plain Vanilla ASCII” or other form. Any alternate format must include the full Project Gutenberg™ License as specified in paragraph 1.E.1. 1.E.7. Do not charge a fee for access to, viewing, displaying, performing, copying or distributing any Project Gutenberg™ works unless you comply with paragraph 1.E.8 or 1.E.9. 1.E.8. You may charge a reasonable fee for copies of or providing access to or distributing Project Gutenberg™ electronic works provided that: • You pay a royalty fee of 20% of the gross profits you derive from the use of Project Gutenberg™ works calculated using the method you already use to calculate your applicable taxes. The fee is owed to the owner of the Project Gutenberg™ trademark, but he has agreed to donate royalties under this paragraph to the Project Gutenberg Literary Archive Foundation. Royalty
- 74. payments must be paid within 60 days following each date on which you prepare (or are legally required to prepare) your periodic tax returns. Royalty payments should be clearly marked as such and sent to the Project Gutenberg Literary Archive Foundation at the address specified in Section 4, “Information about donations to the Project Gutenberg Literary Archive Foundation.” • You provide a full refund of any money paid by a user who notifies you in writing (or by e-mail) within 30 days of receipt that s/he does not agree to the terms of the full Project Gutenberg™ License. You must require such a user to return or destroy all copies of the works possessed in a physical medium and discontinue all use of and all access to other copies of Project Gutenberg™ works. • You provide, in accordance with paragraph 1.F.3, a full refund of any money paid for a work or a replacement copy, if a defect in the electronic work is discovered and reported to you within 90 days of receipt of the work. • You comply with all other terms of this agreement for free distribution of Project Gutenberg™ works. 1.E.9. If you wish to charge a fee or distribute a Project Gutenberg™ electronic work or group of works on different terms than are set forth in this agreement, you must obtain permission in writing from the Project Gutenberg Literary Archive Foundation, the manager of the Project Gutenberg™ trademark. Contact the Foundation as set forth in Section 3 below. 1.F. 1.F.1. Project Gutenberg volunteers and employees expend considerable effort to identify, do copyright research on, transcribe and proofread works not protected by U.S. copyright
- 75. law in creating the Project Gutenberg™ collection. Despite these efforts, Project Gutenberg™ electronic works, and the medium on which they may be stored, may contain “Defects,” such as, but not limited to, incomplete, inaccurate or corrupt data, transcription errors, a copyright or other intellectual property infringement, a defective or damaged disk or other medium, a computer virus, or computer codes that damage or cannot be read by your equipment. 1.F.2. LIMITED WARRANTY, DISCLAIMER OF DAMAGES - Except for the “Right of Replacement or Refund” described in paragraph 1.F.3, the Project Gutenberg Literary Archive Foundation, the owner of the Project Gutenberg™ trademark, and any other party distributing a Project Gutenberg™ electronic work under this agreement, disclaim all liability to you for damages, costs and expenses, including legal fees. YOU AGREE THAT YOU HAVE NO REMEDIES FOR NEGLIGENCE, STRICT LIABILITY, BREACH OF WARRANTY OR BREACH OF CONTRACT EXCEPT THOSE PROVIDED IN PARAGRAPH 1.F.3. YOU AGREE THAT THE FOUNDATION, THE TRADEMARK OWNER, AND ANY DISTRIBUTOR UNDER THIS AGREEMENT WILL NOT BE LIABLE TO YOU FOR ACTUAL, DIRECT, INDIRECT, CONSEQUENTIAL, PUNITIVE OR INCIDENTAL DAMAGES EVEN IF YOU GIVE NOTICE OF THE POSSIBILITY OF SUCH DAMAGE. 1.F.3. LIMITED RIGHT OF REPLACEMENT OR REFUND - If you discover a defect in this electronic work within 90 days of receiving it, you can receive a refund of the money (if any) you paid for it by sending a written explanation to the person you received the work from. If you received the work on a physical medium, you must return the medium with your written explanation. The person or entity that provided you with the defective work may elect to provide a replacement copy in lieu of a refund. If you received the work electronically, the person or entity providing it to you may choose to give you a second opportunity to receive the work electronically in lieu of a refund.
- 76. If the second copy is also defective, you may demand a refund in writing without further opportunities to fix the problem. 1.F.4. Except for the limited right of replacement or refund set forth in paragraph 1.F.3, this work is provided to you ‘AS-IS’, WITH NO OTHER WARRANTIES OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO WARRANTIES OF MERCHANTABILITY OR FITNESS FOR ANY PURPOSE. 1.F.5. Some states do not allow disclaimers of certain implied warranties or the exclusion or limitation of certain types of damages. If any disclaimer or limitation set forth in this agreement violates the law of the state applicable to this agreement, the agreement shall be interpreted to make the maximum disclaimer or limitation permitted by the applicable state law. The invalidity or unenforceability of any provision of this agreement shall not void the remaining provisions. 1.F.6. INDEMNITY - You agree to indemnify and hold the Foundation, the trademark owner, any agent or employee of the Foundation, anyone providing copies of Project Gutenberg™ electronic works in accordance with this agreement, and any volunteers associated with the production, promotion and distribution of Project Gutenberg™ electronic works, harmless from all liability, costs and expenses, including legal fees, that arise directly or indirectly from any of the following which you do or cause to occur: (a) distribution of this or any Project Gutenberg™ work, (b) alteration, modification, or additions or deletions to any Project Gutenberg™ work, and (c) any Defect you cause. Section 2. Information about the Mission of Project Gutenberg™
- 77. Project Gutenberg™ is synonymous with the free distribution of electronic works in formats readable by the widest variety of computers including obsolete, old, middle-aged and new computers. It exists because of the efforts of hundreds of volunteers and donations from people in all walks of life. Volunteers and financial support to provide volunteers with the assistance they need are critical to reaching Project Gutenberg™’s goals and ensuring that the Project Gutenberg™ collection will remain freely available for generations to come. In 2001, the Project Gutenberg Literary Archive Foundation was created to provide a secure and permanent future for Project Gutenberg™ and future generations. To learn more about the Project Gutenberg Literary Archive Foundation and how your efforts and donations can help, see Sections 3 and 4 and the Foundation information page at www.gutenberg.org. Section 3. Information about the Project Gutenberg Literary Archive Foundation The Project Gutenberg Literary Archive Foundation is a non- profit 501(c)(3) educational corporation organized under the laws of the state of Mississippi and granted tax exempt status by the Internal Revenue Service. The Foundation’s EIN or federal tax identification number is 64-6221541. Contributions to the Project Gutenberg Literary Archive Foundation are tax deductible to the full extent permitted by U.S. federal laws and your state’s laws. The Foundation’s business office is located at 809 North 1500 West, Salt Lake City, UT 84116, (801) 596-1887. Email contact links and up to date contact information can be found at the Foundation’s website and official page at www.gutenberg.org/contact
- 78. Section 4. Information about Donations to the Project Gutenberg Literary Archive Foundation Project Gutenberg™ depends upon and cannot survive without widespread public support and donations to carry out its mission of increasing the number of public domain and licensed works that can be freely distributed in machine-readable form accessible by the widest array of equipment including outdated equipment. Many small donations ($1 to $5,000) are particularly important to maintaining tax exempt status with the IRS. The Foundation is committed to complying with the laws regulating charities and charitable donations in all 50 states of the United States. Compliance requirements are not uniform and it takes a considerable effort, much paperwork and many fees to meet and keep up with these requirements. We do not solicit donations in locations where we have not received written confirmation of compliance. To SEND DONATIONS or determine the status of compliance for any particular state visit www.gutenberg.org/donate. While we cannot and do not solicit contributions from states where we have not met the solicitation requirements, we know of no prohibition against accepting unsolicited donations from donors in such states who approach us with offers to donate. International donations are gratefully accepted, but we cannot make any statements concerning tax treatment of donations received from outside the United States. U.S. laws alone swamp our small staff. Please check the Project Gutenberg web pages for current donation methods and addresses. Donations are accepted in a number of other ways including checks, online payments and
- 79. credit card donations. To donate, please visit: www.gutenberg.org/donate. Section 5. General Information About Project Gutenberg™ electronic works Professor Michael S. Hart was the originator of the Project Gutenberg™ concept of a library of electronic works that could be freely shared with anyone. For forty years, he produced and distributed Project Gutenberg™ eBooks with only a loose network of volunteer support. Project Gutenberg™ eBooks are often created from several printed editions, all of which are confirmed as not protected by copyright in the U.S. unless a copyright notice is included. Thus, we do not necessarily keep eBooks in compliance with any particular paper edition. Most people start at our website which has the main PG search facility: www.gutenberg.org. This website includes information about Project Gutenberg™, including how to make donations to the Project Gutenberg Literary Archive Foundation, how to help produce our new eBooks, and how to subscribe to our email newsletter to hear about new eBooks.
- 80. Welcome to our website – the perfect destination for book lovers and knowledge seekers. We believe that every book holds a new world, offering opportunities for learning, discovery, and personal growth. That’s why we are dedicated to bringing you a diverse collection of books, ranging from classic literature and specialized publications to self-development guides and children's books. More than just a book-buying platform, we strive to be a bridge connecting you with timeless cultural and intellectual values. With an elegant, user-friendly interface and a smart search system, you can quickly find the books that best suit your interests. Additionally, our special promotions and home delivery services help you save time and fully enjoy the joy of reading. Join us on a journey of knowledge exploration, passion nurturing, and personal growth every day! ebookbell.com