0% found this document useful (0 votes)
33 views23 pages

Symbian OS

Symbian OS evolved from the earlier SIBO and EPOC operating systems, becoming the foundation for mobile devices after being acquired by Nokia and other manufacturers in 1998. It features a small footprint for efficient performance on limited-resource devices, supports pre-emptive multitasking, and provides a robust development environment primarily using C++ and Java. The architecture includes multiple layers for hardware interaction, application framework, and user interface management, ensuring a consistent experience across applications.

Uploaded by

azsafrah
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
33 views23 pages

Symbian OS

Symbian OS evolved from the earlier SIBO and EPOC operating systems, becoming the foundation for mobile devices after being acquired by Nokia and other manufacturers in 1998. It features a small footprint for efficient performance on limited-resource devices, supports pre-emptive multitasking, and provides a robust development environment primarily using C++ and Java. The architecture includes multiple layers for hardware interaction, application framework, and user interface management, ensuring a consistent experience across applications.

Uploaded by

azsafrah
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 23

Symbian OS

Architecture
INTRODUCTION
 Symbian OS did indeed evolve out of an earlier operating system
called SIBO (short for "Seattle Invented Battery Operated"), which
was developed by Psion in the late 1980s and early 1990s for their
handheld computers.
 SIBO was later renamed to EPOC (short for "Extended Pseudo-
Operating System"), which was used in Psion's Series 5 and Series 7
handheld computers in the late 1990s.
 When Nokia, Ericsson, and other mobile phone manufacturers
formed the Symbian Ltd. joint venture in 1998, they acquired the
rights to EPOC and used it as the basis for Symbian OS.
Features of Symbian OS
Hardware support: includes a full qwerty keyboard, a 0–9*# a T-Key pad, voice,
handwriting recognition and predictive text input.

OS Features: include a hard real-time, multithreaded kernel working with CPUs,


peripherals and memories. Software support is provided through dedicated application
engines for contacts, schedule, messaging, browsing, OBEX, etc., support for multimedia
hardware acceleration, direct access to screen and keyboard for high performance.

Application Development Environments: include C++, Java ( J2ME) MIDP 2.0,


WAP.Application engines for audio and video recording, playback ,streaming, graphics,
Unicode Standard Version 3.0 for international support, etc. The system provides
comprehensive security through encryption and certificates, secure protocols (HTTPS, SSL
and TLS), WIM framework and authentication for installation of third party applications.
Versions-Symbian OS
SYMBIAN OS ARCHITECTURE
 Symbian OS lies in its small footprint.
 In computing, the term "footprint" generally refers to the amount of memory or storage
space that a program or operating system requires in order to run. In the context of
mobile devices, the footprint is particularly important because these devices typically
have limited memory and storage capacity.
 In the case of Symbian OS, its small footprint meant that it could run efficiently on
mobile devices with limited resources, without compromising performance or
functionality. This was a key factor in the success of
 The small footprint also made it easier for device manufacturers to customize the OS to
their specific requirements and add their own features and applications.
Symbian OS supports pre-emptive
multitasking
 means that the OS can interrupt and switch between different tasks or processes to
allow for more efficient use of system resources.
 In Symbian OS, system services such as device drivers, memory management, and
input/output operations run in privileged mode, while user applications run in a user
context. When an application requests a system service, the OS temporarily
switches the application's context to privileged mode to grant it access to the
requested service. Once the service has been provided, the context is switched back
to user mode.
 This mechanism is similar to the way that operating systems like UNIX and
Windows NT handle system calls, where user processes make requests for system
services and the OS switches the process context to kernel mode to perform the
requested service before switching back to user mode.
SYMBIAN OS ARCHITECTURE
SYMBIAN OS ARCHITECTURE
 A Symbian system can be divided into three layers, where the
bottom most layer interacts with the underlying hardware/hardware
abstraction layer: includes the kernel, memory, device drivers and file
services.
 The top of this layer network and security support components.
Also included are multimedia and communication protocol implementations.
 The third layer is the application framework and applications
support mechanism for PC synchronization, Bluetooth and USB support.
 The topmost layer of course is the development environment
and the applications themselves.
SYMBIAN OS ARCHITECTURE
 The kernel encapsulates the system services like multitasking, file services,
power management, memory management and the various device drivers.
 It includes support for the telephony services for GSM, GPRS, CDMA and
the security features.
 Symbian also makes extensive use of a special type of DLL called
polymorphic DLL. A notable example is the application DLL, which exports
NewApplication( ), to create an instance of an application.
Hardware Interfaces
It has a range of hardware interfaces that allow it to interact with different types of
hardware components. Here are some of the hardware interfaces in Symbian OS:
 Audio Interfaces
 Bluetooth Interfaces
 Camera Interfaces
 USB Interfaces
 GPS Interfaces
 Display Interfaces
 Input Interfaces
The operating system also supports other interfaces, such as Wi-Fi, infrared, and FM radio.
Memory Management
Here are some key features of memory management in Symbian OS:
 Heap-Based Memory Management: Each process has its own heap, which can be
dynamically resized to accommodate changing memory requirements.
 Memory Protection: Symbian OS provides memory protection mechanisms to prevent
one process from accessing the memory of another process.
 Paging: Symbian OS uses a paging system to manage virtual memory.
 Memory Compression: Symbian OS also supports memory compression, where unused
memory pages are compressed and stored in memory to free up space for other
processes.
 Memory Fragmentation Prevention: Symbian OS uses a number of techniques to prevent
memory fragmentation, which can occur when memory is repeatedly allocated and
deallocated. These techniques include heap compaction.
Development Environment
Symbian OS provided two development environments for developers to create
applications: C++ and Java.
 C++: Symbian OS was primarily designed to support C++ programming language.
Symbian C++ provided additional features such as support for garbage collection,
multithreading, and real-time performance. Developers could use the Symbian C++
development environment to create native applications for Symbian OS.
 Java: The Java development environment for Symbian OS was based on the Java ME
(Micro Edition) platform. Java applications were typically slower than native
applications but provided platform independence and ease of development.
In addition to C++ and Java, Symbian OS also provided support for other programming
languages such as Python and Ruby. However, C++ and Java were the most widely used
development environments for Symbian OS applications.
Structure and life cycle of a Symbian program
 The structure and life cycle of a Symbian program can be broken down into several
phases:
 Application Development: The application is typically developed on a personal
computer using an integrated development environment (IDE) such as Nokia Qt
Creator, Carbide.c++, or Eclipse.
 Compilation
 Packaging: After compilation, the application is packaged into a SIS (Symbian
Installation) file. The SIS file contains the application binaries, resources, and any
other required files.
 Installation: The SIS file is installed on the Symbian device using the built-in
application installer or third-party installer. During installation, the SIS file is checked
for any dependencies and installed accordingly.
Model-View-Controller (MVC) pattern
Model-View-Controller (MVC) pattern
 The Model-View-Controller (MVC) pattern is a software design pattern that separates
an application into three interconnected components: the model, the view, and the
controller.
 The model represents the data and the business logic of the application. It encapsulates
the application's data and provides methods for accessing and manipulating that data.
 The view represents the presentation of the data. It provides a user interface for the
application and displays the data to the user.
 The controller acts as an intermediary between the model and the view. It receives
input from the user through the view, updates the model accordingly, and updates the
view to reflect changes in the data.
Model-View-Controller (MVC) pattern
Application Framework
Application Framework
 Uikon is a key component of the Symbian OS application framework. It provides a standard
user interface framework that is common across all Symbian OS platforms. Uikon defines a
set of UI components and services that can be used by developers to create consistent and
familiar user interfaces for their applications. These components and services include things
like menus, dialogs, buttons, text entry fields, and various other UI controls.
 The use of a common UI framework like Uikon helps to ensure that applications built for
Symbian OS have a consistent look and feel, regardless of the specific device they are
running on. It also helps to simplify the development process, as developers can rely on a set
of pre-defined UI components rather than having to create their own from scratch.
 Overall, Uikon plays an important role in the development of applications for Symbian OS,
and has helped to make the platform more accessible and easier to use for both developers
and end users.
Application Framework
 Control Environment (CONE) is another important component of the Symbian OS
framework. It provides a framework for managing and organizing the resources used by
Symbian OS applications, such as icons, bitmaps, sounds, and other multimedia content.
 CONE is designed to be a flexible and extensible framework, allowing developers to create
their own custom resource types and to manage these resources using the standard CONE
APIs. It also provides a number of other features, such as support for localization and
internationalization, that make it easier for developers to create applications that can be used
in different languages and regions.
 One of the key benefits of the CONE framework is that it provides a unified way of
managing resources across the entire Symbian OS platform. This makes it easier for
developers to create applications that work consistently across different devices and versions
of the OS.
Components of a Symbian Application
Components of a Symbian Application
 In Symbian OS, the document object model (DOM) is a core component of the application
architecture. The DOM defines a standard way of representing the content and structure of a
document or data object, and provides a set of APIs that can be used to manipulate the
document's contents.
 The document object in Symbian OS is typically used to represent the application's data model
or persistent state. The application's state is stored within the document object and is
manipulated using the APIs provided by the DOM. This allows the application to save and
restore its state across multiple sessions or device reboots.
 In Symbian OS, the document object can be thought of as the central engine that drives the
application. It provides a standard way of representing the application's data, and allows
developers to create applications that can easily save and restore their state. This is an important
feature in mobile devices, where battery life and device restarts can be common occurrences.
Components of a Symbian Application
 In Symbian OS, the AppUi (Application User Interface) class is responsible for creating and
managing the application's user interface. The AppUi is typically the main class of a Symbian
OS application and is responsible for creating the application's user interface controls, views,
and handling UI events such as user input, options menu commands, opening/closing files, and
the application losing focus.

 The AppUi also handles system events such as power loss, memory management, and other
platform-specific events that may affect the application. It acts as a mediator between the
application's UI and its backend logic, ensuring that the application behaves consistently and
responds appropriately to user input and system events.
Components of a Symbian Application
 In Symbian OS, a View is a UI control that displays data on the screen that the user can interact
with. Views are typically used to present information to the user and to receive input from the user.

 The View in Symbian OS follows the Model-View-Controller (MVC) architecture. In this


architecture, the View is responsible for displaying the data from the Model to the user and for
handling user input. Views are typically notified of updates in the model's state by an observer
mechanism, which allows them to update their display based on changes in the underlying data.
The View also passes user commands back to the AppUi, which then translates them into actions
that the Model can take.

 In Symbian OS, Views are typically created and managed by the AppUi. The AppUi is responsible
for creating and initializing the Views and for handling their lifecycle. Views can be reused in
different parts of the application, and the AppUi can switch between different Views to display
different information to the user.

You might also like