1. Symbian Basics

2. Agenda Overview of Symbian Platform –Introduction, History
Naming Conventions
–Variables, Constants, Classes, Functions, Enumerations
Coding Guidelines
–Header files, Class Layout, Multiple Inheritance
Layered Architecture
–System, Graphics, Uikon, Eikon, Avkon

4. History
1998
Symbian established as a private independent company in June 1998, owned by Ericsson, Nokia, Motorola and Psion
1999
Matsushita (Panasonic) joins Symbian as shareholder and licensee
Symbian awarded title of 'best overall' company with the 'best long term potential' by US magazine Red Herring

5. 2000
Sony and Sanyo license Symbian OS
The world’s first Symbian OS phone, the Ericsson R380, goes on sale to the public
2001
Fujitsu licenses Symbian OS
The first 2.5G Symbian OS phone, the Nokia 7650, is announced
The Nokia 9210 Communicator goes on sale to the public
2002
NTT DoCoMo launches 3G FOMA F2051 from Fujitsu
Sendo licenses Symbian OS
Siemens becomes a Symbian shareholder
Symbian OS v7.0 for 3G mobile phones unveiled
Sony Ericsson joins Symbian as a shareholder and licensee

6. 2003
Nokia 6600, the first phone to utilize Symbian OS v7.0s, produced
Symbian OS v7.0s unveiled
Successive new Symbian OS phones unveiled: FOMA F2102v and F900i, Motorola A920 and A925, Nokia 7700, Sendo X, Siemens SX1, Sony Ericsson P900
BenQ announces the P30, based on UIQ
Samsung becomes a Symbian shareholder
2004
Sharp licenses Symbian OS
Sir Peter Gershon joins Board of Symbian Limited as an independent chairman
Symbian shareholders purchase Psion stake in Symbian and invest a further £50m in cash funding
Lenovo, China’s largest IT corporation, licenses Symbian OS
Symbian OS v8.0 announced
Arima and LG Electronics license Symbian OS
New Symbian OS phones unveiled: Panasonic X700, Motorola A1000, Nokia 6260, 6630, 9500, 7610 and N-Gage QD, Samsung SGH-D710, Sony Ericsson P910, FOMA F900iT,F900iC and F880iES

7. 2005 Nigel Clifford named CEO of Symbian Limited
Symbian OS v9 announced
New Symbian OS phones unveiled: Leveno P930, Motorola A1010, Panasonic X800, Samsung SGH-D720, Sendo X2, Nokia 6680, Nokia 6681, FOMA F901iC, Nokia N90, Nokia N91, Nokia N70, Nokia 6682, FOMA D901i, FOMA F901iS, D901iS
Symbian licenses Microsoft Exchange Server ActiveSync protocol for Symbian OS

9. What is Symbian OS…?
It is Highly optimized, pre-emptive multitasking OS
95% written in C++ , some c and assembly
32 bit OS
Client server architecture
Have Modular approach
It is truly modular . Major components of the OS can be removed as and when needed.
Practical size of OS ranges from 500 KB to MB
Has full hierarchical file system
Path naming convention is identical to DOS/Windows naming convention

10. Why It is different from other OS……
Because…
Resources are constrained: The CPU is slower and there is less memory
There is NO HARD DISK
Power management is critical as most of the time user data is often placed on RAM.
Data and machine state must be maintained in low-power condition
To Summarize it…
we need to have that compact OS which addresses all the above mentioned issues and SYMBIAN OS addressees almost all these issues …
CPU speed: based on 190 MHz and 206 MHz StrongARM processors
RAM: ranges between 8-16 MB typically
ROM: 20 MB approx
Stack size: 8KB
Heap Size: 1MB

11. Design Constraints Of Symbian
Must be able to provide hours of operation without power down at all
Should support low power processors with limited amount of memory
Code reused should be maximized
Multiple inheritance is not supported
Reliability is enhanced with better error handling framework
Needs plug-in facility for protocol stack with necessary abstraction

12. Naming Conventions General
Always use meaningful and carefully considered names. In general, first letter of words capitalized.
All words adjoined
Avoid the use of ‘_’ <underscore> except in macros and resource IDs
Use mixed case to make names readable
Use abbreviations sparingly
Avoid long names(> 15 characters)
Avoid names that are similar or differ only in case
Capitalize the first letter of standard acronyms like SqlDatabase.

