Symbian Os Introduction

An Introduction to Symbian O.S. Presented By: Deepak Rathi PGDWTA-IV-2008 [C-DAC NOIDA]

Outline
Symbian OS overview
Symbian OS structure
Setting up a development environment
Creating a “Hello World” example
Basic Symbian OS and Symbian C++ concepts

Outline
Symbian OS overview
Definition
History
Market Share
Device Classes
Symbian OS Characteristics

Definition
Symbian OS(v9.5) is the advanced, open operating system designed for the specific requirements of advanced 2.5G and 3G mobile phones. Symbian OS combines the power of an integrated applications environment with mobile telephony, bringing advanced data services to the smartphones .
Symbian OS (in general) is a multitasking operating system with features that include a file system, a graphical user interface framework, multimedia support, a TCP/IP stack and libraries for all the communication features found on smartphones .

History
1997: Psion’s EPOC OS Launched(2 MB memory)
1998: Symbian consortium and Symbian OS
independent of Psion
Ericsson, Nokia, Motorola, Psion (founders)
Panasonic, Sony Ericsson, Siemens, Samsung (shareholders)
2000: First Symbian OS phone
Ericsson R380

Market Share
Symbian OS runs on ~75% of all smartphones
Nokia expects the smartphone market to exceed 250 million units in 2008
82.8 million cumulative Symbian OS phone shipments since the formation of Symbian (as of Q2 2006).
Symbian C++ gives
Maximum flexibility
Speed
Market share in smartphones

Symbian Device Classes/Platforms
Same Basis, different feel and look due to difference at UI layer :
S 60: Smartphones with numeric keypad, “phone centric”
e.g.: Nokia 6600
S 80: Organizers with full keyboard, “information centric”
e.g. : Nokia 9300
UIQ: smartphones with pen input, “information centric”
e.g.: Sony Ericssion P910

Symbian OS Features
Symbian OS from the developer‘s point of view = {operating system for handheld devices with limited resources
+ user interface framework
+ APIs (C++)
+ tools}
Operating system:
pre-emptive multitasking, multithreading, memory
protection, event-based
special features: conserving memory, reliability, CPU switched off when applications are not dealing with events
Symbian OS from the user‘s view:
consistent user interface, comprehensive set of PIM applications, extensible by 3rd party applications

Outline
Symbian OS overview
Hardware resources
Software components
Processes, threads, and context switching
Kernel and user library
Event handling and active objects
Client-server framework

Hardware resources
CPU: ARM, 32-bit, 36-220 MHz
ROM: contains the OS and all the built-in middleware and applications . Symbian OS v7.0 machines use around 20 MB of ROM. Z: drive.
RAM: system RAM is used for two purposes:
RAM for use by active programs and the system kernel
RAM used as 'disk' space accessed as the c: drive.
I/O Devices: keypad, pen input, card slot, CCD camera, serial port for RS232.
Communication: GSM/GPRS/UMTS, infrared, Bluetooth.
Power source: rechargable battery 2000-3000 mWh (600-900 mAh, 3.5 V).
Display: 176x208 pixels, 65536 colors for smartphones.

Memory Organization and Disk Drives
RAM:
runtime memory (stack, heap)
C: System flash, or RAM, disk; full read/write file system
application files, user files
D, E, ...: Compact flash cards, memory sticks; removable read/write media
application files, user files
Z: contain ROM i.e.; read only file system
operating system files

Software components
Kernel:
manage and controls access to hardware resources
hardware-supported privileges, kernel mode
Application:
program with a user interface
runs in user mode in its own process
Server:
program without a user interface
manages resources, provides interface to clients; applications or other servers
Engine:
application part that manipulates data, often separate DLL

Processes, Threads, and Context Switching
Process: fundamental unit of protection
own address space
virtual addresses – MMU  physical addresses
It may contain one or more threads
Thread: fundamental unit of execution
one or more per process
preemptively scheduled by the kernel
The consequent interruption of the running thread by the higher-priority thread is called preemption, giving rise to the term preemptive multitasking in Symbian OS
executes independently of the others, but within the same address space
Context switching: switching b/w one thread to another
expensive between two threads in different processes
typically just one thread per process  active objects

