Contents

Chapter Title Page No

List of Abbreviations.............................................................................................................2
List of Figures........................................................................................................................4
List of Tables.........................................................................................................................5
Chapter 1 An Overview of Smartphone’s OSes..........................................................6
1.1 Different OSes available.................................................................................6
1.2 Comparisons of OSes....................................................................................12
Chapter 2 Introduction To Symbian OS......................................................................13
2.1 History...........................................................................................................13
2.2 Symbian OS User Interfaces.........................................................................13
2.3 Different UIs.................................................................................................14
Chapter3 Architecture................................................................................................17
3.1 Introduction...................................................................................................17
3.2 Basic Design Patterns of Symbian OS..........................................................18
3.3 Why Architecture Matters.............................................................................19
Chapter 4 Programming Model.....................................................................................22
4.1 Introduction...................................................................................................22
4.2 Creating a Console Application....................................................................22
4.3 The Structure of a Symbian OS Application.................................................25
Chapter 5 Tools...........................................................................................................26
5.1 Coding Idioms...............................................................................................27
5.2 Tool Chains...................................................................................................29
Chapter 6 Just Add Phone..........................................................................................32
6.1 Introduction...................................................................................................32
6.2 Anatomy of a Phone......................................................................................33
6.3 Telephony.....................................................................................................37
Chapter 7 Refrences...................................................................................................41

1
 List of Abbreviations
ADT: Abstract data type

BAL :Bearer Abstraction Layer

BIO: Bearer-independent object

CDMA: Code Division Multiple Access

DFRD :Device family reference design

DRM :Digital rights management

DSP :Digital Signal Processor

EDGE: Enhanced Data Service for GSM Evolution

ETSI :European Telecommunications Standards Institute

FOMA: Freedom of Mobile Access

GPRS :General Packet Radio Service

IPC: Interprocess communication

MOAP: Mobile Application Platform

MTM: Message type module

MVC: Model–view–controller

OBEX IrDA :Object Exchange

OMA: Open Mobile Alliance

OTA :Over the air

PAN: Personal Area Networking

PIM: Personal information manager

PLP: Psion Link Protocol

QoS: Quality of Service

RTOS: Real-time operating system

RTP: Real-time transport protocol

SIP: Session initiation protocol

SMIL: Synchronized Multimedia Integration Language

UART: Universal Asynchronous Transmitter/Receiver

2
UMTS: Universal Mobile Telecommunications System

VoIP: Voice over IP

VPN: Virtual Private Network

WAP: Wireless Application Protocol

WDP: Wireless Datagram Protocol

XIP: Execute in place

3
 List of Figures
Figure No. Name Page No.

1 Series 40 12

2 Series 40 Nokia 6260 13

3 UIQ Series-Sony Ericsson P1i 13

4 Series 60v3-Nokia N95 14

5 Series 60v5-Nokia 5800 14

4
 List of Tables
Table No. Name Page No.

1 Comparisons of OSes 10

5
Chapter 1

An Overview of Smartphone’s OSes

1.1 Different OSes available

Nokia S60 3rd Edition on Symbian

What it is: S60 3rd Edition is the version of the venerable

Symbian mobile OS found in a variety of smart phones, not only from Nokia
including its new N96) but also LG and Samsung.

Designed for devices without a touch screen, S60 3rd Edition makes you wade
through lots of menus; the BlackBerry OS deals with the lack of touch much more
intelligently.How it works:S60's interface dates from the days when even the smartest
phones sported only a numeric keypad and a few other buttons, and it tends to make you
shuffle through menus one laborious item at a time. (The BlackBerry OS does a much
better job of making non-touch-screen devices fast and efficient.)

How it looks: It's pretty old-fashioned by today's standards, with blocky fonts and retro
icons.

6
Built-in applications: The programs vary from phone to phone. The N96 I tried includes a
reasonably comprehensive suite of apps, and judged purely on available features, they're
respectable; the browser, for instance, has a zoom-in/zoom-out interface that's theoretically
similar to the one in iPhone OS's Safari. But the clunky interface leaves them feeling less
powerful than the apps on any other phone I tried for this article.

The S60's fonts and icons are serviceable, but they add to the operating system's
out-of-date look compared with iPhone OS, Android, and even the BlackBerry OS.Third-
party stuff: A profusion of useful S60-compatible applications is available at sites such as
Handango--one of the deepest libraries for any platform, thanks to Symbian's long life
span and wide usage.

Bottom line: S60 3rd Edition is stale in comparison with iPhone OS and Android, but it's
also heading for retirement. The new S60 5th Edition brings the OS up-to-date with
features such as touch-screen support; Nokia's 5800 XpressMusic, the first phone to use it,
won't arrive in the United States until early next year.

Microsoft Windows Mobile

What it is: This is Microsoft's mobile edition of Windows. Version 6.1 ships on a dozen
phones from manufacturers such as HTC (with its Touch Diamond), Motorola, Palm, and
Samsung.

7
 HTC's TouchFLO layers an iPhone-esque layer on top of Windows Mobile--it's
pretty, but nowhere near as usable as the real thing.Some manufacturers--including HTC
with the Diamond, Palm, and Samsung--supplement Windows Mobile with their own
software layer or tweaks to the underlying Windows Mobile OS.

How it works: Surprisingly, Windows Mobile acts like full-strength Windows, complete

with a Start menu and system tray. That isn't a virtue--who wants to squint at tiny icons on
devices meant for on-the-go use? The Touch Diamond covers up part of Microsoft's
stylus-oriented interface with a fingertip-driven system called TouchFLO that's nowhere
near as elegant and intuitive as the iPhone.

How it looks: It's workmanlike. But it falls far, far short of iPhone OS's surface gloss.

Built-in applications: The version of Internet Explorer on current phones is profoundly