13. Automatic Variables First letter lowercase
Do not declare automatics until required
Always try to initialize variable when they are declared rather than assigning values to them
Never initialize or instantiate multiple items on the same line
Explanation: having the first letter of automatic variable lowercase is simply a convention to help reviewers and
maintainers to follow your code
• the main reason for not declaring automatics until required is because they may not be required; declaring
them at the start of a routine is therefore inefficient in terms of execution speed and use of stack space
• for lengthy routines, declaring automatics as close as possible to the point of use can also help people to
understand code fragments without having to refer back to the top
• initializing variables when they are declared is more efficient (smaller and faster code) and avoids the risk of
using the variable in an uninitialized state
• declaring multiple items on the same line can lead to errors such as:
TText* data1, data2;
TInt int1, int2 = 0;
when the programmer meant:
TText* data1;
TText* data2;
TInt int1=0;
TInt int2=0;

14. Global Variables Macros Use of global variables is discouraged
Start names with a capital letter. In cases where confusion might be caused you may use a small g prefix, e.g., gTotal
Non-const global data is not supported in DLLs; better to use thread local storage
Macros
All capitalized
An underscore separate words, e.g., IMPORT_C _TEST_INVARIANT
The main reason writeable static data (WSD) is not supported on Symbian OS, is that it comes at the cost of significant memory wastage
The main sources of memory wastage are discussed below: 1. Requirement for multiple copies of DLLs in RAM All processes that use a DLL must set the same address for the DLL's static data, because the address is referenced by the shared DLL code. If the required address is free when the process comes to use the DLL, then there is no problem. However it is perfectly possible that the address might not be free, so the copy of the DLL in memory cannot be used. The workaround is to copy the DLL code and modify the copy to use a different address for static data. Symbian OS does not consider this duplication acceptable. 2. Inefficient use of RAM pages The amount of memory needed for writable static data by any DLL is likely to be much smaller (<0x100 bytes) than the smallest possible RAM allocation (4K). The remaining memory is wasted. Since the memory is per-process-dll-static-data, the memory wastage on the machine is: (4K-WSD bytes)*number-client-processes.

15. Pointer and Reference Types
Specifier placed next to type; not next to name
TText* data;
void TDemo::Append(const TDesc& aData);
Class Names
‘C’,’R’,’T’,’M’ class types only (the first letter of the class name).The class naming distinction helps reinforce valuable programming idioms.
Structs are ‘T’ ;structs with attitude
static classes have no prefix letter
exceptionally, driver classes known by the kernel are 'D' classes.

16. Examples class CBase; class TTypefaceInfo; class RFont; class MLaydoc;
class User; // static class
class EikUtils; // static class
class Time; // static class

17. Function names general rules apply Setters are typically SetThing().
Getters are typically Thing() if the function returns the item.
Examples:
void TObject::PrepareForCommit()
{DoPrepareForCommit();}
void SetOffset(TInt aOffset);
TInt Offset() const;
TInt offset=Offset();

18. 'Get' used for functions that set values into reference arguments.
Example
TCharFormat format;
GetCharFormat(format);
Trailing 'L' means function may leave; lack of trailing ‘L’ means it does not leave
Trailing 'C' means function places an item on the cleanup stack
Trailing 'D' means the object in question will be destroyed
CStoreMap* map=CStoreMap::NewLC(); // map returned on cleanup stack

19. Member data preceding 'i' lowercase; for instance data. Example:
class TObject {
TType iType;
TInt iElementOffset;
TPtrC iComponentValue; };

20. • preceding 'a' lowercase; for argument data
Function arguments
• preceding 'a' lowercase; for argument data
• do not use 'an' before a vowel
Example
void TObject::TObject(TType aType,TInt aElementOffset) {
iType=aType;
iElementOffset=aElementOffset; }

21. Constants • preceding 'K', uppercase. Example
const TInt KMaxNameLength=0x20;
const TUid KEditableTextUid={ }

22. • should be scoped within the relevant class
Enumerations
• should be scoped within the relevant class
• do not pollute the global name space
• must have a meaningful, unambiguous name
• enumerations are types; therefore 'T' classes
• uppercase 'E' for enum members
• class-specific constants can be implemented as enums and in that case are ‘K’