Kernel and User Library... 1
Kernel : The core of OS. It manages memory, loads processes and libraries and schedules threads for execution.
Most fundamental component of Symbian OS E32 & consists of the kernel and user library .
Kernel runs in privileged mode
The user library, euser.lib , is the lowest-level user-mode code

Kernel and User Library... 2
The kernel itself has two major components:
Kernel Executive : runs privileged code on behalf of a user thread & runs in the context of that user thread.
Kernel Server : highest-priority thread in system. It allocates and deallocates kernel-side resources needed by the system and by user programs
User library (euser.lib), basic library for kernel access, perform 3 functions:
functions executing entirely at user-side (e.g. descriptors, arrays)
Function requiring privilege hence cross into kernel executive mode (e.g. time checking)
Functions that require the services of the kernel server: these go through the user library, via the executive, to the server

Event handling and active objects... 1
Symbian OS optimized for efficient event handling using:
Active Objects & Active Schedulers:
non-preemptive event handling within a single thread
well-suited for GUI systems
Active objects responsible for issuing requests to asynchronous service providers and handling those requests on completion. Derives from CActive class.
Active scheduler calls RunL method of active object. Responsible for scheduling events to the active objects in an event-handling program.

Cascade of events which occurs on pressing of a key when using say Symbian OS word application:
The I/O device controlling the keyboard generates an interrupt( press PGDWTA )
ISR/DFC (Delayed Fn Call) , translates this to an event & generates ASCII code corresponding to PGDWTA

The window server then works out for the application that is currently receiving keystrokes and sends the event to the application, in this case Symbian OS Word.
Symbian OS Word then handles the key – by adding text: PGDWTA to the document and then updating the display.
The window server updates the display in response to the application's requests by displaying PGDWTA on the Smartphone's display screen .

Client-server framework

Client-server framework... 2
A server thread is responsible for managing one or more related resources.
One or more client threads may use the server to perform functions that use those resources.
Most critical servers in Symbian OS:
File Server: which handles all files related operations.
Window Server: which handles user inputs and drawings to screen.
Other servers: communications, databases, schedule, contacts, etc.
Key elements of Client-server interface are:
The client interface : each server provides an API to its clients – the client interface, which disguises all the client-server communications
Kernel-supported message passing : implementing a server (along with its client interface), this is the main method by which you pass requests from the client to the server, and handle them.
Kernel-supported inter-thread read/write : server can read from, or write to, a client's address space

Outline
Symbian OS overview
Development tools
Installation issues
Application wizard
Debugging Programs in Emulator

Symbian Series 60 and UIQ Development Tools
Microsoft Visual Studio – C++ IDE (MSVS)
Metrowerks Code Warrior – C++ IDE (alternative)
[Makmake – makefiles for Windows and ARM, project files for MSVS]
Bldmake – generates abld.bat from bld.inf
Abld – Perl tool, creates makefiles, compiles project
Makesis – creates installation file “.sis” from “.pkg” file

Installation directories created
Epoc32 – gcc compiler, emulator, include files, etc.
Examples – SDK examples
Series60Doc – SDK documentation
Series60Ex – Series 60 specific examples
Series60Tools – tools

Using the Application Wizard...1

Using the Application Wizard...2

Using the Application Wizard...3 Application title will appear on the device Each application has a unique identifier

Using the Application Wizard...4 Generated classes: - Application - Document - User interface - Container

Using the Application Wizard...5 Generated directories: - C++ include files - C++ source files - group: Symbian project files - data, aif: resource files - install: installation files

Debugging Programs in the Emulator
Set breakpoints(F9)
Debug (F5)
Breakpoint Inspect variables

Generated Files GUI resources Project definition file Package definition file Source files

Outline
Symbian OS overview
Naming conventions
Basic types
Exception handling
Resource management
Descriptors