archaic; the Touch Diamond dumps it for Opera Mobile. (Microsoft has released a new
version of IE, but it isn't yet available on any phones.) On the other hand, the productivity
apps--basic versions of Word, Excel, Outlook, and PowerPoint--aren't bad.

Windows Mobile brings desktop Windows features such as the File Explorer to
your phone--but many of them feel out of place when you're on the go.Third-party
stuff: The best thing about this OS is the sheer variety of available applications in every
category. Utilities such as Lakeridge Software's WisBar Advance let you tweak the
interface's look, feel, and functionality, compensating for some of its deficiencies. But you
get no built-in app store à la iPhone OS and Android.

8
Bottom line: Windows Mobile has fallen behind the times on multiple fronts. Microsoft's
next major overhaul isn't expected until late 2009 or 2010; by then, version 6.1 will be all
but irrelevant.

Google Android

What it is: Google's new phone OS is an ambitious open-source platform intended to let

companies customize it to their liking for an array of handsets. So far, however, it's
available on just one model,T-Mobile's G1.

How it works: On the G1, Android's interface feels like an iPhone/BlackBerry mashup
much of it uses the touch screen, but you get a trackball and Menu, Home, and Back
buttons, too. The highly customizable desktop is a plus. Ojverall, it compares well to older
platforms but isn't as effortless as the iPhone.

The Android desktop is reminiscent of those in desktop OSs like Windows Vista
and OS X Leopard. You can arrange shortcuts as you like and install widgets such as
clocks and search fields.How it looks: Android isn't an aesthetic masterpiece like iPhone
OS, but it's fresh and appealing, and it makes good use of the G1's high-resolution screen.

Built-in applications: They're tightly integrated with Google services such as

Gmail and Google Calendar--the first thing you do when you turn on the phone for the first
time is to give it yourGoogle account info. (That's fine as long as you're not dependent on
alternatives such asMicrosoft Exchange.)

Android's browser lacks the iPhone's multitouch navigation but is otherwise a close
rival. The best thing about its music features is the ability to download DRM-free songs
from Amazon. The only videos it can play are YouTube clips, alas.

9
 Like the iPhone, Android comes with an application that makes finding,
downloading, and installing third-party apps exceptionally easy.Third-party
stuff: Developers are just beginning to hop on the Android bandwagon. The iPhone-like
Market service lets you download apps directly to the phone from Google; unlike with the
iPhone, you can also snag programs from third-party merchants such as Handango.

Bottom line: Android's potential is gigantic, especially if it winds up on scads of phones.

On the G1, it's a promising work in progress.

Apple iPhone OS

What it is: iPhone OS is a pocket-size version of the Mac's OS X, shrunk down and

redesigned to power the iPhone 3G.

How it works: As you zip your way around the iPhone 3G's multitouch interface with
your fingertips, hardware and software blur into one pleasing experience. With other OSs,
it's all too easy to get lost in menus or forget how to accomplish simple tasks; iPhone apps,
however, are remarkably sleek and consistent. The OS's most infamous omission is cut-
and-paste capability--but to tell the truth, I haven't missed it yet.

How it looks: Terrific. Everything from the sophisticated typography to the smooth

animation effects contributes to the richest, most attractive environment ever put on a
handheld device.

10
 iPhone OS's Safari was the first browser to display pages designed for desktop
browsers with high fidelity; other OSs are scrambling to play catch-up.Built-in
applications: What's good is great--especially the Safari browser, which makes navigating
around sites that were never designed to be viewed on a phone remarkably simple. And the
OS's music and video programs truly are of iPod caliber. But as a productivity tool, the
iPhone lacks depth: You can't search e-mail, and you get no apps for editing documents or
managing a to-do list.

The best iPhone OS applications, such as the Evernote note-taker, are exceptionally
slick and useful--and many of them are free.Third-party stuff: Just months after Apple
opened up the iPhone to other developers, thousands of programs are available, and
downloading them directly via the App Store is a cakewalk. The best ones, such as
Facebook andthe Evernote note-taker, are outstanding. But thelimitations that Apple puts
on third-party apps--they can't run in the background or access data other than their own--
place major obstacles in the way of everything from instant messengers to office suites.
And Apple, the sole distributor of iPhone software, has declined to make available some
useful applications that developers have submitted.

Bottom line: iPhone OS is easily the most enjoyable and intuitive phone operating system
in existence, but its growth could be stunted unless Apple keeps its control-freak
tendencies in check

1.2 Comparisons of OSes

11
 Capacit
Model CPU RAM OS UI Size Weight Resolution Keyboard Camera Other
y
3-axis
accelerometer, 3-
axis
gyroscope, aGPS,
Apple
iO 5.0 MP AFwith LED flash multi-touch,
A4 16 or 32 512 62.8 cc SoftQWERT
iPhone 4[4] S 137 g 3.5" 640x960 andgeotagging, 1280x720 video at Proximity and
800 GB MB 115.2x58.6x9.3mm Y
4.0 30 fps ambient light
MHz
sensors, digital
compass, WiFi
b/g/n, Bluetooth
2.1+EDR

HTC Touch Window

528 MHz Qualcomm 512 HTC SoftQWERT 4.92 MP AF,
HD(aka HTC 288 MB s Mobile 87 cc 146 g 3.8" 480x800
MSM7201A MB TouchFlo3D Y 0.31 MP
Blackstone) 6.1

Symbian
OS 9.4 111 x 51.7 3.15 MP, Auto
Nokia 5800 434 MHz Freescale 256
128 MB Series 60 x 15.5 mm 109g 3.2" 360x640 Touchscreen Focus and Dual
XpressMusic MXC300-30 MB
5th 83 cc LED Flash
Edition

Sony Ericsson
Window
XPERIA 512 Full slide-
528 MHz ARM1136EJ-S 384 MB s Mobile 99cc 158g 3" 800x480 3.15mp AF
X1 (aka HTC MB outQWERTY
6.1
Venus)[37][38]

5mp Auto Focus,

face
Samsung Window
16 3.7" SoftQWERT detection,smile
SGH-i8000 800 MHz 256 MB s Mobile ? 117 g
GB 800x480AMOLED Y detection, geo
Omnia II 6.5
tagging, Dual
LED Flash

12
Chapter 2

Introduction To Symbian OS
2.1 History

Symbian Limited was founded by a group of major shareholders, originallyPsion,

Nokia and Ericsson in July 1998, with Motorola joining later that year, Matsushita in 1999
and Siemens in 2002. Motorola sold its stake in the company to Psion and Nokia in
September 2003, although it continues to produce phones based on Symbian OS. Psion’s
stake was then bought in pro-rata shares by Nokia, Panasonic, Siemens AG and Sony
Ericsson in July 2004.

Symbian OS had its beginnings in the old Psion EPOC software, and the early
versions of the operating system that shipped with phones in 1999 still carried that name.
(More information on the history and evolution of Symbian OS is available in The
Symbian OS Architecture Sourcebook by Ben Morris.) Mobile phones based on Symbian
OS v6.0 were ‘open’, meaning that users of the phones were able to install their own
software. Symbian OS v6.0 appeared in 2001 and shipped on the Nokia 9210
Communicator. Symbian OS continued to evolve with improved API functionality and
market-leading features, with the next big change occurring in early 2005 when Symbian
OS v9.0 was announced. This version was designed to be more secure and deliver major
cost savings to manufacturers – partly through new, standard tooling, which necessarily
meant that it would not support software compiled for earlier releases.

This chapter provides an introduction to Symbian OS, starting with the background
of the company and the development of the operating system. We then explain the
different user interfaces available for Symbian OS, which facilitate the production of
software on mobile phones with very different screen layouts and input mechanisms. We
then delve into the operating system itself by identifying the very specific coding idioms
used in Symbian OS, which are part of the process of producing very efficient and reliable
mobile software. The final section of this chapter is oncerned with the tools available to
would-be developers. It is fair to say that many people who have been programming on
Symbian OS for a number of years have found the performance of the tools highly
variable. It is, however, good to see that this situation is resolving itself.

2.2 Symbian OS User Interfaces

The different user interfaces available for Symbian OS are designed to allow
manufacturers to produce a range of phones in different styles, addressing many different
market segments. They essentially fall into three categories: S60 (formerly known as
Series 60), Series 80, and UIQ. There was a fourth category, Series 90, but this has now
been amalgamated into S60.

S60 consists of a suite of libraries and standard applications and is

intended to provide fully-featured modern mobile phones with large color
screens, which are most often referred to as smartphones. S60 is most often
associated with Nokia, which is by far the largest manufacturer of these

13
mobile phones, although S60 is also licensed to other major mobile-phone
manufacturers such as BenQ–Siemens, Samsung and Panasonic. S60 is most often
associated with the standard ITU keyboard layout for onehanded entry, although recent
versions also offer support for stylus entry. S60 supports applications developed in Java
ME, native Symbian C++, Python and FlashLite. The most important feature of S60
phones from an application developer’s perspective is that they allow new applications
to be installed after purchase. The screen size is generally 176 × 208 pixels, however this
is not defined in the specification. Some S60 devices have other screen sizes; for example,
Nokia N90 has a resolution of 352 × 288 pixels. Series 80 is primarily designed to target
the more business-orientated user with a device that accesses, views and manipulates data
using a large screen and a full keyboard. Currently only Nokia produces Series 80 devices
with screen resolutions of 640 × (200–240) pixels and a folding
case that reveals the full keyboard.

2.3 Different UIs

Figure 1:Series 40

14
Figure 2 : Series 40 Nokia 6260

Figure 3:UIQ Series-Sony Ericsson P1i

15
Figure 4:Series 60v3-Nokia N95

Figure 5:Series 60v5-Nokia 5800

16
Chapter 3

Architecture

3.1 Introduction
Architecture is goal driven. The architecture of a system is the vehicle through
which its design goals are realized. Even systems with relatively little formal architecture,
such as Unix,1 evolve according to more or less well-understood principles, to meet more
or less well-understood goals. And while not all systems are ‘architected’, all systems have
an architecture. Symbian OS follows a small number of strong design principles. Many
of these principles evolved as responses to the product ethos that was dominant when the
system was first being designed.2 That ethos can be summarized in a few simple rules.
• User data is sacred.
• User time is precious.
• All resources are scarce.
And perhaps this one too, ‘while beauty is in the eye of the beholder, elegance springs
from deep within a system’. In Symbian OS, that mantra is taken seriously. What results is
a handful of key design principles:
• ubiquitous use of servers: typically, resources are brokered by servers;
since the kernel itself is a server, this includes kernel-owned resources represented by R
classes.
pervasive asynchronous services: all resources are available to multiple simultaneous
clients; in other words, it is a service request and callback model rather than a blocking
model
• rigorous separation of user interfaces from services
• rigorous separation of application user interfaces from engines
• engine reuse and openness of engine APIs.
Two further principles follow from specific product requirements:
• pervasive support for instant availability and instant switching of
applications
• always-on systems, capable of running forever: robust management
and reclaiming of system resources.

Symbian OS certainly aims at unequaled robustness, making strong guarantees

about the integrity and safety (security) of user data and the ability of the system to run
without failure (to be crash-proof, in other words). From the beginning, it has also aimed
to be easy and intuitive to use and fully driven by a graphical user interface (GUI). (The
original conception included a full set of integrated applications and an attractive, intuitive
and usable GUI; ‘charming the user’ is an early Symbian OS slogan.3)

Perhaps as important as anything else, the operating system set outfrom the
beginning to be extensible, providing open application programminginterfaces (APIs),
including native APIs as well as support for theVisual Basic-like OPL language and Java,
and easy access to Software Development Kits (SDKs)4 and development tools.

However, systems do not stand still; architectures are dynamic and evolve.
Symbian OS has been in a state of continuous evolution since it first reached market in late
2000; and for the three years before that it had been evolving from a PDA operating

17
system to one specifically targeting the emerging market for mobile phones equipped with
PDA functions. In view of this, it may seem remarkable that the operating system exhibits
as much clarity and consistency in design as it does.

Architectures evolve partly driven by pressures from within the system and partly
they evolve under external pressures, such as pressures from the broad market, from
customers and from competition. Recent major releases of Symbian OS have introduced
some radical changes, in particular:
• a real-time kernel, driven by evolving future market needs, in particular, phone vendors
chasing new designs (for example, ‘single core’ phones) and new features (for example,
multimedia)
• platform security, driven by broader market needs including operator, user and licensee
needs for a secure software platform. While both are significant (and profound) changes,
from a system perspective they have had a relatively small impact on the overall shape
of the system. Interestingly, in both cases the pressure to address these particular market
needs arose internally in Symbian in anticipation of the future market and ahead of
demand from customers. It is tempting to idealize architecture. In the real world, all
software architecture is a combination of principle and expediency, purity and pragmatism.
Through the system lifecycle, for anything but the shortest-lived systems, it is part
genuine, forward-looking design and part retrofitting; in other words, part architecture and
part re-architecture. Some of the patterns that are present in Symbian OS were also present
(or, in any case, had been tried out) in its immediate precursors, the earlier Psion operating
systems. The 16-bit operating system (SIBO) had extended the basic server-based,
asynchronous, multitasking model of previous Psion products and re-engineered it using
object-oriented techniques. SIBO also pioneered the approach to GUI design, designed
communications services into the system at a deep level, and experimented with some
idioms which have since become strongly identified with Symbian OS (active objects, for
example). In fact, surprisingly many features of Symbian OS have evolved from features
of the earlier system:
• the fully integrated application suite: even though Symbian OS no longer includes a user
interface or applications, it remains strongly application-centric
• ubiquitous asynchronous services
• optimization for battery-based devices

• an event-driven programming model

• cross-platform development: the developers’ mindset was more that of embedded
systems engineering than the standard micro-computer or PC model.6
SIBO also introduced some of the programming constraints which show up in Symbian
OS, for example forbidding global static variables in DLLs (because the compilers of the
day could not support re-entrant DLLs), an early example of using the language and tools
to constrain developer choices and enforce design and implementation choices, a
consistent theme in Symbian’s approach to development. Symbian OS, or EPOC as it was
then, was able to benefit from the experience of the earlier implementation in SIBO. The
16-bit system was, in effect, an advanced prototype for EPOC.

3.2 Basic Design Patterns of Symbian OS

18
 The design principles of a system derive from its design goals and are realized in
the concrete design patterns of the system. The key designpatterns of Symbian OS include
the following:
• the microkernel pattern: kernel responsibilities are reduced to an essential minimum
• the client–server pattern: resources are shared between multiple users, whether system
services or applications
• frameworks: design patterns are used at all levels, from applications (plug-ins to the
application framework) to device drivers (plug-ins to the kernel-side device-driver
framework) and at all levels in between, but especially for hardware adaptation-level
interfaces
• the graphical application model: all applications are GUI and only servers have no user
interface
• an event-based application model: all user interaction is captured as events that.
• specific idioms aimed at improving robustness: for example, active objects manage
asynchronous services (in preference, for example, to explicit multi-threading) and
descriptors are used for type-safe and memory-safe strings
• streams and stores for persistent data storage: the natural ‘document’ model for
applications (although conventional file-based application idioms are supported)
• the class library (the User Library) providing other user services and access to kernel
services.

3.3 Why Architecture Matters

‘Doing architecture’ in a complex commercial context is not easy. Arguably all

commercial contexts are complex (certainly they are all different), in which case
architecture will never be easy. However, the business model for Symbian OS is
particularly complex. While it must be counted as part of Symbian’s success, it also
creates a unique set of problems to overcome and work around, and to some extent those
problems are then manifested as problems for software architecture. Architecture serves a
concrete purpose; it makes management of the system easier or more difficult, in
particular:
• managing the functional behavior and supported technologies
• managing the size and performance
• retaining the ability to evolve the system.
Elegance, consistency, and transparency were all early design drivers in the creation of the
system. Charles Davies, now Symbian CTO, was the early architect of the higher layers of
the operating system.
Charles Davies:
I remember looking at Windows at that time and thinking that this is all very well,
here is this Windows API, but just look what’s happening underneath it, it was ugly. I
wanted something that you could look inside of. The early ‘ethic of robustness’, to use his
phrase, came straight from the product vision.

Managing the Bounds of the System

In some ways, the hardest thing of all for Symbian is managing the impact of its
business model on the properties of the system and, in particular, the problem that Charles
Davies calls ‘defining the skin’ – understanding, maintaining, and managing the bounds of
the system under the impact of the business model. As well as originating the requirements
push and feeding the requirements pipeline, generating almost all of the external pressure
on the system to evolve and grow, licensees and partners also create their own extensions

19
to the system. (S60, arguably, is the most extreme example, constituting a complete system
in itself, at around twice the size of the operating system.)
Being clear where to draw the boundary between the responsibilities of Symbian OS and
the responsibilities of GUIs, in terms of who makes what and where the results fit into the
architecture, becomes difficult.
Charles Davies is eloquent on the subject.
Charles Davies:
One of the things I’ve done since being here is to try and identify where the skin of
Symbian OS is, to define the skin. When I was at Psion and we were building a PDA, I
understood where the PDA ended and where the things outside the PDA began, and so I
knew the boundaries of the product. And then I came to Symbian and Symbian OS, and I
thought, where are the boundaries? It’s really tough to know where the boundaries are, and
I still sometimes wonder if we really know that. That’s debilitating from the point of view
of knowing what to do. In reality we’re trying to fit some kind of rational boundary to our
throughput, because you can’t do everything. We’ve got, say, 750 people in software
engineering working on Symbian OS, and we can’t make that 1500 and we don’t want to
make that 200. So with 750 people, what boundary can we draw that matches a decent
product? In one sense the problem is particular to the business model that Symbian has
evolved, and is less a question of pure technology management, which to some extent
takes care of itself (or should, with a little help to balance the sometimes competing needs
of different licensees), than of driving the operating system vision in the absence of a
wider product vision. In that wider sense, the licensees have products; Symbian OS has
technologies and it is harder to say what the source of the technology vision for the
operating system itself should be. To remain at the front of the field, Symbian OS must
lead, but on the whole, customers would prefer that the operating system simply maps the
needs of their own leading products. The problem is that by the time the customer product
need emerges, the operating system is going to be too late if it cannot already support it.
(At least, in the case of complex technologies and, increasingly, all new mobile
technologies are complex.) Customers therefore build their own extensions or license them
from elsewhere, and the operating system potentially fails under the weight of
incompatibilities or missing technologies).