23. Example class TDemo { public: enum TShape {EShapeRound, EShapeSquare};
enum TFruit
{// Fruit definitions
EFruitOrange,
EFruitBanana,
EFruitApple }
TDemo::TShape shape=TDemo::EShapeSquare;

24. Coding Guidelines Header Files
use references in preference to pointers - if none of the criteria for using pointers apply; (see below)
• pay attention to const; use const for parameters and return values if the data is not to be modified
• encourage generality; use the least derived class possible
Examples
void Foo(const CArrayFix<X>& aX);
rather than
void Foo(const CArrayFixFlat<X>& aX);

25. • when writing a Symbian OS library, attention must be given to which functions are defined as EXPORT_C
• do not export (const) data; rather, export a function returning a reference/pointer to the data.
• only export private functions if…
- they are accessed via public inline members.
- They are virtual and the class is intended for derivation outside the library.
• For public or protected members…
- do not export functions that are not designed for use outside the library
- do not export pure virtual functions
- do not export inline functions

26. always write access control specifiers; removes all ambiguity
• list the public methods first, with special member functions at the top
• list public member data before private member data(otherwise changing the private data would break binary compatability)
• use explicit access specifiers at the start of each class section…
friend classes
public methods
protected methods
private methods
public data
protected data
private data

27. heed binary compatibility issues with respect to promoting functions' access control specifiers; (if you change the access for something after an API freeze, you may have to leave it in exactly the same place as before).
• use white space to group related functions and improve readability
• function arguments are named in the function declaration (as well as the definition). Improves readability
• obey the indentation conventions.

28. Example Header layout
// DEMHEADR.H
#ifndef __DEMHEADR_H__
#define __DEMHEADR_H__
#include <e32std.h>
class CContainer; // forward reference avoids header inclusion
class CShape : public CBase, public MEmptyable {
public:
enum TShape
EShapeCircle,
EShapeSquare, }
IMPORT_C static CShape* NewL(TShape aValue);
inline CContainer* Container() const;
inline void SetContainer(CContainer* aContainer);
private:
CShape(TInt aShape);
void ConstructL();
CContainer* iContainer;
TInt iValue; };
#endif // __DEMHEADR_H__

29. • be consistent in the use of programming conventions
Source Modules
Writing good code
• build code that gives 0 compiler warnings and 0 link errors; it is dangerous to ignore compiler warnings, and
these are highly likely to generate errors on othercompilers. Complacency regarding compiler warnings leads to important new compiler warnings not being noticed among a pile of familiar warnings
• be consistent in the use of programming conventions
• strive to write tight, efficient code
• minimize on stack usage
• minimize on the number of calls to the allocator
• always ask... what would happen if this code were to leave?
• avoid hard-coding magic numbers; use constants or enumerations.

30. Basic types
e32def.h defines concrete types; use them.
Example
TInt32 integer;
... and not...
long int integer;
Date classes
Use the Symbian OS date and time classes, such as TDateTime, instead of hand-crafted alternatives.

31. String and buffer classes
Use the Symbian OS descriptor classes, such as TPtr, TDesC and TBuf<n>; instead of ‘native’ text string classes or hand-crafted buffer classes. This results in code that is much more easily converted between wide-character and narrow-character builds, and also has gains in efficiency and robustness over other string classes.

32. Indentation
• indentation is performed using 4 space tabs, not spaces
• opening braces are indented to align with the code that follows; they are not aligned with the preceding code;
i.e. braces form part of the indented code.
Example:
void CItem::Function() {
Foo(); }
...and not...

33. Class types
• it is strongly recommended that you use direct initialization for class types
• the use of copy initialization is deprecated.
Explanation:
If you declare a class type using the copy constructor = like this:
TParsePtrC parser=TPtrC(FileName);
…then the initialization of TParsePtrC effectively requires a call to TParsePtrC::TParsePtrC(const TPtrC&) followed by a call to TParsePtrC's copy constructor
TParsePtrC::TParsePtrC(const TParsePtrC&).
This is significantly more expensive than directly initalizing the class type, which is done like this:
TParsePtrC parser((TPtrC(FileName)));
and eliminates the redundant call of the copy constructor.

34. Multiple inheritance
In general…
• M.I. is fine; only 'M' classes (mixins) are inherited
• Mixins specify interface only, not implementation
• inherit from CBase-derived class first; achieve correct layout of the v-table
• inherit from only one CBase-derived class; other super-classes must be mixins
refer to the Symbian Developer Library for further information
class CGlobalText : public CPlainText, public MLayDoc, public MFormatText {
... };