Naming Conventions for Class Types...1 Category Examples Description T (“data type”) classes TDesC, TPoint, TFileName T classes don't have a destructor. They act like built-in types. No pointers, no resources C (“cleanup”) classes CConsoleBase, CActive, CBase Any class derived from CBase. C classes are allocated on heap. CBase also includes a virtual destructor, so that by calling delete on a CBase* pointer any C object it points to is properly destroyed.

Naming Conventions for Class Types...2 Category Examples Description R (“resource/remote”) classes RFile, RTimer, RWriteStream, RWindow Client-side handle to an OS resource (file server, message server, etc.) M (“mixin”) classes/interface classes MGraphicsDevice-Map,MGameViewCmd-Handler, MEikMenuObserver An interface consisting of pure virtual functions. A class implementing this interface should derive from it. M classes are the only approved use of multiple inheritance in Symbian OS.

Naming Conventions for Variables and Constants
One character prefix for consistency, readability
i : member (instance) variables i Document
a : method arguments a Index
no prefix : local variables on the stack size
K : constants K Pi
Method names: capitalized S etName

Basic Data Types – Integers, Void, Boolean Boolean Void Signed Integer Unsigned Integer Name Size (bytes) Tint >=4 Tint8 1 Tint16 2 Tint32 4 Tint64 8 Name Size (bytes) TUint >=4 TUint8 1 TUint16 2 TUint32 4 Name Size TBool 4 Name Type TAny Void

Basic Data Types-Floating Point, Characters Floating Point (avoid it) Character Name Size (bytes) TReal 8 TReal32 4 TReal64 8 TRealX 12 Name Size (bytes) TText8 1 TText 2 TText16 2 TChar 4

Error Handling and Cleanup
Error handling is about producing reliable programs, on continuously running resource constrained devices running Symbian OS
Memory leaks must not occur!
Use memory efficiently and safely
Release resources as early as possible
Cope with out-of-memory and other errors and roll back to a consistent state when they occur
The Symbian OS error handling and cleanup framework is good for more than OOM errors. Many operations can fail because of other environment conditions – reading and writing to files, opening files, sending and receiving over communications sessions to name a few.

Exception Handling…1
Exception is an indication of some error or problem during
execution.
The bigger the application, the more probable it may have
problem situations.
Typical problems are e.g. out of memory situations or lack of
some resource, e.g. network not available.
In e.g. Java, exceptions are used in many kinds of erroneous
situations, e.g. overindexing table, divide by zero etc.
In Symbian OS, exceptions are used in “ lack of resource ”
situations.
Symbian OS “exception” is called a leave .

Symbian OS exception mechanism differs from standard C++
Symbian OS does use standard C++ throw-catch mechanism (so it does not matter if you never coded C++ exceptions).
The C++ standardization was in progress while Symbian OS was developed so they created their own mechanism.

Symbian’s own variant of C++ try, catch, throw
C++ throw Symbian User::Leave()
C++ try, catch Symbian TRAP macro
Cleanup stack
clean up heap when exception occurs
Two-phase construction of complex objects
1st phase constructors never leave
2nd phase constructors can

Resource Management: Exceptions, Panics, Leaves, and Traps
Exception : runtime error that is not the programmer’s fault
Panic : A run-time exception on Symbian OS that terminates the current thread. Panics tend to be caused when assertion statements fail.
It is programmatic error that is the programmer’s fault
Leave : Symbian OS exception handling. Execution leaves the method and jumps up the call stack to the closest exception handler
A function leaves when User::Leave()is called.
Trap / trap harness : central exception handler
Symbian OS provides two macros, TRAP and TRAPD, to trap a leave.
A variation on TRAP is TRAPD (the D is for declare). TRAPD is the same as TRAP except the TRAPD macro will declare the first argument (the leave code variable) so you do not have to. For example:
TRAPD(LeaveError,MyFunctionL());
is equivalent to:
TInt LeaveError;
TRAP(LeaveError,MyFunctionL());