Product companies are easier to manage than technology companies because it is

clear what product needs are; either they align with the market needs or the product fails in
the market. The Symbian model is harder and forever raises the question of whether
Symbian is simply a supplier or integrator to its customers, or an innovator. Is Symbian a
product company, where the operating system is the product, or does it merely provide a
useful ‘bag of bits’?

Architecture is at the heart of the answer. If there is an architecture to describe,

then there is more to the operating system than the sum of its parts.

Managing Competitive Threats

There are many external threats to Symbian OS. Some of the threats are household
names. Microsoft is an obvious threat, but the likelihood is that Microsoft itself will
always be unacceptable to some part of the market, whatever the quality of its technology
offering. (It is hard to see Nokia phones, for example, sharing branding with Microsoft
Windows, and the same issues no doubt apply to some network operators, but clearly not
to all of them.) It is almost as certain that Nokia in turn is unacceptable to some other parts
of the market. S60 aims at building a stable of licensees, vendors for whom the advantages
of adopting a proven, market-ready user interface outweigh the possible disadvantages of
licensing a solution from a competitor, or the costs of developing an in-house solution.
20
There will always be vendors, though, for whom licensing from Nokia is likely to be
unacceptable. Interestingly, the more Microsoft resorts to branding its own phones, in
order to increase market share, the more it competes with those it is seeking to license to. It
is hard to see any scenario in which the phone market could become as homogeneous as
the PC market. Linux is also a clear and visible threat, even though again there are natural
pockets of resistance. Linux, for example, is viral. Linux does not just take out
competitors, it takes out whole parts of the software economy, and it is not yet clear what it
replaces them with.7 To put Linux in a phone, for example, seems to require just the same
‘old’ software economy as to put any other operating system into a phone, dedicated
software development divisions which do the same things that other software development
divisions do: write code, miss deadlines, fix defects, pay salaries. Linux may be royalty-
free, but that translates into ‘not-free-at-all’ if you have to bring it inside your own
dedicated software division. Nonetheless, to ignore Linux would be a (possibly fatal)
mistake.
Architecture is part of the answer. If Symbian OS is a better solution, it is because
its architecture is more fit for purpose than that of its competitors, not because its
implementation is better. Implementation is a second-order property, easy to replace or
improve. Architecture, in contrast, is a deep property.

21
Chapter 4

Programming Model
4.1 Introduction

It is traditional for programming books to start with a ‘Hello World’ application

and this book is no exception, as there is still something reassuring about being able to
print a couple of words to the screen. Although a Symbian OS device is a based on a
graphical user interface (GUI), we are going to start with a console-based version of ‘Hello
World’, as it is both simple and a useful tool for testing an application engine. An
application’s engine is the core logic at the heart of the application, where all the
information or data processing is carried out as directed by the user interface. Examples
are a game’s algorithm processing, the storage and retrieval of data in a database
application and the message processing of a chat application. The code is independent of
the GUI and so the code is the same across devices – a chess game has the same logic
regardless of the specific Symbian GUI used (for example, S60 or UIQ).

