Contents

Chapter Title Page NoList 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 AbbreviationsADT: 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 FiguresFigure 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 TablesTable 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

Model CPUCapacity

RAM OS UI Size Weight Resolution Keyboard Camera Other

iPhone 4[4]

Apple A4 800 MHz

16 or 32 GB

512 MB

iOS 4.0

62.8 cc 115.2x58.6x9.3mm

137 g 3.5" 640x960 SoftQWERTY5.0 MP AFwith LED flash andgeotagging, 1280x720 video at 30 fps

3-axis accelerometer, 3-axis gyroscope, aGPS, multi-touch, Proximity and ambient light sensors, digital compass, WiFi b/g/n, Bluetooth 2.1+EDR

HTC Touch HD(aka HTC Blackstone)

528 MHz Qualcomm MSM7201A

512 MB

288 MBWindows Mobile 6.1

HTC TouchFlo3D

87 cc 146 g 3.8" 480x800 SoftQWERTY4.92 MP AF, 0.31 MP

Nokia 5800 XpressMusic

434 MHz Freescale MXC300-30

256 MB

128 MB

Symbian OS 9.4 Series 60 5th Edition

111 x 51.7 x 15.5 mm83 cc

109g 3.2" 360x640 Touchscreen3.15 MP, Auto Focus and Dual LED Flash

Sony Ericsson XPERIA X1 (aka HTC Venus)[37][38]

528 MHz ARM1136EJ-S512 MB

384 MBWindows Mobile 6.1

99cc 158g 3" 800x480Full slide-outQWERTY

3.15mp AF

Samsung SGH-i8000 Omnia II

800 MHz16 GB

256 MBWindows Mobile 6.5

? 117 g3.7" 800x480AMOLED

SoftQWERTY

5mp Auto Focus, face detection,smile detection, geo tagging, Dual LED Flash

12

Chapter 2

Introduction To Symbian OS2.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 idiomsused 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 isintended to provide fully-featured modern mobile phones with large colorscreens, which are most often referred to as smartphones. S60 is most oftenassociated with Nokia, which is by far the largest manufacturer of these

13

mobile phones, although S60 is also licensed to other major mobile-phonemanufacturers 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 applicationsto 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 foldingcase 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. Manyof 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 ofapplications• always-on systems, capable of running forever: robust managementand 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 exhibitsas 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 shapeof 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.6SIBO 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 thoseproblems 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 SystemIn 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 productneed 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 aproduct 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 ThreatsThere 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 Model4.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 wantthe 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 thecertificate 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 wewill 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.infPRJ_MMPFILEShelloworld.mmpThe first line’s label, PRJ_MMPFILES, indicates that a list of the .mmpfiles contained in the project will follow, and sure enough, the secondline lists this project’s single .mmp file.helloworld.mmpTARGET helloworld.exeTARGETTYPE exeSOURCEPATH ..\srcUID 0SOURCE helloworld.cppUSERINCLUDE ..\incSYSTEMINCLUDE \epoc32\includeLIBRARY 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 functionLOCAL_C void MainL(){_LIT(KHelloWorldString, "Hello World\n");gConsole->Printf(KHelloWorldString);}// Console HarnessLOCAL_C void ConsoleMainL(){_LIT(KConsoleTitle,"Hello World!");

23

gConsole = Console::NewL(KConsoleTitle, TSize(KConsFullScreen,KConsFullScreen));MainL();}// EPOC's main entry pointGLDEF_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 ApplicationThe 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 fileand 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) theprevious 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 abldmakefile.The simplest method for building the project is:abld build

This will build the project for all possible build variants. However, itis possible to build for a specific platform. The following command willbuild 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 userinput 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 recommendedway 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 AppUiis 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 bysupplying 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 buildingthe 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.

CapitalizationThe 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-caseletter:TMyClass myObject;

PrefixesNon-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 32An 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);

SuffixesSingle-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 DefinitionsSymbian 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.

IntegersAn 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-bitintegers, 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 numbersThe 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 asTReal).

CharactersTText 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 valuesTBool 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.

ClassesClass 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 classesA 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 classesA 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 classesA 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 classesA 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.

StructsStructs 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 classesStatic 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. Inthis 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 KitsThe 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 2ndEdition, 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 EnvironmentsThere 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 andfor 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.

UtilitiesIn 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.

LeavescanLeavescan 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 inthe application.

Automated Test ToolA 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 packagesDevelopers 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: AdobePhotoshop, Corel Photopaint and Corel Paint Shop Pro.

31

Rapid PrototypingIt 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 8Flash 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 beavailable 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.

PythonPython 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 anddecompression 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 looktrivial.

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 remaininghardware: 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’sNewton or Motorola’s Magic Cap devices [Wolf 2001, p. 548].15.3 The Phone Operating SystemA 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 ImpactsThe 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 BasebandThe 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 StrongARMCPU, 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 topof 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 orlicensed 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 HardwareThe 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 ServicesNetworks 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 FeaturesThere 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 continueto 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 ModelPhones 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 MarketPhone 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 thebackground 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 ArchitectureETel’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 phonespecificextras, 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 questionprovides 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 ETelCharles 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 dataconnections 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