Throw Exceptions: User::Leave()
void DoExampleL()
{
CExample* example = new CExample;
if (example == NULL)
{
User::Leave(KErrNoMemory);
}
// do something with example
delete example;
}
] L indicates that method may leave (naming convention) ] throw exception with reason code

Cleanup Stack: Avoid Memory Leaks
CleanupStack is a stack where you can store pointers of allocated objects e.g. myObject1 pointer in the scenario in previous slide.
If a leave occurs, TRAP macro frees the memory deleting the pointers in CleanupStack
You can store pointers by pushing them to CleanupStack as follows:
CleanupStack::PushL( myObject1 ), pushes object
myObject1 to the CleanupStack.
You can remove pointers by popping them from the CleanupStack as follows:
CleanupStack::Pop()
You can pop and destroy objects in cleanup stack by calling: CleanupStack::PopAndDestroy()
Pop and PopAnDestroy operations are always for the last object put on the CleanupStack.

Two Phase Constructor
Two phased construction:
1. Allocate the object itself without creating the dynamically allocated instances. Now we have a
pointer to this object.
This is done in the ’normal’ constructor.
2. After that we create the dynamical members.
This is done in ConstructL method.
If something goes wrong, we have the pointer so we can delete all allocated memory.
This is done in the NewL() and NewLC() –methods .

Descriptors: Containers for (16-bit) Text and (8-bit) Binary Data
Runtime bounds checking
API for buffer modification
Used extensively in Symbian OS APIs
Modifiable and nonmodifiable

Descriptor Classes Name Instatiable Modifiable Description TDesC No No abstract base class; argument passing and return values (const TDesC&) TDes No Yes abstract base class; argument passing return values (const TDes&) TBufC Yes No templated buffer descriptor: (size, data) stored together TPtrC Yes No pointer descriptor: (size, pointer) separate from data, data not owned TBuf Yes Yes templated buffer descriptor: (size, maximum size, data) stored together TPtr Yes Yes pointer descriptor: (size, maximum size, pointer) separate from data, data not owned HBufC Yes No heap descriptor: (size, maximum size, data) stored together on the heap

Descriptor API: Search, Extract, Insert, Delete, Replace, Format
Nonmodifiable
TInt Length ()
TInt Size ()
const TUint* Ptr ()
HBufC* Alloc ()
TPtrC Left (TInt aLength)
TPtrC Mid (TInt aPos,
TInt aLength)
TInt Find (const TDesC& aDes)
const TUint16& operator[] ()
Modifiable
TInt MaxLength ()
TInt MaxSize ()
void SetLength (Tint aLength)
void Append (const TDesC& aDes)
void Insert (TInt aPos, const TDesC& aDes)
void Delete (TInt aPos,Tint aLength);

Heap Buffer Descriptors HBufC: heap: (size, max size, data)
Used if descriptor size unknown at compile time
Change to pointer descriptor to modify
HBufC* buf16 = HBufC::NewLC(buf8.Length());
TPtr ptr16 = buf16->Des();
ptr16.Copy(buf8);
buf16 = buf16->ReAlloc(4 * buf8.Length());
CleanupStack::Pop();
CleanupStack::Push(buf16);
...
CleanupStack::PopAndDestroy(buf16);

Descriptors as Arguments and Return Types
Abstract base classes TDes and TDesC as formal parameters for flexibility
void SetName(const TDesC& aName);
const TDesC& Symbol() const ;

Outline d
Symbian overview

Any Queries!!! ☺

Thank you for your endurance! ☺

http://daytodayinformation.blogspot.com	57
http://daytodayinformation.blogspot.in	57
http://www.slideshare.net	6
http://www.daytodayinformation.blogspot.in	2
http://www.daytodayinformation.blogspot.com	1
http://daytodayinformation.blogspot.co.uk	1

Symbian Os Introduction

by deepak1795

Accessibility

Upload Details

Usage Rights

6 Embeds 124

Statistics