4.2 Creating a Console Application

For a basic (minimal) ‘Hello World’ application, we need three files:

bld.inf, helloworld.mmp, and helloworld.cpp.
The bld.inf file contains information about where to find the individualcomponents of an
application, as well as the platforms supported(for example, emulator or target). For simple
applications, there will be only one component and so the bld.inf file may simply point to
the.mmp file.
The .mmp file is the project definition file. This file lists and describes each of the
individual source code files and libraries required by the application or component, as well
as directory locations and other project-defined assets. This file can be used to generate the
appropriate project files for your chosen Integrated Development Environment
(IDE), and so allows for a software-independent definition of your application.
The .cpp file contains the source code for the console application.
This is the part of the code that tells the compiler what function we want
the phone to perform.
The console application we are going to develop is an executable (EXE) file.
Symbian OS applications are usually a special form of dynamic link library (DLL). A DLL
is a dynamic link library that contains functions available for use by other applications.
DLLs are more rigid than EXEs in their use of memory (an advantage on a memory-
limited device) and are, for example, not allowed to contain global variables.
On Symbian OS, an application is a DLL with file extension .app for OS versions prior to
Symbian OS v9. From version 9 onwards Symbian applications are executable files with
extension .exe. However, in both cases, console applications are compiled as .exe files, so
our first example is fairly straightforward.
In order to prevent malicious applications from accessing low-level features in the phone,
Symbian OS v9 introduces a strict security model that requires applications to be signed. A
distributable application must go through the full Symbian Signed
(www.symbiansigned.com) signing process (see Chapter 8) and development versions
can be signed using a certificate generated by the user for a specific phone by linking the
certificate to the IMEI number. At this basic level of certification, applications can access
local services (such as Bluetooth and location APIs), read and write user data, access
network features, etc. However, applications cannot access the file system, DRM APIs or
22
other sensitive functionality without having the application approved and signed by a
mobile-phone manufacturer.
This is quite enough of the preamble, so let’s get started on our first application. It
is a good idea to practice good development techniques, even with relatively trivial
applications such as this. The three files should therefore be stored in separate
subdirectories that can then provide additional information to help other developers
understand their purpose. Note that directory names and the paths to them should not
contain spaces since the Symbian OS toolset relies heavily on command-line tools, which
make it difficult to deal with such directory names.
The project should be placed in a directory called helloworld. Within this directory,
there should be two further subdirectories, called group and source. There are no hard and
fast rules as to what subdirectory names to use and which files to place within each, but we
will aim to use a set of names and locations that are used commonly in Symbian OS
development. The bld.inf and helloworld.mmp files should be placed in the group
directory and the helloworld.cpp file should be placed in the source directory. The code
listings for these files are as follows.
bld.inf
PRJ_MMPFILES
helloworld.mmp
The first line’s label, PRJ_MMPFILES, indicates that a list of the .mmp
files contained in the project will follow, and sure enough, the second
line lists this project’s single .mmp file.
helloworld.mmp
TARGET helloworld.exe
TARGETTYPE exe
SOURCEPATH ..\src
UID 0
SOURCE helloworld.cpp
USERINCLUDE ..\inc
SYSTEMINCLUDE \epoc32\include
LIBRARY euser.lib
This is the project definition file, which lists the name of the compiled application
(the target), the target type (in this case, an EXE), the directory that contains the .cpp files
for the project (the source path), the unique identifier for the application, the directory that
contains the .h files (the user include directory), the directory that contains the API header
files (the system include directory), and a list of library files to be compiled against. In this
case, we are using only one library, euser.lib. helloworld.cpp

#include <e32base.h>
#include <e32cons.h>
LOCAL_D CConsoleBase* gConsole;
// main function
LOCAL_C void MainL()
{
_LIT(KHelloWorldString, "Hello World\n");
gConsole->Printf(KHelloWorldString);
}
// Console Harness
LOCAL_C void ConsoleMainL()
{
_LIT(KConsoleTitle,"Hello World!");

23
gConsole = Console::NewL(KConsoleTitle, TSize(KConsFullScreen,
KConsFullScreen));
MainL();
}
// EPOC's main entry point
GLDEF_C TInt E32Main()
{
ConsoleMainL();
User::After(5000000);
return 0;
}

This is the source code for the application. The first function called by a Symbian
OS phone when an application is started is the E32Main() function, which builds the rest
of the application. This example is very simple: the main function uses the console
harness, ConsoleMainL(), to create a console for the application, waits for 5 000 000
microseconds, and then exits the program.
The console harness creates a console, gConsole (the g indicates that it is a global
variable, which is permitted in an EXE although not in a DLL). This console is titled
‘Hello World’ and the _LIT macro, KConsoleTitle, turns the name into a literal string,
which we will talk about later. The console is set to the full size of the screen. After
creating the console harness, it calls the main function, MainL(), which simply prints
‘Hello World’ to the screen. Note that the Symbian OS implementation of Printf() requires
a literal string as a parameter.

Building the Application

The only viable option for Symbian C++ application development is Carbide.C++.
As we mentioned previously, it is recommended that beginners use the free Carbide.C++
Express edition and then migrate to Carbide.C++ Developer edition as required. It is also
useful to gain a basic understanding of the command-line tools, particularly when it comes
to getting the application onto the phone. A couple of command-line tools you should
become familiar with are bldmake and abld. The bldmake tool processes the bld.inf file
and the corresponding .mmp files in the current directory to generate the batch file,
abld.bat, and a number of makefiles.
The easiest way to use bldmake is:

bldmake bldfiles

This creates the project directory within the \epoc32\build directory. It generates target-
specific makefiles for the component in this directory and finally creates the batch file,
abld.bat, in the current directory. The abld.bat file is used to control the building process of
the project. Before building the application, it is useful to clean (remove) the
previous binary files from the project:
abld clean

To remove the intermediate files, such as those from the \epoc32\

build directory use the following command:

abld reallyclean

This command is the same as abld clean, but it also removes

24
files exported by abld export and the makefiles generated by abld
makefile.
The simplest method for building the project is:
abld build

This will build the project for all possible build variants. However, it
is possible to build for a specific platform. The following command will
build a WINSCW platform version for debug:
abld build winscw udeb

An easier method of compiling and running the application is to import it into an IDE.
Having imported your application into Carbide.C++, you can compile it and run your
project in the emulator.
We have now created a basic framework with which we can test the logical engines
for our games and applications. (At this stage we have not begun to worry about memory
checking or the cleanup stack, because the size and complexity of the application is trivial
and, furthermore, a console application is not intended to be run on a phone.)

4.3 The Structure of a Symbian OS Application

A badly designed interface can ‘make or break’ any mobile application. A well-
designed graphical user interface (GUI) enables us to enhance the user experience by
allowing the user to interact through graphical images and menus, in addition to text. In
Chapter 1, we discussed some of the limitations of the mobile phone in terms of input and
display mechanisms. This chapter is less concerned about the philosophy of human–
computer interface design but more about how it can be implemented. We start with an
introduction to descriptors, a fundamental part of Symbian OS coding which is needed for
text manipulation and display. The following section discusses how to enhance the display
with graphics. We then introduce more complex images, such as bitmaps, as well as the
conversion of these images utilizing mixins. Finally, we show you how to handle user
input from the keypad before enabling you to enhance the simple textbased card game. The
game project is enhanced in this chapter with a much richer graphical environment, by
incorporating a menu structure to simplify game play and the use of card images to
enhance the look and

The S60 App Wizard (supplied with the S60 SDK) is the recommended
way to start a new application project. The wizard creates an empty application with a
menu, which is ready for you to add features and run.The wizard removes the repetitive
task of creating concrete instances of the foundation base classes of the Symbian OS
application framework.

The structure contains the following classes:

• The application class is responsible for setting up and executing the application. It
supplies a globally unique 32-bit identifier (UID) which is always associated with the
application (both in the build project and at run time). Changing the UID during the
lifetime of the project is not advisable since it is used in a number of places through the

25
application source files.
• The document class is created by the application class. It usually has strong ownership
of application data and is responsible for persisting and internalizing the data. This class
also instantiates the application user interface (AppUi) class. It is feasible for the document
class not to implement anything other than creating the application’s instance of the
AppUi.
• The application user interface is used for event handling. The AppUi acts as a global
event, and command, handler. It processes key presses and menu selections and can pass
these events on to the views and container classes that make up an application. The AppUi
is a controller that has no visible presence on the screen.
• Views and container classes provide the screens of the application. They are handled by
the view architecture. A view is essentially a container class associated with an ID. A
particular view can be activated from within the application or from another application by
supplying the UID of the application and the ID of the view. For very simple applications,
a single container class is used, rather than a view. (See Chapter 6 for more information on
views and containers.) Figure 4.1 shows the minimum number of classes that need to be
created to run an application. More classes may be added as the application evolves and
other screens or views are needed. As well as the source files, a fully fledged application
includes .hrh files, .rss application resource files (see Chapter 5) and files for building
the application installer package (the SIS file).

A standard directory structure for your application is recommended, in order to

maintain clarity as the application evolves. If we use a common structure for the project
we will have at least six folders and a build description file