35. Casting
• casts may indicate questionable code, always use with caution
• use the correct casting operator as this improves readability and removes ambiguity
• always use the C++ casts
• avoid using C-style casts.
Note: be aware that, for historical reasons, Symbian OS provides the following macros to encapsulate the C++ cast operators.
REINTERPRET_CAST
STATIC_CAST
CONST_CAST
MUTABLE_CAST
These are historical and should not be used in any new code. These used to be needed because some older compilers did not fully support all the C++ casts. Always use the standard C++ casts in any new code e.g.
static_cast<>()

36. Layered Architecture
A graphical user interface (GUI) application is separated
into two parts:
an engine (model)
user interface (UI) ,usually called simply the application in Symbian OS
Application part has two main tasks:
it deals with the visual representation of the application data on the screen (picked up from the engine),
it sets the overall behavior of the application, defining how the users interact with the application.
A graphical user interface (GUI) application is separated
into an engine part and user interface (UI) part . The application engine, also known as an application model, contains all data of the application
and the structures and algorithms dealing with it. The engine is
responsible for interacting with the system devices, such as the file
system, communications, etc. The application user interface, usually
called simply the application in Symbian OS, has two main tasks:
it deals with the visual representation of the application data on the
screen (picked up from the engine), and it sets the overall behavior of
the application, defining how the users interact with the application.

37. User Interface Architecture
A high-level description of the UI architecture of any GUI application is
shown in Figure. The system level contains the base (EUser library,
device drivers, etc.) and system servers (communications servers, Window
server, etc.). The graphics layer takes care of drawing all the
graphics on the screen. The core contains the application framework,
called Uikon. The Uikon framework consists of several libraries providing
services for application launching and state persistence, which
allows the restoration of the same state in which the application was
previously closed. Other libraries provide classes for event handling

38. The system level contains the base (EUser library, device drivers, etc
The system level contains the base (EUser library, device drivers, etc.) and system servers (communications servers, Windowserver, etc.).
The graphics layer takes care of drawing all the graphics on the screen.
The core contains the application framework, called Uikon. The Uikon framework consists of several libraries providing services for application launching and state persistence, which allows the restoration of the same state in which the application was previously closed. Other libraries provide classes for event handling and standard GUI components (also known as controls) with basic look and feel for all Uikon applications.
An adaptable core (standard Eikon) is implemented by the provider of the UI style. In the case of the Series 60 Platform, standard Eikon has been implemented by Nokia. Together with a style-dependent framework extension (Avkon), standard Eikon provides the style-dependent set of UI components with their own look and feel.

39. Uikon Application Framework
In Figure, the contents of the Uikon framework is depicted in
more detail. Application architecture (App Arc) and control environment
(CONE) provide a great deal of UI functionality in a general
and an abstract form. Uikon makes the UI functionality concrete. In
addition, Uikon supplies the look and feel for the standard UI components.
The Uikon and CONE frameworks have virtual functions
through which the rest of Symbian OS can be reused. Application
developers derive classes implementing these virtual functions with
any specific functionality required. Writing GUI applications involves
a great deal of derivation from the base classes of Uikon and CONE.

40. Uikon Application Classes
The Uikon framework is used by deriving own application classes from
its base classes and specializing their behavior if required. The base
classes of applications and their relationship to the Ukon application
architecture and control environment are shown in Figure

41. Application class
The application class is derived from CEikApplication, which is derived from a class declared by the application architecture. There are two functions to be implemented in this class, CreateDocumentL(), which creates the application’s document, and AppDllUid(), which identifies the application by returning its unique identifier.
Document class
The document class is derived from CEikDocument, which is derived from a class in the application architecture. The document class instantiates the application engine (model) and creates the AppUI object using the CreateAppUiL() function.
AppUI class
The AppUI class is derived from CEikAppUI, which is derived from the base class in the CONE (CCoeAppUi). The main task of this class is to handle application-wide UI details. Responses to various kinds of events can be handled at the AppUI level by implementing virtual functions of the base class. The functions are not purely virtual, but their implementation is empty.

42. View
The application view is derived from the CONE control class
(CCoeControl) or any class for which the base class is CCoeControl. All controls need to draw themselves (unless they are simply containers having controls). Thus, they have to implement a virtual Draw() function, defined in CCoeControl. The Draw() function receives a parameter, which is a reference to TRect object generated by the windows server. The object contains the smallest bounding box to need redrawing. TRect classes represent rectangles, the sides of which are parallel to the axes of the coordinate system.

43. For more information, refer:
Thank You….!
For more information, refer:

44. Contributed By: Sulabh Srivastava