Chapter 5

Tools

5.1 Coding Idioms

Naming Conventions

26
 Symbian OS has its own naming convention for classes, variables and functions.
The idea of using prefixes is similar to Hungarian notation, with different letters being
used. Naming conventions are used to improve readability, as they allow the programmer
to determine the nature of an item without looking at its implementation. As a general rule
of thumb, the name should be meaningful and neither overly abbreviated nor too long. As
programmers we need to find a happy medium.

Capitalization
The first letter of a class or function name should be capitalized. If a number of
words make up the name of a class, the start of each word should be capitalized:
class TMyClass; Function parameters and variable names should start with a lower-case
letter:
TMyClass myObject;

Prefixes
Non-static member variables are prefixed with the letter ‘i’, referring to an instance
of a class:
TInt iCount;
Function parameters are prefixed with the letter ‘a’, which stands for argument:
void MyFunction(TInt aParameter);
Automatic variables do not require a prefix.
for (TInt x = 0; x < 5; x++)
A constant is a value that does not change throughout the lifetime of a program. To prevent
this value being changed, it is defined as a constant, using const or #define. Constants are
prefixed with the letter ‘K’.
#define KMaxItemLength 32
An enumerated type is a list of constants that refer to integer values. This allows the
programmer to compare, for example, states of a game such as playing, paused or finished.
The name of an enumerated type is prefixed with ‘T’ and its members’ names are prefixed
with ‘E’. enum TGameStates (EPlaying, EPaused, EFinished);

Suffixes
Single-letter suffixes are only used in function names. The suffix ‘L’ is used to
indicate that the function in question may leave. A leaving function may not complete
successfully due to conditions such as unsuccessful memory allocation. If there are not
enough resources available then the function will cause a leave. As programmers, we are
able to handle events that may cause a leave by using trap harnesses (see Chapter 3).
However,
knowing which particular functions may leave is useful to a programmer and you should
always append the letter ‘L’ to a function name if its actions may cause a leave.
void FunctionMayLeaveL()
The suffix ‘C’ indicates that the function will return a pointer that has been pushed onto
the cleanup stack. The cleanup stack is used to store pointers that may become orphaned so
that if a leave occurs, cleanup can still be carried out. Chapter 3 gives a more detailed
overview of the cleanup stack and other memory issues.
CMyClass* NewLC()
The suffix ‘D’ indicates that the object associated with the function will be deleted. In the
example below, ExecuteLD() will delete CAknInformationNote once it has finished.
CAknInformationNote* note = new(ELeave) CAknInformationNote;
note->ExecuteLD(KNoteMessage);

Underscores
27
 The use of underscores should generally be avoided. When naming functions or
variables, capitalization and joining of the words is recommended. Underscores may be
used in the definitions of resource names (which are always in lower case) and macro
names (which are normally written in upper case).
RESOURCE my_dialog

Type Definitions
Symbian OS provides a number of type definitions that should be used instead of
standard C++ types (such as int, float and char). These definitions are guaranteed to be
compiler-independent and therefore should always be used.

Integers
An integer value is defined by its size and whether it is signed or unsigned. A
signed integer will hold any number between −2n−1 and 2n−1−1 and an unsigned integer
will hold a value between 0 and 2n−1, where n is the number of bits.
A TInt is a signed 32-bit integer that should be used in preference to other defined integers.
The unsigned equivalent is a TUint, where ‘U’ indicates unsigned. Smaller signed integers
can be defined to save resources: TInt8, TInt16 and TInt32 are signed 8-, 16- and 32-bit
integers, respectively. Unsigned 8-, 16- and 32-bit integers are named appropriately:
TUint8, TUint16 and TUint32. A larger 64-bit signed integer, TInt64, is also available but
there is no TUint64. All the integer types are defined in e32def.h apart from TInt64, which
is defined in e32std.h.

Floating-point numbers
The use of floating-point numbers should be avoided where possible as they are not
natively supported. An application is much slower when it uses floating-point numbers on
a mobile phone. However, a number of floating-point types are defined in e32def.h:
• TReal: 64-bit floating-point number providing double precision
• TReal32: single-precision floating-point number
• TReal64: double-precision floating-point number (the same as
TReal).

Characters
TText is an independent general unsigned character which can be used to store
narrow or wide characters. Non-Unicode builds map TText to TText8 (narrow characters)
whereas Unicode builds map to TText16 (wide characters). All versions of Symbian OS are
now Unicode builds.
TChar holds a character value stored as a 32-bit unsigned integer. More frequently, and for
general use, TText is used in preference to TChar.

Boolean values
TBool defines a Boolean value where ETrue means logical truth (1) and EFalse
means logical falsity (0). Comparisons with ETrue should be avoided, because any non-
zero value evaluates to true but ETrue is only ever 1.

Classes
Class names are defined by a prefix followed by a useful name for the class and
then by a suffix, if it is required. We have already discussed the suffixes and a number of

28
prefixes, however classes have their own prefixes, C, T, R and M, that denote the nature of
the class.

C classes
A C class derives from CBase or any class already derived from CBase. The ‘C’
indicates that the class is constructed on the heap and will need a ‘cleanup’. The class
overloads the new operator to initialize the object data to zero, thus initialization of
member data is not necessarily required. CBase also includes a virtual destructor to allow
the safe deletion of objects through a base-class pointer. The class should be accessed by a
pointer owned by another object, a local pointer variable or by reference.

T classes
A T class does not use dynamic data (heap-allocated memory). As no cleanup is
required, there is no need for a destructor. All data is contained internally or refers to
external data that is ‘used’ rather than ‘owned’. T class objects are returned from methods
by value and are passed by value or reference.

R classes
A resource class, or R class, owns a resource. An R class will typically have a
constructor to set its resource handle to null. The object must be associated with a resource
via methods such as Open(), Create() or Initialize(). There should also be a corresponding
Close() or Reset() method to free resources.

M classes
A mixin class is an abstract interface often used to define callback interfaces or
observer classes. This is the only type of class in Symbian OS that allows multiple
inheritance. Mixin classes will be discussed further in Chapter 4.

Structs
Structs are rarely seen in Symbian OS as the T class should be used in preference.
The structure has no member functions and can be declared as:
typedef struct linked_list_node
{
UInt16 top;
UInt16 left;
UInt16 bottom;
UInt16 right;
} NPRect;

Static classes
Static classes have no prefix letter. The class contains only static functions that
cannot be instantiated into an object. An example is the User class which contains a
number of functions related to the component APIs.

5.2 Tool Chains

For developing Symbian OS software, the use of Symbian’s standard tool chain is
essential. In theory, one could develop perfectly satisfactory code with nothing more than a
text editor and a Software Development Kit (SDK). In reality, the situation is more

29
complex and a rather richer set of tools is required. In order to quickly produce effective
code, an Integrated Development Environment (IDE) is critical. Depending on the
particular IDE and the target platform chosen, the IDE will perform simple functions such
as color-coding the source code as it is entered, grouping together files, compiling code
and interpreting error messages from the compiler. The more advanced IDEs provide
debugging tools on the emulator or the target device. An IDE may also provide access to
additional tools, for example project wizards that aid in the creation of new projects. In
this section, we shall consider a tool chain which provides an adequate set of tools to
develop S60 C++ applications. This list is by no means comprehensive and is subject to
change as new tools emerge and old ones become redundant.

Software Development Kits

The SDK provides the basic Application Programming Interface (API) functions
for use in Symbian OS programs, as well as the compilation tools needed to compile
software for mobile phones and tools to package up files into the required formats for
transfer to the phone. The S60 SDKs can be downloaded from www.forum.nokia.com.
When choosing an SDK to use, you need to know which version of Symbian OS and
which edition of S60 you wish to target, and which feature packs are required for your
application. Feature packs are additional libraries that are added to support new
functionality as it appears on phones, for example, 3D libraries supporting OpenGL ES
were introduced in 2nd
Edition, Feature Pack 2.
For example, if you are creating a basic application that uses only simple graphic
elements, then you will need to download, install and compile with the SDK for S60 1st
Edition, Feature Pack 1. Your application will then support the widest range of devices up
to (but not including) S60 3rd Edition. If you want to develop an application that uses the
camera, then you will need to install the 2nd Edition SDK, as the camera APIs changed in
this version (if you wish to support older mobile phones, then you will need to develop two
versions of your application). If you wish to use 3D features, then you will need S60 2nd
Edition, Feature Pack 2. Your choice of SDK determines the size of the target market for
your application. When selecting a version of Symbian OS and S60 to target for your
application, you should be aware that the application structure changes fundamentally
between S60 2nd Edition and S60 3rd Edition (Symbian OS v9). You will need to develop
separate versions of an application if you wish to support phones that use S60 3rd Edition
and also phones that use earlier versions of S60.
To add further complexity, you may also require different SDKs for each IDE that
you use. A minimal set of SDKs would be 1st Edition Feature Pack 1, 2nd Edition Feature
Pack 2, and 3rd Edition (although it is advisable to install all available SDKs for your
preferred IDE).

Integrated Development Environments

There are three IDEs available to Symbian OS C++ developers:
• Carbide.C++, based on the open source IDE called Eclipse
• Microsoft Visual Studio, the IDE of choice for most Windows programmers
• CodeWarrior, formerly the IDE of choice for Palm programmers and
for PlayStation development and which is now being deprecated. Carbide.C++ is an IDE
available from Nokia. The Express version is available for free and provides the necessary
functionality to build and compile applications. The Developer version has additional tools
for on device debugging and graphical tools for Rapid Application Development 30
(RAD), such as drag-and-drop creation of the user interface. The Professional version is
geared towards developing new Symbian OS devices, supporting the use of development
30
hardware. Visual Studio and CodeWarrior are commercial applications, although both are
available at preferential rates to academic institutions for non-commercial application
development. CodeWarrior is available in three flavours: Personal Edition for developing
applications; Professional Edition, which allows development on pre-release hardware;
and the OEM edition, which enables development on custom development boards. The
choice of IDE is not necessarily simple. Initially, Carbide.C++ supported only the
Symbian OS v9 SDKs (for example, S60 3rd Edition and UIQ 3), with support for older
SDKs being introduced later. Developers may still need CodeWarrior or Visual Studio for
developing applications on older SDKs (having said this, the main market for applications
is increasingly Symbian OS v9 and later). Of the two, CodeWarrior is the better
environment for Symbian OS development, although Visual Studio has a better application
wizard. So, at least for now, it may be appropriate to have all three IDEs (and a selection
of SDKs supporting each of the IDEs). For beginners, however, Carbide.C++ Express is
obviously the cheapest solution.

Utilities
In addition to the core tool chain of IDE and SDK, a number of other utilities are
useful. These utilities are necessary for basic image manipulation, quality assurance, or
prototyping. This list is by no means exhaustive and the choice of tools is very much a
matter of personal preference and the requirements of the particular applications being
developed.

Leavescan
Leavescan is a tool developed by Symbian. It checks that functions that may leave
are correctly named, with the letter ‘L’ appended to the function name. Whilst applications
will run and compile with incorrectly named functions, this provides a useful signifier that
the potential leave may not have been handled safely, leading to potential memory leaks in
the application.

Automated Test Tool

A number of tools are available for testing applications prior to submission for the
Symbian Signed test process. The most useful of these is the Automated Test Tool,
developed by SysOpen Digia. At the time of writing, a beta version was available for
download from the Symbian Signed website (www.symbiansigned.com). The Automated
Test Tool takes your application through a series of tests to check for compliance against
the Symbian Signed test criteria, such as low-memory start-up, unexpected reboot and
more.

Vector-drawing and image-editing packages

Developers will inevitably need to create, modify, convert and manipulate images
for use in their applications. Such packages come in two flavours: vector-drawing
packages, which create images from primitive shapes and objects, and image-editing
packages, which manipulate images at a pixel level. The choice of package is a matter of
personal taste and a matter of much debate amongst the authors of this book. We
recommend the following three vector-drawing packages: Adobe Illustrator, Macromedia
Freehand and CorelDRAW. As ever when dealing with software packages, nothing stands
still; at the time of writing, Adobe and Macromedia are in the process of merging, casting
some doubt on the future of Freehand. There are also three image-editing packages to
consider: Adobe
Photoshop, Corel Photopaint and Corel Paint Shop Pro.

31
Rapid Prototyping
It is often useful to be able to develop a prototype application quickly in a scripting
language before developing a full version of the application in C++. There are two
scripting languages which provide useful features and functionality for rapid prototyping:
Macromedia Flash 8 and Python.

Flash 8
Flash 8 provides a graphical approach to application development and targets the
Flash Lite environment which is increasingly available on mobile phones. The Flash Lite
currently supports a limited set of ActionScript commands but it can still provide a
powerful framework for application development and prototyping. In fact, it is quite easy
to develop sophisticated games and applications in Flash Lite. Flash Lite 2, which will be
available from 2006, will support more advanced ActionScript features such as XML
objects, turning it into a far more serious proposition for Symbian OS application
development. HTTP access is straightforward but as yet there are no plans for Bluetooth
support.

Python
Python is an open-source scripting language, popular on the web, which has been
ported onto Symbian OS. Python is somewhat limited graphically when compared to Flash
Lite but it does provide greater underlying functionality in its communications capabilities.
For developing Bluetooth applications, Python is by far the easiest of all the available
languages.

Chapter 6

Just Add Phone

6.1 Introduction

Mobile phones are uniquely complex devices: more complex than PDAs; more
complex by far than PCs. This case study looks back to the critical early points in the
evolution of Symbian OS into a fit-for-phones operating system. It looks at why phones
are different, what particular challenges they pose and the impact of those challenges in
shaping Symbian OS.
It is often said that Symbian OS was ‘built for mobile phones’ and the claim, while
true, does not remind engineers of the roots of the operating system. Its predecessor,
EPOC, was conceived and implemented first as a mobile operating system for PDAs, even
though, by the time it first shipped, mobile telephony had been identified as a critical

32
market in which the operating system would win business and work was well in hand –
driven by phone licensee collaborations – to put Symbian OS inside phone handsets.
As this case study shows, the shift in emphasis from PDAs to phones involved some very
real challenges. Understanding what those challenges were helps us to build a deeper
understanding of what Symbian OS is today.

6.2 Anatomy of a Phone

‘Mobile phones’, says David Wood, ‘are just irreducibly complex.’ He should
know. As one of the five founding directors when Symbian was created,1 Wood took
responsibility for the Technical Consulting arm of the company – with a mission to
support licensees, old and new, to create ‘great phones’ on Symbian OS. Technical
Consulting has always been at the forefront of the process of securing licensees’ use of the
system and following through to shipped products.

Compared with PCs or even PDAs, phones pack an astonishing number of different
technologies into a tiny package. The things which in a PC are peripheral become integral
in any pocket device; screen, keyboard, speakers, microphone and soundcard are packed in
with CPU core and memory and permanent storage. But phones, of course, go further.
There is the phone radio hardware itself and possibly multiple other radio interfaces, such
as Bluetooth, and their associated software stacks, full networking, and a complete
multimedia system. Megapixel cameras with true optics have arrived (Zeiss lenses, for
example, and optical zoom) as, of course, has stereo sound with real-time compression and
decompression for stereo playback. Integrated high-definition TV is the most recent
arrival, hard on the heels of Wi-Fi, with Wi-Max waiting in the wings. Add in the power-
management technologies needed to deliver long battery life while fueling this impressive
array of technologies with ever-increasing processor speeds yet also avoiding the device
becoming (literally) hot in the user’s pocket; the PC, in comparison, starts to look
trivial.

Looking back, the hardware architecture of the early devices for which Symbian
OS was originally designed now looks remarkably simple too. A hardware schematic of
the Psion Series 52 shows little more than an ARM core connected via a data bus to ROM,
DRAM, and removable media-card memory, with direct connections to the remaining
hardware: an audio codec for microphone input and speaker output, RS- 232 and infrared
UARTs, LCD screen and digitizer overlay (via an analogue to- digital converter) and
keyboard (via parallel I/O pins). A power supply unit drives the system from two standard
AA batteries and a wristwatch style flat cell backup battery. Interestingly, the Series 5
hardware was itself more complex than that of some competitors, for example, Apple’s
Newton or Motorola’s Magic Cap devices [Wolf 2001, p. 548].
15.3 The Phone Operating System
A phone operating system must manage complexity at a number of levels.
• It must manage the sheer hardware complexity of a converged device but, more
specifically, it must manage a double platform: a highly specialized, data-centric
(including voice data3) radio hardware device on the one hand and a multimedia-ready,
networked, application-centric device on the other.
• It must cope with the sheer software complexity and, more specifically, a double
software stack: specialized communications and data-centric protocol stacks and real-time
channels on the one hand and a GUIbased, friendly, application-rich consumer system on
the other.

33
• It must deliver the performance expectations of a general consumer market (toasters ‘just
work’ and so phones had better ‘just work’: when they stop working, they are thrown
away), quite different from the expectations of users of desktop computers, PDAs or
gadgets.
• It must conform to the usability expectations of a general consumer market (no one
expects to read the manual for a toaster; why should they read the manual for a phone?),
again quite different from specialist users.
• It must stay fit and keep up to date with rapidly evolving technologies, a rapidly evolving
network-services (operator-services) infrastructure and evolving open standards (often
multiple, competing global standards).
Depending on who you talk to, ‘phonification’ means different things but, in principle, it
means all of the above. ‘Being a phone’ is different from being merely a small, pocketable,
mobile device.

Architectural Impacts
The impacts on the system architecture of the move from PDAs to phones are
worth examining.
• The most obvious impacts are on the Kernel Services and Hardware Interface layer. The
Kernel itself must either support the real-time needs of the baseband or it must be made
amenable to an alternative solution. It must also support licensee ASIC or ASSP custom
chip packages, which may mean supporting alternative memory models and memory-
hardware architectures. It must support phone-specific device peripherals, including
screens and keypads and possibly dedicated hardware such as a phone flip.
• In the Base Services layer, the File Server must support multiple file system architectures
and media types (both NOR and NAND flash, for example, and probably also hard drives),
providing specialist services such as wear-leveling (for NAND) and demand paging.
• In the OS Services layer, the Comms Services architecture must support telephony
protocols and integrate with networking support; graphics and multimedia services must
support phone use cases (such as camera-phones and music-player-phones); connectivity
requirements are probably also different between PDAs and phones.
• The Application Services layer is significantly affected too, with the different phone use
cases for applications and new services requiring support.
• Finally, the UI Framework must provide support for a dedicated phone user interface.
There are almost certainly other system-wide impacts:
• system performance characteristics are likely to be quite different for a phone and a PDA
• greater modularity in the system may be necessary to enable the different product cycle
for phones (a more platformized model, in other words) and a full product matrix
• adaptation almost certainly becomes more complex, with a much greater range of
technologies needing integration (web browsers, viewers for content such as Flash and
PDF, and Office file viewers, font technologies, etc.) and plumbing to close hardware
support.
• service assumptions turn into architecture headaches; phone operators are simply not
used to open network models (third-party software availability, for example) and a system-
wide security model becomes a requirement.

Supporting the Baseband

The mobile phone ‘baseband’ is the software signaling stack that accepts a data
stream (e.g., the output from a digital signal processor which has been fed voice input from
a microphone) at the top layer and emits a stream of encoded data frames at the bottom
layer onto a data channel to radio–air-interface hardware and vice versa; accepting
encoded data

34
frames at the bottom and emitting a data stream at the top (if it is voice data, it is fed to a
DAC for conversion to audio output).

The signaling stack sits on a software layer of some kind, traditionally a real-time
operating system (RTOS), which in turn drives the baseband processor, typically a
general-purpose CPU such as an ARM or Strong ARM dedicated to the RTOS and the
stack that it hosts. The radio hardware is likely to vary between phone makers, from
custom silicon to standard bought-in parts, and the data channel might be old-fashioned
serial or,more recently, USB.

Non-voice data on 2G and 2.5G and all data on 3G is packetized (into TCP/IP
packets). The DSP/DAC steps are omitted but otherwise the packets follow the same path
through the signaling stack and are tunnelled as GSM/2.5G/3G frames.
The basic hardware design choices for a Symbian phone revolve around whether to use
one processor or two and, if two, how to connect them. The two-CPU option treats the
baseband, or phone side, as a completely separate hardware subsystem and interfaces it to
an application subsystem with its own application processor (an ARM or StrongARM
CPU, for example), running Symbian OS and applications. The single- CPU option creates
a single hardware system, and shares it between an RTOS and Symbian OS or (enabled by
the Symbian real-time EKA2 kernel) uses Symbian OS exclusively to host both the
baseband and the application stack on a single CPU.

While to some extent how licensees architect their phones around Symbian OS and
the design choices they make are opaque (and often jealously guarded), the consequences
clearly impact the operating system design and the assumptions it makes about the
environment in which it runs.
The hardware design options are as shown in Figure 15.1. A: Two processors connected by
a fast serial bus: CPU A is the baseband processor and hosts an RTOS, which in turn hosts
the baseband stack. CPU B is the application processor and hosts Symbian OS, on top
of which is layered a bespoke or licensed user interface that hosts applications.
B: A custom package with two CPUs and shared memory at the register level. CPU A is
the baseband processor and hosts an RTOS, which in turn hosts the baseband stack. CPU B
is the application processor and hosts Symbian OS, on top of which is layered a bespoke or
licensed user interface that hosts applications. C: A single processor hosts both the RTOS
and Symbian OS. RTOS runs the baseband stack and Symbian OS runs the user-side
processes; the two operating systems have a mutual agreement to share the CPU, RAM,
device drivers, and other system resources. D: A single processor hosts Symbian OS with
real-time kernel EKA2.

Symbian OS, abstracted by a custom ‘personality layer’, runs the baseband stack,
device drivers and user-side application processes. But telephony is not just a matter of
getting raw data to the baseband. The baseband needs to be under application control,
which means that there must be application interfaces to the phone side from the
application side. On a typical Symbian phone, the phone application is simple and can
therefore be relatively hard-wired to the phone side, but phone books, call logs, messaging
(SMS, MMS, email, and so on) require access to phone protocols and data services (such
as networking and Web browsing) need to control the phone side in a modem-like fashion.
While the telephony application that the user sees is relatively simple, the underlying
engine which sits beneath it is quite complex. It needs to handle a number of cases such as
ensuring that emergency calls are always possible, even in low-memory conditions, and it
must interoperate with hardware accessories such as headsets, as well as specific call-

35
handling and over-the-air (OTA) settings protocols (e.g., call-handling and SIM toolkit
functions).

Supporting New Hardware

The real-time kernel (EKA2) is still valuable even in designs that retain a separate,
edicated RTOS or partner operating system. Whether or not it hosts the baseband, EKA2
has advantages on the application side too.

Supporting Services
Networks are driven by services and services are supported by phones. As voice
services become increasingly commoditized, existing non voice services such as
messaging, browsing and new services (alternative network access through Wi-Fi,
broadcast TV, presence and navigation) become more important.

Supporting Features
There is no good definition of what features make a smartphone into a smartphone,
a mid-range phone into a mid-range phone or a low-end phone into a low-end phone.4
Typically the measure is Bill of Materials (BOM) cost; as manufacturing techniques
improve and Moore’s law continues to hold, BOM costs fall (See Figure 15.2). As
volumes continue
to push inexorably upwards, driving marginal costs down, so the cost of a given feature set
drops inexorably.
Meanwhile feature pressure (the demand to pack more and more functionality into
phones) exerts a degree of counter pressure, driving ROM/RAM peripheral hardware
requirements up. (For example, the camera-phone has evolved into the multi-camera-
phone; still pictures have become video sequences; the ringtone phone has become a music
playing phone and has subsequently evolved into a direct competitor to MP3 players.) It’s
not clear whether that means that the BOM costs are not falling as fast as they might and
therefore the line between high-end and mid-range is not falling as quickly as it might or
whether it just means that we are all migrating to the high end.

Supporting the User Model

Phones are branded goods, fashion items, consumer appliances (see [Lindholm et
al. 2003, Introduction]), and a host of other unlikely things that drive user expectations for
how they behave, how easy they are to use and what they do. Phones have hard keys and
soft keys; some have keyboards, some have pens, some accept voice commands; all may
raise issues about handedness and screen orientation. Users expect ‘natural’ interaction
models, associate interaction styles with brands, and fuel both performance pressure and
feature pressure (where the performance and features of mid-range phones are increased to
match high-end phones).

Supporting the Market

Phone manufacturers typically want rapid product cycles as part of their drive
towards increased volume of sales. Feature pressure (again with a helping hand from
Moore’s law and the economics of volume) drives a rapid technology-proliferation cycle.
The pace of the drive towards increased volume of sales continually quickens and the
cycle times for technology moving from research labs to products speed up. The result is a
demand for continuously greater agility from suppliers, including the operating system
supplier, as well as continuously greater predictability, fuelled by the relatively long
product lead time coupled with a short product cycle and lifetimes.

36
There is additional pressure on a system when it becomes a platform (being a supplier is
easier: there is only one customer to please).

6.3 Telephony

Telephony services in Symbian OS are organized around the ETel server and
framework, which is at the heart of the application-side interaction with the phone
baseband or, as it was originally conceived, any modem at all.
As Andy Cloke remembers it, development work on ETel started even before the Series 5
had shipped. See Figure 15.5.
Andy Cloke:
We started doing ETel when Roger Nolan8 was running the Comms group. I don’t
think it was entirely clear that we were going to do the next Nokia Communicator. At
least, it wasn’t clear to me at that point. There was still quite a focus on PDAs. Certainly,
the thought that we wouldn’t be doing PDAs hadn’t become clear. So it could have been
PDAs in a variety of forms: the modem could have been built in; it could have been a plug
on; it could have been wirelessly linked. It was quite different from the way we are today.
The device that came to market was the Nokia 9210 Communicator, the direct descendant
of the Nokia 9000. But at least two other phone based projects ran more or less
concurrently with the Communicator project, one for a Philips phone ‘companion’, which
did not come to market, and one for the Ericsson R380. (See Chapter 2 for more about the
background to these early projects.)

The starting point for the design was not really a converged device at all. While
assumptions had moved beyond being simply an operating system for the Psion Series 5,
the thinking was closer to a ‘super PDA’.
Andy Cloke:
We were thinking about the possibility that you might have multiple modems that
may appear and disappear. So the concept of PCMCIA cards that could be inserted and
removed dynamically was still very prevalent. So that was the motivation for having
multiple phones: you might have an internal modem and a PCMCIA modem and another
one accessible over Bluetooth, for example.
ETel first appeared in the codeline at version 001 in July 1997 and by the end of
the year was providing basic ‘Hayes’ control of a GSM phone (as modem) over a serial
connection. As it happens, the test phone was none other than a Nokia 9000. If there had
been uncertainty about whether the Nokia Communicator project was the target, it was
resolved by the end of the year and ETel was explicitly delivering into the Nokia
Communicator project.
Andy Cloke:
We established the ETel API first and then, in parallel as I remember, we started
developing an AT-command-based TSY, and we didn’t quite realize how big a job that
was. And in parallel with doing that, we started talking to Nokia, to the Communicator
development team. I remember going to talk to them and we thought we were going to get
completely toasted when we presented our ideas because we were fairly new to it, and
clearly these people knew everything about telephony and we didn’t. I can remember
coming back on the plane after the meeting in Tampere and thinking ‘Wow!’ Because we
had expected to get roasted alive and that hadn’t happened, so we just thought, ‘How great
we are, we’ve managed to get it right first time!’ It wasn’t until later that we realized how
easy they’d been on us and how much we had to learn. In the end, we got strong design
steers from Nokia and Ericsson. In 1998, the first GSM extensions began to appear; the fax
server was integrated from a standalone component into the ETel framework (as a

37
framework extension). By the end of 1998, the code had reached a degree of stability as an
alpha-release component of what was by then the ‘EPOC Release 5_ platform, aimed at
the new Psion Series 5MX, a souped up palmtop intended to have full phone and
networking capability (in two-box mode).
In January 1999, ETel branched for the Ericsson R380 and by May it had become a
component of the ER5u baseline, the so-called ‘wide’ or Unicode build of the operating
system, and part of the main codeline. By then, there were multiple licensees taking the
component.
Andy Cloke:
As you can imagine with companies working together but competing in the same
market, there were quite a few political considerations; the opportunities for getting the
different parties into a room together were fairly small, and the amount that they would
discuss in the room together was also fairly small. You have to understand that we hadn’t
shipped a phone at this point, the Ericsson R380 hadn’t shipped and the Nokia
Communicator (9210) hadn’t shipped either. So it was difficult for us. In terms of the TSY
development, both Ericsson and Nokia were saying, ‘Don’t worry about that, we’ll do the
TSY’. We all thought that this was a good thing, little knowing that with us creating the
API and them creating the TSY that plugs into the bottom of it, we were creating an
integration nightmare. If we’d done the TSY design more in parallel it would have been
better. We would have avoided some pain later.

ETel Design Goals and Architecture

ETel’s design drivers are clear enough. It was designed to support multiple clients
and multiple dynamically loaded TSY modules with the goal of enabling a PDA to access
either a built-in or external modem – indeed, multiple modems at any time – typically to
enable data calls (for example, SMS messaging and fax) and Internet access (for example,
email and Web browsing). From the beginning, there were also some clever phonespecific
extras, designed for the case in which the ‘modem’ being accessed was in fact a GSM
mobile phone. For example, SIM toolkit functions llowed synchronization of on-phone
SIM-stored and memory-stored phonebook entries with the PDA contacts application.

The design took the existing serial communications architecture as its starting point
(Figure 15.6). The design goal was to provide an abstract model for controlling phones
from Symbian OS. Phone hardware was understood in classical Symbian terms as a
resource to be shared by multiple applications with serialized access; in other words, the
server model applied. Analogously with CSY serial communications modules, TSY
telephony modules were defined as the abstractions for actual hardware and a similar
framework architecture to the serial communications system was adopted. Depending on
what hardware was available to the system (and what application was requested) the TSY
would either interface directly to the hardware (the baseband–built-in modem case) or
access the hardware through the serial communications system (for example, a TSY
sending AT commands to a true Hayes modem or to a GSM phone presenting an AT
interface, over infrared or a cable serial connection).

The ETel architecture closely followed the tried and tested architecture of the
Comms services. A classic Symbian OS client–server interface shares access to telephony
services and hardware between multiple clients. A framework architecture provides for a
core API which is extensible in two directions by plug-ins; horizontally, ETel extensions
add richer functionality to the basic core set with extensions for fax, packet data for GPRS
and 3G, the Multimode extensions for CDMA2000, and SIM toolkit extensions; vertically,
plug-in TSY adapter modules, modelled on the Comms CSY modules, that are loaded on
demand interface the abstracted ETel APIs to the actual hardware available.
38
 ETel therefore interacted closely with the serial communications system and, in
fact, did so through the generic mechanism of the Socket Server (requesting a serial socket
connection, for example). Looked at from the other direction, ETel equally became a
socket provider, providing telephony sockets to serial or networking components.
The communications design analogy was an obvious starting point, especially because the
design was proven and had shown itself to be both extensible and flexible. In effect, the
whole communications architecture was elaborated horizontally so that the telephony
system was created as a peer of the networking and serial communications systems. The
serial system was ‘first among equals’, primarily because, in the use cases that drove the
design, serial communications via modem always provided the physical access to the
network (phone or Ethernet). With hindsight, however, the PDA or two-box use case
dominated over the built-in phone use case. ETel started with a design goal which it met
admirably, but which was rapidly overtaken by the change in context. Symbian OS in a
phone has different telephony requirements to Symbian OS in a modem-connected PDA.
Andy Cloke:
Our early design assumptions were not really true any more; modem wasn’t the
primary use case. And certainly the primary use case that we’re dealing with now is a
phone that has a single baseband, and consequently ETel has morphed into a baseband
abstraction.
The more complex question is whether ETel’s design supports the needs of an
abstracted baseband or simply provides an API for application access to the baseband. In
design terms, ETel is a classically good example of object-oriented abstraction. Its three
key concepts are phones, lines and calls. Clients request an RPhone session, from within
which an RLine subsession can be opened and a further RCall subsession can be created.
The TSY instantiates corresponding derived classes from the framework:
CPhoneBase, CLineBase and CCallBase. In turn, these objects create AT commands,
instantiated as objects derived from CATBase, which are then sequenced through the
TSY’s command sequencer, which controls a communications port requested through a
serial communications session owned by the TSY. The communications port in question
provides a direct (docking-style), infrared or serial-cable connection to an actual phone,
which responds to the AT commands.
Andy Cloke:
I wish in hindsight I had spent more time looking at the ISDN specs, standard
wireline phone specs, and the GSM standards. I think Phone and Call are still quite valid
abstractions, but I think Line was a bit of a waste of our time. It was there originally
because, on a single GSM phone in the GSM specs, you can have a different telephone
number for voice calls, data calls and fax calls. Fax, indeed, turned out to be troublesome.
Andy Cloke:
Fax over GSM is tricky because of timing issues. You have to spoof packets on the
base-station side to stop the fax machine timing out because the transmission delays are
too long over GSM. Well, and then it all gets more complex because of the alternate
numbers. But anyway, I think I would have dropped the Line abstraction.
Another, subtle, design assumption that proved a problem comes back again to
assumptions about the nature of the modem that is providing access to the phone network.
Andy Cloke:
That’s something else that ETel was predicated on, that the modem would become
completely commoditized, and while it is slowly moving in that direction, with the advent
of 3G and all the different services on there and all the different ways that packet data
works and some of the services work, that is not true yet. And coming you have HSDPA
and HSUPA – High-Speed Downlink and High-Speed Uplink Packet Access – which will
be the next service that will be required. It’s already being referred to as 3.5G. So these
39
sorts of forces stop the modem software – I’m using these words, modem and baseband,
interchangeably – they stop that software becoming a commodity because it just moves on
and on, it’s moving so fast. How many non-proprietary 3G signaling stacks are there out
there that have any kind of market credibility? I think the answer is as small as three or
four, ones where you’re going to buy off the shelf, so it’s certainly not yet a commodity
item.

The Problem With ETel

Charles Davies:
We did a telephony API, whereas what we needed was a distributed computing
solution with a baseband. Or to put it another way, it was not so much a telephony API we
needed as a subsystem that does more than telephony, but of which telephony is one
application.
The more general case of supporting data communications, including abstracting the
baseband, is the direction in which Charles Davies is heading. With hindsight, the
requirement was not to provide abstract control for a phone, because outside the two-box
context that is not what devices require. What devices really require are high speed data
connections between the application side and the phone baseband. As Davies puts it,
something much more like what he calls ‘a distributed computing solution with a
baseband.’

Charles Davies:
What that really means is that you supply a reliable by-value RPC mechanism
between the two sides which is independent of the application you are doing it from, and
then telephony would be one of the applications. On the question of the importance of
telephony, Charles Davies is even more radical.
Charles Davies:
You can debate how important a telephony API really is anyway. Many other APIs
are much more important from the point of view of the operating system, in the sense that
connections to packet data are more important, because telephony is only needed by one
application, although it certainly is an important application. But it’s all the rest of it that
allows a phone to be built.
Andy Cloke takes a more sanguine line.
Andy Cloke:
With hindsight we would have preferred to establish a narrower API upon which
Symbian would have built its services, in other words, data calls, establishment of PDP
contexts and secondary contexts, transmission of SMSs, reception of SMSs, these sorts of
things. It’s very important that we have an API which works well there, a downward,
hardware-adaptation-interface-style API.

40
Chapter 7

Refrences

 The Symbian OS Architecure Source Book by Ben Morris

 S60 A Programming Tutorial Guide by Paul Coulton & Edward Rubert

 www.techrepublic.com

 www.developer.symbian.org

41