seminar symbian

8/2/2019 Seminar Symbian

1/52

CHAPTER 1

HISTORY:

Psion:

In 1980, Psion was founded by David Potter

Symbian OS v6.0 and 6.1:

Sometimes called ER6. The first 'open' Symbian OS phone, theNokia 9210 Communicator, was

released in June 2001. Bluetooth support added. Almost 500,000 Symbian phones were shipped in

2001, rising to 2.1 million the following year.

Development of different UIs was made generic with a "reference design strategy" for either

'smartphone' or 'communicator' devices, subdivided further into keyboard- or tablet-based designs.

Two reference UIs (DFRDs) were shipped - Quartz and Crystal. The former was merged with

Ericsson's 'Ronneby' design and became the basis for the UIQ interface, the latter reached the

market as the Nokia Series 80 UI.

Later DFRDs were Sapphire, Ruby, and Emerald. Only Sapphire came to market, evolving into the

Pearl DFRD and finally the Nokia Series 60 UI, a keypad-based 'square' UI for the first true

smartphones.

Despite these efforts to be generic the UI was clearly split between competing companies, Crystal

or Sapphire was Nokia, Quartz was Ericsson. DFRD was abandoned by Symbian in late 2002, as

part of an active retreat from UI development in favour of 'headless' delivery. Pearl was given to

Nokia, Quartz development was spun-off as UIQ Technology AB, and work with Japanese firms

was quickly folded into the MOAP standard.

Symbian OS 7.0 and 7.0s

First shipped in 2003. This is an important Symbian release which appeared with all contemporary

user interfaces including UIQ (Sony Ericsson P800, P900, P910, Motorola A925, A1000),

1
http://en.wikipedia.org/wiki/Psionhttp://en.wikipedia.org/wiki/David_Potterhttp://en.wikipedia.org/wiki/Nokia_9210http://en.wikipedia.org/wiki/Bluetoothhttp://en.wikipedia.org/wiki/UIQhttp://en.wikipedia.org/wiki/Series_80http://en.wikipedia.org/wiki/Series_60http://en.wikipedia.org/w/index.php?title=MOAP&action=edit&redlink=1http://en.wikipedia.org/wiki/UIQhttp://en.wikipedia.org/wiki/Psionhttp://en.wikipedia.org/wiki/David_Potterhttp://en.wikipedia.org/wiki/Nokia_9210http://en.wikipedia.org/wiki/Bluetoothhttp://en.wikipedia.org/wiki/UIQhttp://en.wikipedia.org/wiki/Series_80http://en.wikipedia.org/wiki/Series_60http://en.wikipedia.org/w/index.php?title=MOAP&action=edit&redlink=1http://en.wikipedia.org/wiki/UIQ


2/52

Series 80 (Nokia 9300, 9500), Series 90 (Nokia 7710), Series 60 (Nokia 3230, 6600,

7310) as well as several FOMA phones in Japan. It also addedEDGE support andIPv6.

Java support was changed from pJava and JavaPhone to one based on the Java ME

standard.

One million Symbian phones were shipped in Q1 2003, with the rate increasing to one million a

month by the end of 2003.

Symbian OS 7.0s was a version of 7.0 special adapted to have greater backwards compatibility

with Symbian OS 6.x, partly for compatibility between the Communicator 9500 and its

predecessor the Communicator 9210.

In 2004, Psion sold its stake in Symbian. The same year, the first worm for mobile phones using

Symbian OS,Cabir, was developed, which used Bluetooth to spread itself to nearby phones. See

Cabirand Symbian OS threats.

Symbian OS 8.0

First shipped in 2004, one of its advantages would have been a choice of two different kernels

(EKA1 or EKA2). However, the EKA2 kernel version did not ship until Symbian OS 8.1b. The

kernels behave more or less identically from user-side, but are internally very different. EKA1 was

chosen by some manufacturers to maintain compatibility with old device drivers, while EKA2 was

a real-time kernel. 8.0b was deproductized in 2003.

Also included were new APIs to support CDMA, 3G, two-way data streaming, DVB-H, and

OpenGL ES with vector graphics and direct screen access.

Symbian OS 8.1

Basically a cleaned-up version of 8.0, this was available in 8.1a and 8.1b versions, with EKA1 and

EKA2 kernels respectively. The 8.1b version, with EKA2's single-chip phone support but no

additional security layer, was popular among Japanese phone companies desiring the real-time

support but not allowing open application installation.

Symbian OS 9.0

2
http://en.wikipedia.org/wiki/Series_80http://en.wikipedia.org/wiki/Series_90http://en.wikipedia.org/wiki/Series_90http://en.wikipedia.org/wiki/Series_60http://en.wikipedia.org/wiki/Series_60http://en.wikipedia.org/wiki/FOMAhttp://en.wikipedia.org/wiki/FOMAhttp://en.wikipedia.org/wiki/Enhanced_Data_Rates_for_GSM_Evolutionhttp://en.wikipedia.org/wiki/Enhanced_Data_Rates_for_GSM_Evolutionhttp://en.wikipedia.org/wiki/IPv6http://en.wikipedia.org/wiki/IPv6http://en.wikipedia.org/wiki/Computer_wormhttp://en.wikipedia.org/wiki/Caribe_(computer_worm)http://en.wikipedia.org/wiki/Caribe_(computer_worm)http://en.wikipedia.org/wiki/Bluetoothhttp://en.wikipedia.org/wiki/Caribe_(computer_worm)http://en.wikipedia.org/wiki/Symbian_OS_threatshttp://en.wikipedia.org/wiki/Real-timehttp://en.wikipedia.org/wiki/CDMAhttp://en.wikipedia.org/wiki/3Ghttp://en.wikipedia.org/wiki/DVB-Hhttp://en.wikipedia.org/wiki/OpenGLhttp://en.wikipedia.org/wiki/Vector_graphichttp://en.wikipedia.org/wiki/Series_80http://en.wikipedia.org/wiki/Series_90http://en.wikipedia.org/wiki/Series_60http://en.wikipedia.org/wiki/FOMAhttp://en.wikipedia.org/wiki/Enhanced_Data_Rates_for_GSM_Evolutionhttp://en.wikipedia.org/wiki/IPv6http://en.wikipedia.org/wiki/Computer_wormhttp://en.wikipedia.org/wiki/Caribe_(computer_worm)http://en.wikipedia.org/wiki/Bluetoothhttp://en.wikipedia.org/wiki/Caribe_(computer_worm)http://en.wikipedia.org/wiki/Symbian_OS_threatshttp://en.wikipedia.org/wiki/Real-timehttp://en.wikipedia.org/wiki/CDMAhttp://en.wikipedia.org/wiki/3Ghttp://en.wikipedia.org/wiki/DVB-Hhttp://en.wikipedia.org/wiki/OpenGLhttp://en.wikipedia.org/wiki/Vector_graphic


3/52

This version was used for internal Symbian purposes only. It was deproductised in 2004. 9.0

marked the end of the road for EKA1. 8.1a is the final EKA1 version of Symbian OS.

Symbian OS has generally maintained reasonablebinary compatibility. In theory the OS was BC

from ER1-ER5, then from 6.0 to 8.1b. Substantial changes were needed for 9.0, related to tools and

security, but this should be a one-off event. The move from requiring ARMv4 to requiring ARMv5

did not break backwards compatibility.

A Symbian developer proclaims that porting from Symbian 8.x to Symbian 9.x is a more daunting

process than Symbian says.

Symbian OS 9.1

Released early 2005. It includes many new security related features, particularly a controversial

platform security module facilitating mandatory code signing. Symbian argues that applications

and content, and therefore a developers investment, are better protected than ever, however others

contend that the requirement that every application be signed (and thus approved) violates the

rights of the end-user, the owner of the phone, and limits the amount of free software available.

The new ARM EABI binary model means developers need to retool and the security changes mean

they may have to recode. S60 platform 3rd Edition phones have Symbian OS 9.1. Sony Ericsson is

shipping the M600 and P990 based on Symbian OS 9.1. The earlier versions had a fatal defect

where the phone hangs temporarily after the owner sent hundreds of SMS'es. However, on 13September2006, Nokia released a small program to fix this defect. Support forBluetooth 2.0 (was

1.2)

Symbian OS 9.2

Released Q1 2006. Support for OMA Device Management 1.2 (was 1.1.2). S60 3rd Edition

Feature Pack 1 phones have Symbian OS 9.2. Nokia phones with Symbian OS 9.2 OS:Nokia E90,

Nokia N95,Nokia E51, Nokia 5700, Nokia N81, Nokia N78, Nokia 6290, Nokia 6120 classic,Nokia N82.

Symbian OS 9.3

3
http://en.wikipedia.org/wiki/Binary_compatibilityhttp://en.wikipedia.org/wiki/Mandatory_code_signinghttp://en.wikipedia.org/wiki/EABIhttp://en.wikipedia.org/wiki/S60_platformhttp://en.wikipedia.org/wiki/Sony_Ericsson_M600http://en.wikipedia.org/wiki/Sony_Ericsson_P990http://en.wikipedia.org/wiki/September_13http://en.wikipedia.org/wiki/September_13http://en.wikipedia.org/wiki/2006http://en.wikipedia.org/wiki/Bluetoothhttp://en.wikipedia.org/wiki/OMA_Device_Managementhttp://en.wikipedia.org/wiki/S60_platformhttp://en.wikipedia.org/wiki/Nokia_E90http://en.wikipedia.org/wiki/Nokia_N95http://en.wikipedia.org/wiki/Nokia_E51http://en.wikipedia.org/wiki/Nokia_5700http://en.wikipedia.org/wiki/Nokia_5700http://en.wikipedia.org/wiki/Nokia_N81http://en.wikipedia.org/wiki/Nokia_N81http://en.wikipedia.org/wiki/Nokia_N78http://en.wikipedia.org/wiki/Nokia_N78http://en.wikipedia.org/wiki/Nokia_6290http://en.wikipedia.org/wiki/Nokia_6120_classichttp://en.wikipedia.org/wiki/Nokia_N82http://en.wikipedia.org/wiki/Binary_compatibilityhttp://en.wikipedia.org/wiki/Mandatory_code_signinghttp://en.wikipedia.org/wiki/EABIhttp://en.wikipedia.org/wiki/S60_platformhttp://en.wikipedia.org/wiki/Sony_Ericsson_M600http://en.wikipedia.org/wiki/Sony_Ericsson_P990http://en.wikipedia.org/wiki/September_13http://en.wikipedia.org/wiki/September_13http://en.wikipedia.org/wiki/2006http://en.wikipedia.org/wiki/Bluetoothhttp://en.wikipedia.org/wiki/OMA_Device_Managementhttp://en.wikipedia.org/wiki/S60_platformhttp://en.wikipedia.org/wiki/Nokia_E90http://en.wikipedia.org/wiki/Nokia_N95http://en.wikipedia.org/wiki/Nokia_E51http://en.wikipedia.org/wiki/Nokia_5700http://en.wikipedia.org/wiki/Nokia_N81http://en.wikipedia.org/wiki/Nokia_N78http://en.wikipedia.org/wiki/Nokia_6290http://en.wikipedia.org/wiki/Nokia_6120_classichttp://en.wikipedia.org/wiki/Nokia_N82


4/52

Released on 12 July 2006. Upgrades include improved memory management and native support

for Wifi 802.11, HSDPA, Vietnamese language support. TheNokia N96 will feature Symbian OS

9.3.

Symbian OS 9.5

It was announced in March 2007. It provides the concept of demand paging which is available

from v9.3 onwards. Applications should launch up to 75% faster. Native support for mobile digital

television broadcasts in DVB-H and ISDB-T formats and also location services. Additionally, SQL

support is provided by SQLite.

1.2 WHAT IS SYMBIAN MOBILE OS:

Symbian OS is the basis of a lot of phones, probably more than you realize. Over 100 million

phones are powered by symbian os, representing over 100 different phone models. most of these

devices look completely different to each other some have keyboards, others use pen input; some

have color TFT screens, others monochrome lcd displays; some specialize in music, others in

games, in imaging or even in television; some are consumer devices, others are for business users;

some are designed for one-handed operation, others for two-handed use the variation is almost

endless .people like symbian os phones. in 2006, over 50 million symbian os devices were sold at

a rate of more than one phone a second. Network operators like symbian os

phones, too. Over 250 mobile phone network operators worldwide have adopted symbian os

phones for their networks.

Symbian OS, with its roots in Psion Software's EPOC(EPOC is the name of Symbian compiler), is

structured like many desktop operating systems with pre-emptive multitasking and memory

protection. EPOC was inspired by a VMS-like approach to multitasking with server-based

asynchronous serialized access based on events.

Symbian OS was built to follow three design rules - the integrity and security of user data is

paramount, user time must not be wasted, and all resources are scarce. This led to a continuation of

the use of servers; a microkernel; a request and callback approach to all services; an absolute

division of user interfaces from system or application services; reuse and openness; extensibility;

and robust management and resource recovery to support extended always-on operation. For

4
http://en.wikipedia.org/wiki/July_12http://en.wikipedia.org/wiki/2006http://en.wikipedia.org/wiki/802.11http://en.wikipedia.org/wiki/HSDPAhttp://en.wikipedia.org/wiki/Nokia_N96http://en.wikipedia.org/wiki/Digital_televisionhttp://en.wikipedia.org/wiki/Digital_televisionhttp://en.wikipedia.org/wiki/DVB-Hhttp://en.wikipedia.org/wiki/ISDB-Thttp://en.wikipedia.org/wiki/SQLhttp://en.wikipedia.org/wiki/SQLitehttp://en.wikipedia.org/wiki/Psionhttp://en.wikipedia.org/wiki/EPOC_(computing)http://en.wikipedia.org/wiki/Pre-emptive_multitaskinghttp://en.wikipedia.org/wiki/Memory_protectionhttp://en.wikipedia.org/wiki/Memory_protectionhttp://en.wikipedia.org/wiki/VMShttp://en.wikipedia.org/wiki/July_12http://en.wikipedia.org/wiki/2006http://en.wikipedia.org/wiki/802.11http://en.wikipedia.org/wiki/HSDPAhttp://en.wikipedia.org/wiki/Nokia_N96http://en.wikipedia.org/wiki/Digital_televisionhttp://en.wikipedia.org/wiki/Digital_televisionhttp://en.wikipedia.org/wiki/DVB-Hhttp://en.wikipedia.org/wiki/ISDB-Thttp://en.wikipedia.org/wiki/SQLhttp://en.wikipedia.org/wiki/SQLitehttp://en.wikipedia.org/wiki/Psionhttp://en.wikipedia.org/wiki/EPOC_(computing)http://en.wikipedia.org/wiki/Pre-emptive_multitaskinghttp://en.wikipedia.org/wiki/Memory_protectionhttp://en.wikipedia.org/wiki/Memory_protectionhttp://en.wikipedia.org/wiki/VMS


5/52

hardware the OS is optimized for low-power battery-based devices and for ROM-based systems.

Applications, and the OS, follow an object orientated design.

Later OS iterations diluted this approach in response to market demands, notably the introduction

of a real-time kernel and a platform security model in versions 8 and 9.

There is a strong emphasis on conserving resources, using Symbian-specific programming idioms

such as descriptors and a cleanup stack. There are similar techniques for conserving disk space

(though the disks on Symbian devices are usually flash memory). Furthermore, all Symbian OS

programming is event-based, and the CPU is switched off when applications are not directly

dealing with an event. This is achieved through a programming idiom called active objects.

Similarly the OS approach to threads vs. processes is driven by reducing overheads.

5
http://en.wikipedia.org/wiki/Descriptorhttp://en.wikipedia.org/w/index.php?title=Cleanup_stack&action=edit&redlink=1http://en.wikipedia.org/wiki/Flash_memoryhttp://en.wikipedia.org/wiki/Central_processing_unithttp://en.wikipedia.org/wiki/Active_objectshttp://en.wikipedia.org/wiki/Descriptorhttp://en.wikipedia.org/w/index.php?title=Cleanup_stack&action=edit&redlink=1http://en.wikipedia.org/wiki/Flash_memoryhttp://en.wikipedia.org/wiki/Central_processing_unithttp://en.wikipedia.org/wiki/Active_objects


6/52

1.3 WHY SYMBIAN AMONG OTHER MOBILE OS:

Competition:

Symbian OS is the leading OS in the 'smart mobile device' market. Statistics published February

2007 showed that Symbian OS had a 67% share of the 'smart mobile device' market, with

Microsoft having 13% through Windows CE and Windows Mobile and RIM having 10%.

Other competitors include Palm OS, Linux, Mac OS X, Qualcomm's Brew, and SavaJe.

Symbian OS EKA2 supports sufficiently-fast real-time response that it is possible to build a single-

core phone around it - that is, a phone in which a single processor core executes both the user

applications and the signaling stack. This is a feature which is not available in Linux. This has

allowed Symbian OS EKA2 phones to become smaller, cheaper and more power efficient.

Needs of a different Operating System-SYMBIAN:

The five key points small mobile devices, mass market, intermittent wireless connectivity,

diversity of products and an open platform for independent software developers are the premises

on which Symbian OS was designed and developed. This makes it distinct from any desktop,

workstation or server operating system. This also makes Symbian OS different from embeddedoperating systems, or any of its competitors, which werent designed with all these key points in

mind.

Symbian is committed to open standards and is actively working with emerging standards, such

as J2ME, Bluetooth, MMS, SyncML, IPv6 and WCDMA. As well as its own developer support

organization, books, papers and courses, Symbian delivers a global network of third-party

competency and training centers the Symbian Competence Centers and Symbian Training

Centers. These are specifically directed at enabling other organizations and developers to take part

in this new economy. Symbian has announced and implemented a strategy that will see Symbian

OS running on many advanced open mobile phones. Products in the market show the diversity of

mobile phones that can be created with Symbian OS. Traditional standards such as Unicode for

internationalization, a POSIX API, and Java are a must, but for an operating system to take its

6
http://en.wikipedia.org/wiki/Windows_CEhttp://en.wikipedia.org/wiki/Windows_Mobilehttp://en.wikipedia.org/wiki/RIMhttp://en.wikipedia.org/wiki/Palm_OShttp://en.wikipedia.org/wiki/Linuxhttp://en.wikipedia.org/wiki/Mac_OS_Xhttp://en.wikipedia.org/wiki/Qualcommhttp://en.wikipedia.org/wiki/SavaJehttp://en.wikipedia.org/wiki/Application_softwarehttp://en.wikipedia.org/wiki/Signalling_stackhttp://en.wikipedia.org/wiki/Linuxhttp://en.wikipedia.org/wiki/Windows_CEhttp://en.wikipedia.org/wiki/Windows_Mobilehttp://en.wikipedia.org/wiki/RIMhttp://en.wikipedia.org/wiki/Palm_OShttp://en.wikipedia.org/wiki/Linuxhttp://en.wikipedia.org/wiki/Mac_OS_Xhttp://en.wikipedia.org/wiki/Qualcommhttp://en.wikipedia.org/wiki/SavaJehttp://en.wikipedia.org/wiki/Application_softwarehttp://en.wikipedia.org/wiki/Signalling_stackhttp://en.wikipedia.org/wiki/Linux


7/52

place in the connected world, open standards such as TCP/IP, POP3, IMAP4, SMTP, SMS, MMS,

Bluetooth, OBEX, WAP, i-mode, Java and SyncML should also be supported.

Symbian has trusted leading partners in the mobile phone market and actively participates in

standards organizations (such as the Open Mobile Alliance and the Java Community Process).

Through these, Symbian has advance knowledge of future technologies and can test Symbian OS

with many different phone systems. This ensures the stability and the future place of Symbian OS.

Furthermore, a user interface framework, data service enablers and application engines provide a

solid base for application developers to target. Symbian and its licensees aim to create a mass

market for advanced open mobile phones. To deliver products that satisfy mobile phone users, an

operating system must be engineered to take into account key functional demands of advanced

communications on 2.5G and 3G networks.

To fit into the limited amount of memory a mobile phone may have, the operating system must be

compact. However, as we have seen , it must still provide a rich set of functionality. What is

needed to power a mobile phone is not a mini-operating system but a different operating system

one that is tailored. Symbian is dedicated to mobile phones and Symbian OS has been designed to

meet the sophisticated requirements of the mobile phone market that mini operating systems cant.

They simply run out of steam.

1.4 FEATURES OF SYMBIAN:

Browsing: full web browser support and WAP stack for mobile browsing

Messaging: support MMS, EMS, SMS, POP3, IMAP4, SMTP, MHTML; standard

attachments; fax

Multimedia: shared access to screen, keyboard, fonts and bitmaps; audio recording and

playback, and image related functionality (support common audio and image formats),

including API for graphics acceleration, streaming and direct screen access

Communication protocols: including TCP, IP version 4, IP version 6 and WAP, IrDA,

Bluetooth, USB

Mobile telephony: abstract API for cellular standards.

7


8/52

Data synchronization: over-the-air (OTA) synchronization support using SyncML.

Supported over serial, infrared, Bluetooth and USB links. Provides synchronization : PIM

data, transfer of files, and document conversion to and from non-Symbian OS formats.

Security: full-strength encryption and certificate management, secure communications

protocols (including HTTPS, WTLS and SSL), WIM framework and certificate-based

application installation.

1.5 STRUCTURE:

The Symbian OS System Model contains the following layers, from top to bottom:

UI FrameworkLayer

Application Services Layer

o Java ME

OS Services Layer

o generic OS services

o communications services

o multimedia and graphics services

o connectivity services

Base Services Layer

Kernel Services & Hardware Interface Layer

The Base Services Layer is the lowest level reachable by user-side operations, it includes the File

Server and User Library, the Plug-In Framework which manages all plug-ins, Store, Central

Repository, DBMS, and cryptographic services. It also includes the Text Window Server and the

Text Shell, the two basic services from which a completely functional port can be created without

the need for any higher layer services.

Symbian OS has a microkernel architecture, which means that the minimum necessary is within

the kernel to improve robustness, availability, and responsiveness. It contains a scheduler, memory

management, and device drivers, but other services like networking, telephony, or filesystem

support are placed in the OS Services Layer or Base Services Layer. The inclusion of device

8
http://en.wikipedia.org/wiki/Frameworkhttp://en.wikipedia.org/wiki/DBMShttp://en.wikipedia.org/wiki/Microkernelhttp://en.wikipedia.org/wiki/Scheduling_(computing)http://en.wikipedia.org/wiki/Memory_managementhttp://en.wikipedia.org/wiki/Memory_managementhttp://en.wikipedia.org/wiki/File_systemhttp://en.wikipedia.org/wiki/Frameworkhttp://en.wikipedia.org/wiki/DBMShttp://en.wikipedia.org/wiki/Microkernelhttp://en.wikipedia.org/wiki/Scheduling_(computing)http://en.wikipedia.org/wiki/Memory_managementhttp://en.wikipedia.org/wiki/Memory_managementhttp://en.wikipedia.org/wiki/File_system


9/52

drivers means the kernel is not a true microkernel. The EKA2 real-time kernel has been termed a

nanokernel, containing only the most basic primitives and supporting an extended kernel to

implement any other abstractions.

Symbian OS is designed to emphasize compatibility with other devices, especially removable

media file systems. Early development of EPOC led to adopting FAT as the internal file system

and this remains in the Symbian OS but an object-orientated persistence model has been placed

over the underlying FAT, providing a POSIX-style interface and a streaming model. The internal

data formats rely on using the same API that create the data to run all file manipulations - this has

created the problems of data-dependence and associated difficulties with changes and data

migration.

There is a large networking and communication subsystem, which has three main servers ETEL

(EPOC telephony), ESOCK (EPOC sockets) and C32 (responsible for serial communication). Each

of these has a plug-in scheme. For example ESOCK allows different ".PRT" protocol modules,

implementing different types of networking protocol scheme. The subsystem also contains code

that pertains to short-range communication links too, such as Bluetooth, IrDA and USB.

There is also a large volume of 'User Interface (UI) Code'. For the most part actual user interfaces

are maintained by third parties. However the base classes and substructure are contained within the

Symbian OS. This component is known as UIKON. The Symbian OS also contains the graphics,

text layout, and font rendering libraries.

All Symbian applications are built up from three classes defined by the Application Architecture:

an application class, a document class, and an application user interface class. These classes create

the fundamental application behavior. The remaining required functions, the application view, data

model, and data interface, are created independently and interact solely through their APIs with the

other classes. UIQ and S60 both extend this approach, in two different ways.

There are, of course, many other things that do not yet fit into this model for example, SyncML,

Java MEproviding another set of APIs on top of most of the OS and multimedia. Quite a few of

these are frameworks, and vendors are expected to supply plug-ins to these frameworks from third

parties (for example, Helix playerfor multimedia codecs). This has the advantage that the APIs to

such areas of functionality are the same on many phone models, and that vendors get a lot of

9
http://en.wikipedia.org/wiki/Nanokernelhttp://en.wikipedia.org/wiki/File_Allocation_Tablehttp://en.wikipedia.org/wiki/EPOC_(computing)http://en.wikipedia.org/wiki/Bluetoothhttp://en.wikipedia.org/wiki/IrDAhttp://en.wikipedia.org/wiki/USBhttp://en.wikipedia.org/wiki/SyncMLhttp://en.wikipedia.org/wiki/Java_Platform,_Micro_Editionhttp://en.wikipedia.org/wiki/Multimediahttp://en.wikipedia.org/wiki/Helix_projecthttp://en.wikipedia.org/wiki/Codechttp://en.wikipedia.org/wiki/Nanokernelhttp://en.wikipedia.org/wiki/File_Allocation_Tablehttp://en.wikipedia.org/wiki/EPOC_(computing)http://en.wikipedia.org/wiki/Bluetoothhttp://en.wikipedia.org/wiki/IrDAhttp://en.wikipedia.org/wiki/USBhttp://en.wikipedia.org/wiki/SyncMLhttp://en.wikipedia.org/wiki/Java_Platform,_Micro_Editionhttp://en.wikipedia.org/wiki/Multimediahttp://en.wikipedia.org/wiki/Helix_projecthttp://en.wikipedia.org/wiki/Codec


10/52

flexibility, but means that phone vendors need to do a great deal of integration work to make a

Symbian OS phone.

Symbian OS device manufacturers also get supplied with an example user interface layer called

TechView. This is very similar to the user interface from a Psion Series 5 personal organiser, so

isn't used for any given phone user interface, but provides a basis to start customisation. It is also

the environment in which a lot of Symbian OS test code and example code runs.

1.5 APPLICATION PLATFORMS:

o Series 60 is a UI for mobile phones that are single-handed operated. In addition to voice

communication, multimedia messaging, content browsing and application downloading are

the main features of this platform.

o Series 80 is a UI for devices with larger horizontal screens. It is used in clamshell devices

with a keyboard.

o UIQ is a customizable pen-based user interface platform for media-rich mobile phones

based on Symbian OS.

o Symbian OS is also being used in the new Series 90 platform, which is being introduced in

the Nokia 7700 phone. With a pen input user interface, a horizontal screen and an optional

television tuner, the Nokia 7700 brings mobile multimedia to a new leve

1.6 DEVELOPMENT LANGUAGES:

From the very earliest incarnations, symbian os has beendesigned for mobile

phones and shaped by the specific demands that are placed upon mobile operating systems, from

resilient power-management to careful use of memory resources. as a developer for symbian os,

youwill benefit from a platform which was created specifically for mobile devices and has evolved

with the market, the native programming language for symbian os is a modified version of c++.

Modifications are designed to conserve battery life and memory. for instance, to save battery

10
http://en.wikipedia.org/wiki/Psion_Series_5http://en.wikipedia.org/wiki/Psion_Series_5


11/52

power, all symbian os programming is event based, and the cpu is switched off when applications

are not directly dealing with an event.

Unfortunately, Symbian C++ programming has a steep learning curve, as Symbian requires the use

of special techniques such as descriptors and the cleanup stack. This can make even relatively

simple programs harder to implement than in other environments. Moreover, it is questionable

whether Symbian's techniques e.g. the memory management paradigm are actually so beneficial. It

is possible that the techniques, developed for the much more restricted mobile hardware of the

1990s, do cause unnecessary complexity in source code; programmers are required to concentrate

on bug-prone low-level routines instead of truly application-specific features. It is difficult,

however, to make a move towards a more high-level and modern programming paradigm in

Symbian, because the platform is so tightly bound to semi-obsolete thinking models about mobile

software development

It is also possible to use java, python, .net (using visualbasic and c# with appforges

crossfire),ruby, perl, open programming language (opl) and adobe flash for development, but

J2ME is the most powerful (itallows the greatest access to the functionality of the operating

system) and the fastest.

Java ME applications for Symbian OS are developed using standard techniques and tools such as

the Sun Java Wireless Toolkit (formerly the J2ME Wireless Toolkit). They are packaged as JAR

(and possibly JAD) files. Both CLDC and CDC applications can be created with NetBeans.

Other tools include SuperWaba, which can be used to build Symbian 7.0 and 7.0s programs using

Java.

Here further we will describe Symbians Java technology. We shall look at the evolution of Java

on Symbian OS, updating the story to include additions to the platform in the latest release of

Symbian OS, Version 9.5. We shall then briefly discuss Symbian OS phones and how these relate

to the development of Java on Symbian OS. In the final section we shall consider

Symbians Java strategy and provide a glimpse as to how the Java platform may evolve in the

future.

11
http://en.wikipedia.org/wiki/Java_Platform,_Micro_Editionhttp://en.wikipedia.org/wiki/Sun_Java_Wireless_Toolkithttp://en.wikipedia.org/wiki/J2ME_Wireless_Toolkithttp://en.wikipedia.org/wiki/NetBeanshttp://en.wikipedia.org/wiki/SuperWabahttp://en.wikipedia.org/wiki/Java_Platform,_Micro_Editionhttp://en.wikipedia.org/wiki/Sun_Java_Wireless_Toolkithttp://en.wikipedia.org/wiki/J2ME_Wireless_Toolkithttp://en.wikipedia.org/wiki/NetBeanshttp://en.wikipedia.org/wiki/SuperWaba


12/52

However, first we shall discuss the importance of Java technology from the perspective of

Symbian and its stakeholders.

CHAPTER 2

2.1 Why Java?

In a recent press release Sun Microsystems announced that 250 million mobile phones supporting

Java technology have shipped worldwide. Furthermore, this figure is set to increase. A report from

the ARC Group (Future Mobile Handsets, 2002) predicts that there will be more than 800

12


13/52

million Java capable handsets in 2008. As a consequence, Operators and ISVs will often be more

interested in the hundreds of millions of phones supporting MIDP than in native applications

targeted at a specific OS, particularly for mass-market services and applications that must be

delivered to a range of different mobile phones.

The attractions of Java as a development environment were recognized early on by Symbian,

which made a strategic decision to provide a first-class Java runtime environment to supplement

the native C++ environment. This opened up Symbian OS phones to the 3 million Java developers.

Of course, Java doesnt provide all the answers. The mass-market, cross-platform appeal comes at

a price in terms of performance and functionality compared with native applications. However, the

Java tax is becoming less onerous, and the benefits more compelling, as the gap between Java

and native performance closes and Java functionality is enhanced.

2.2 Evolution of Java on Symbian OS:

Symbians first Java implementation, based on Suns JDK 1.1.4, was released as

part of Symbian OS v5 in 1999.

For their next release Symbian decided to take advantage of the reduced memory footprint offered

by PersonalJava (compared to the burgeoning JDK) and used the PersonalJava 1.1.1 specification

(essentially a subset of the JDK 1.1.6 API set) as the basis for their Java implementation. This

release, Symbian OS Version 6.0, became available in 2000. Symbian OS v6.0 also provided an

implementation of Suns JavaPhone API, a vertical extension to the PersonalJava platform,

providing access to the underlying phone functionality including the ability to:

access telephony functionality

send and receive datagram

manipulate address book and calendar information.

In the meantime Sun was revising the Java strategy. In 1999, acknowledging that one size doesnt

fit all, Sun announced the splitting of Java into three versions:

13


14/52

Java 2 Enterprise Edition (J2EE)

Java 2 Standard Edition (J2SE)

Java 2 Micro Edition (J2ME)

(Java had been re-branded Java 2 with the release of the JDK 1.2).

The Enterprise Edition was aimed at providing end-to-end enterprise solutions focusing on the

server side, while the Standard Edition targeted the desktop environment. The Micro Edition was

targeted at a range of consumer and embedded electronic devices with constrained resources and it

is this we will concentrate on. Since the remit of the Micro Edition covers a wide range of devices

in various market segments, the Micro Edition itself is subdivided into Configurations targeted at

particular hardware configurations. The most appropriate configuration for mobile phones is the

Connected, Limited Device Configuration CLDC, (160-512 KB memory available for Java, battery

powered, slow, possibly intermittent, connection). Sitting on top of the CLDC is the Mobile

Information Device Profile (MIDP) which specifies an API set appropriate for mobile information

devices such as phones.

Soon it was clear that J2ME MIDP was gaining momentum in the wireless space as phone

manufacturers endorsed the idea of a lightweight Java environment suitable for mass-market

phones. Symbian recognised the strength of the MIDP movement by including J2ME MIDP 1.0 as

its standard Java offering in Version 7.0 of Symbian OS, released in 2002, as well as back-porting

it to earlier versions. However, it was also recognised that the MIDP 1.0 specification severely

limited the scope of MIDlets. As a consequence the richer, but larger memory footprint

PersonalJava/JavaPhone was retained as an option available to licensees. (For a discussion of the

differences between the PersonalJava/JavaPhone and J2ME MIDP development environments .J2ME has progressed a long way since its first conception in 1999. Although MIDP 1.0 generated

considerable enthusiasm amongst the Wireless Java Community, it was realised that MIDP 1.0 on

its own provided limited access, and so limited capabilities, to the functionality of the typical

smartphone from within a MIDlet. Consequently, soon after the release of MIDP 1.0 the wireless

community started working on enhancing the capabilities of MIDP. This has been manifested in

14


15/52

the MIDP 2.0 Java Specification Request (JSR 118), released in its final form in November 2002

and a range of extension API JSRs, all forming part of the Java Community Process. These

optional packages increase the functionality available to MIDlets.

In 2003 Symbian released Version 7.0s of Symbian OS. This introduced support for J2ME MIDP

2.0, which brings a new, finer-grained security model, enhanced UI API, Game and audio APIs

and the Push Registry to the Java platform. In addition, Symbian OS v7.0s provides an

implementation of the Java API for Bluetooth Wireless Technology (JABWT, JSR82), giving

MIDlets access to the Bluetooth stack and the Wireless Messaging API (WMA, JSR 120),

allowing MIDlets to send and receive SMS messages. To ensure Best in Class performance

Version 7.0s also makes use of Suns high performance CLDC HI VM.

Nokia has used Symbian OS v7.0s for Version 2.0 of their Series 60 Developer Platform. In

addition to the functionality that comes as standard in Version 7.0s (see above), the Series 60

Developer Platform 2.0 also provides an implementation of the Mobile Media API (MMA, JSR

135) providing Java support for video playback, tone generation and photo capture, supplementing

the audio API that comes as part of MIDP 2.0.

The latest version of Symbian OS, Version 8.0, was publicly announced in Q1 2004. This

enhances the J2ME CLDC/MIDP implementation adding the following optional packages to

Symbian OS: Mobile Media API (JSR 125), Mobile 3D Graphics (JSR 184), File GCF (part of JSR

75) all running on top of Suns CLDC HI 1.1 Virtual Machine (VM). In addition, the Java

implementation is now fully compliant with the Java Technology for the Wireless Industry

specification (JTWI, JSR 185). The JTWI is an initiative defined via the JCP to specify a minimum

set of APIs and behaviour that a compliant phone should support. By targeting the JTWI, ISVs and

3rd party developers can know that their applications will run on the largest possible number of

phones. Release 1 of the specification mandates MIDP 2.0, CLDC 1.0 and WMA as a minimum

API set with the MMA also required if multimedia functionality is exposed to Java. Symbian OSv8.0 also integrates support for the Universal Emulator Interface

(UEI) allowing Symbian MIDP emulators to fully integrate with standard tools such as Suns

Wireless Toolkit and IDEs such as JBuilder and Sun One Studio.

15


16/52

2.3 SYMBIAN AND JAVA THE NEXT STEPS:

Symbians Java strategy is enabling the emerging market for advanced consumer services. Future

releases of Symbian OS will implement Java APIs for location, web services, PIM, Bluetooth

push, security and trust and other technologies that will allow developers to create and run larger,

more interesting, games, applications and services. Additionally, Symbian is also represented on

the majority of the expert groups of J2ME JSRs.

Symbian believes that, for the foreseeable future, CLDC provides the right Java technology base

for mass market requirements, consumer in particular. However, in the short term Enterprise

clients need the additional features and functionality available in CDC/Personal Profile and

therefore an implementation is available for Symbian OS for those handset manufacturers thatrequire it. For instance, the recently announced Nokia 9500 not only supports Symbians CLDC

based implementation (including MIDP 2.0, WMA, MMA and JABWT) but also includes IBMs

J9 CDC-based Java implementation providing support for the Personal Profile.

16


17/52

Figure 4 Symbian OS Java performance

Java performance (per MHz) has steadily improved (see Figure 4), due to technologies such as

dynamic adaptive compilation and hardware acceleration of byte code interpreters, and to

optimisations in graphics, native interface, and embedded performance. At the same time clock

rates are increasing. Thus, future v8.0 based mobile phones are likely to deliver around 40 times

the performance of the original Symbian OS v5 JDK1.1 implementation (this is using Symbian's

CLDC benchmark, a more realistic indicator than the embedded Caffeine benchmark). Such a level

of performance means we can run complex advanced data services, that go beyond simple "screen

scraping" applications and wireless services. These advanced services will make use of local

17


18/52

resources for storage, processing, and communication (e.g. Bluetooth), only synchronizing with

other clients and back end data sources as and when needed.

2.4 INTRODUCTION TO JAVA DEVELOPMENT ON THE SYMBIAN

PLATFORM:

GETTING STARTED:

The two tools essential for developing Java for the Symbian platform are a Symbian platform Java

SDK and a Java development environment for Java 1.1.x.

Symbian Platform SDKs

Each of the DFRDs has its own Java SDK, however at the time of writing only the Crystal andQuartz java SDK are available.

The Quartz SDK can be obtained by registering on the Symbian Developer Networkweb site after

which it is available for downloading

Symbian have not yet released a generic SDK for the Crystal DFRD, however Nokia have made

available a version targeted to their recently launched 9210 communicator. The SDK is available to

approved developers by applying on the Forum Nokia and is posted out on CD.

Each SDK contains an emulator for its DFRD. This is accompanied by full documentation, some

example programs and the utilities for creating program icons, the files required to run the

application, help and installation files.

To run any of the SDKs Symbian recommended the following minimum specification PC:

400 Mhz Pentium processor,

128Mb RAM, 500 MB of free disk space, and

Windows NT 4 (although Windows 98 can be used).

In addition, to view the on-line documentation a Web browser supporting frames is required and

18
http://www.symbiandevnet.com/http://forum.nokia.com/http://www.symbiandevnet.com/http://forum.nokia.com/


19/52

for browsing the HTMLHelp file Microsoft Internet Explorer version 4 or higher is needed.

Registering on the Symbian Developer Network also gives access to a number of other useful

resources, including a Java knowledgebase, white papers, additional examples and utilities. The

Nokia Forum contains both complementary and additional information, including style guides for

9210 development, FAQs and a discussion forum.

Java SDK

A Java development tool supporting up to Java 1.1.8 can be obtained from SUN or any commercial

Java ADE supporting PersonalJava can be used.

2.5 SYMBIAN PLATFORM JAVA FUNDAMENTALS:

The Symbian platform differs in some significant ways from the environments

most Java developers will be familiar with. Before we look at a simple example application for

Quartz and the Java development process we will briefly review these differences and the

challenges presented to the Java developer in building for the Symbian platform.

Symbian Platform Environment:

There are two features that most developers would assume exist, but are not presenton the Symbian platform. These features are:

environment variables defining Classpath, and

default definition of the working directory.

Classpath:

Unlike other systems on which Java is deployed the Symbian platform does not have the concept

of environment variables that define the Classpath. The standard, shared and extension

classes are therefore given fixed locations:

19


20/52

on a Symbian platform device in ?:\system\java\lib\classes.zip for the standard

classes, ?:\system\java\classes\ for shared classes and ?:\system\java\ext\ for extension

classes,

on the emulator ?:\lib\, ?:\Classes and ?:\ext\ for standard, shared and extension classes

respectively. Within the standard emulator set-up these are on the mapped J drive.

When an application is run, in addition to searching these fixed locations, the directory containing

the application is also searched for classes.

Classes can be store on any physical drive present on a device. When searching for classes the

following order of precedence is used, d: (any Compact Flash card), a:, b:, c: (the internal RAM

drive), e: then in alphabetical order through to z: (the internal ROM drive). The classes found on

the highest priority drive are the ones used. Therefore, on a device without a CF card, any classes

loaded in RAM (C drive) are used in preference to those on ROM (Z Drive).

It is however possible to override the defaults in two ways, by using the command line parameters:

-classpath, to override (and replace) the default classpath, or

-cp, to add specified directories to the beginning of the default classpath.

Current Directory:

The Symbian platform does not implement the concept of a current directory as many other

operating systems do. Therefore when a Java application is launched to the emulator from the DOS

command line there is no current directory to inherit. Rather the current directory has to be

specified with the -cd parameter when the application is launched.

Normally however an application is run from the platform's interface. When this is done the

current directory is set to the location of the application, which on the emulator

20


21/52

is ?:\Symbian\v6.0\emulator name\epoc32\wins\c\system\apps\appname\

and ?:\system\apps\appname\ on an actual device.

Java and the DFRDs:

Before starting a Java development the first decision which needs to be made is which DFRD or

DFRDs the application will be for. Not only do the unique features of the DFRD need to be

considered but thought also should be given to the target market for that device. In addition,

devices in a family may also have ergonomic differences which effect application design and

targeting, as in the Crystal DFRD that allows for both touch screen and keyboard navigation.

For example, you may want to develop a vector graphic package. You might decide to only

develop it for Crystal devices for the following reasons:

it has no practical use to users of a Pearl smartphone and the smaller screen on some

devices would make its use impractical,

the users of Quartz devices are most interested in personal and web information and

unlikely to have sufficient interest in the product.

Symbian Java Extensions:

Symbian provide several additional classes to assist with creating applications which conform to

the style guides for each DFRD. In Quartz these are AboutDialog, GridPanel and QFrame. Similar

classes exist for Crystal.

QFrame is an extension of the standard awt Frame to provide Quartz look and feel by:

placing a frame between the toolbar and status bar,

adding the default menus, and

creating a number of views using standard awt CardLayout.

21


22/52

GridPanel is an extension of the standard awt Panel to provide relative positioning of items within

a panel.

AboutDialog is used to create a simple dialog to display information about an application from the

application's menu.

2.6 JAVA DEVELOPMENT PROCESS ON SYMBIAN OS:

The process of developing a Java application and making it available on a Symbian

platform device differs greatly from the processes used on the familiar desktop environments. In

this section we will look at this process, using the example application.

The process of developing an application for the Symbian platform has three main steps:

developing the Java code and supporting files, sound graphics etc. which culminates in

testing on the emulator,

creating the files to deploy the application to the Symbian interface using AIF Builder so it

has an icon and can be run from native interface, and

packaging all the application elements in a release file.

Other activities which may be undertaken as part of a Java development, which we do not discuss

in more detail here are:

development of context sensitive help,

font development, and

creation of resource files for multi-lingual installs.

22


23/52

fig.5 J2ME File development proesss

Java Development

Development of a Symbian platform application in Java commences with the standard Java

development path, creating the appropriate class files and packaging them into JARS. In doing so

23


24/52

the Symbian classes need to be used, this is achieved by adding the following items using

-classpath when running javac:

c:\Symbian\6.0\QuartzJava\erj\lib\classes.zip,

c:\Symbian\6.0\QuartzJava\erj\ext\javaphone.jar,

c:\Symbian\6.0\QuartzJava\erj\ext\qawt.jar.

Once this has been done the application can be tested by running it in the emulator. In the case of

the sample application this is done, in DOS, with the following command:

C:\Symbian\6.0\QuartzJava\epoc32\release\wins\udeb\pjava_g.exe -cd j:\examples\QJava

-cp QJava.jar -D#com.symbian.appName="The Java Example"

com.symbian.devnet.quartz.qjava.QJava sleep

The parameters passed to the JVM are:

-cd which sets the current folder to the application folder,

-cp which adds the JAR to the classpath and,

the package method to be run.

You will see that the application has been passed the parameter "sleep", this causes the application

to sleep for 20 seconds before starting. This is needed for all applications run in the emulator from

DOS because the emulator takes time to load. The sleep ensures the emulator is fully loaded before

the application is started.

Two further things are worth noting here:

if the application produces output to the Console this will be seen in the DOS window, and

when the application is exited the emulator also closes.

Obviously running an application from the DOS prompt is somewhat laborious. The main reason

24


25/52

that an application would be run in this way is to use the standard Java debug tool through pjava_g.

It is a lot more convenient, when not debugging, to run the application from the native interface.

Deploying to the Symbian Interface

Prior to the release of v6.0 of the Symbian platform generating the files to deploy a Java

application to the native interface involved the use of DOS commands, text and bitmap source

files. With v6.0 these tools have been packaged into a single visual tool called AIF Builder that

also includes an IconEditor.

Using AIF Builder we create:

an Application Information File which defines the application, its caption and icon file,

a text file defining the applications additional classpath,

a mbm (Symbian's proprietary multiple bit map format) file for the application Icons.

Starting AIF Builder

In a normal install AIF Builder is found under Development Tools in the Symbian 6.0 SDKs start

item.

AIF Builder - Application Tab

On opening AIF Builder the usual options to create a new file or open an existing one are available

from the menu.

25


26/52

If a new file is being created, as for the QJava application, then the first thing that needs to be done

is complete the application details.

By default C++ is selected as the language. If Java is selected an additional field for the Command

Line Text is displayed.

Now the following details are entered:

the Application name, which should be the name given to the program file, in this case

QJava,

the Application UID, which is 01010102 for this example application.

the Java Command Line Text, which is "-cd j:\examples\QJava -cp QJava.jar

-D#com.symbian.appName="The Java Example" com.symbian.devnet.quartz.qjava.QJava"

in this case and this is the same as the -cp command used when running from DOS.

26


27/52

AIF Builder - DFRDs

Having defined the application details, the next step is to provide information for each of the

DFRDs the application is to be implemented on, in the DFRDs tab.

The upper pane allows the target DFRDs to be selected. For the QJava application this is Quartz

only. Having selected the DFRD the file location details are completed in the Quartz tab in the

lower "Customise Icon" pane, as follows:

mbm file location, this would normally be left blank for a new item and the AIF Icon

Editor used to create a new set of icons. Obviously if you have an existing mbm you can

enter the file location here. (However the new DFRDs use icon sizes that differ from those

used in Epoc R5 and these icons are not imported into the Icon Editor from an existing

mbm file.)

the location to generate the file to. The final target folder is

c:\Symbian\6.0\QuartzJava\Epoc32\Wins\c\system\apps\appname. The files can be

generated directly into this folder or the folder containing the application (and subsequently

copied over, with the JAR file, to the target directory).

27


28/52

a temporary location to store intermediary files. By default, if no directory is entered, this is

set to appname\IntermediteFiles. An alternative, as the intermediate files are not required

for application deployment, could be to use a single folder for all these files allowing them

to be periodically deleted.

One word of warning, the tabs in the "Customise Icon" pane do not reflect the selected DFRDs,

e.g. if you select only Quartz the Crystal tab is still active, so some care needs to be taken to ensure

details are entered in the right place.

AIF Builder Capabilities

This tab is not shown for Java (but you will notice it before selecting Java as the language). For C+

+ and OPL applications it allows definition of:

whether the application can be embedded (this only applies to C++ applications),

whether the user can create new files,

whether the display of the icon on the Extras bar is disabled,

a list of MIME file types (e.g. non Symbian files without a UID) that the application can

handle.

AIF Icon Designer

The Icon Designer is accessed from the Action menu in AIF Builder.

or from the Edit or Create buttons at the bottom of the Customise Icon frame:

28


29/52

If a mbm file was not identified in the DFRDs tab, then selecting Create mbm allows a new set of

icons to be designed. Edit mbm allows an existing set of Icons to be updated, the file edited is

dependant on the current DFRD tab in the DFRD window, e.g. if the Quartz tab is selected the

Quartz mbm is opened to edit.

The Icon Editor screen displays two bitmaps for each icon, the left hand bitmap is for the icon and

the right hand for the mask (where clear bits are transparent and black are opaque in the displayed

icon).

29


30/52

The drawing color is selected from the color map at the bottom of the screen or picked up from the

icon using the button.

Effectively you can draw in either pane as changes are mirrored across to the complementary pane,

however it is more natural to draw the icon in the left most pane. The crossed bits in the icon pane

represent transparent bits, to make them opaque it is necessary to draw in white. Using the

button all bits of a selected color can be turned transparent.

For Quartz only the 2016 icon is needed (and when displayed is placed in a circle on the Quartz

screen). If the 3232 icon is defined it is used without modification. The icon sizes to be used can

be selected in the right most pane.

When the editing of the icon is complete it should be saved. The save name of the file is carried

back to the mbm file location in the DFRD details tab of the AIF Builder.

Generating the Application Files

Having created all the necessary information the Generate button in the bottom right hand corner

of the AIF Builder Window creates the necessary files.

When generation is complete the files created are confirmed.

30


31/52

Saving the AIF Builder File

Finally the AIF Builder details can be saved for future amendment.

Deploying The Application

The QJava application and the file generated by AIF Builder were all stored in the

C:\Symbian\6.0\QuartzJava\erj\examples\QJava directory. Applications are deployed on a

Symbian device to the ?:\systems\apps\appname directory which in the emulator for QJava is

C:\Symbian\6.0\QuartzJava\Epoc32\Wins\c\system\apps\QJava. To effectively deploy the QJava

application the aif, app, jar and txt files are copied from examples to apps.

Running The Application

With the application "installed" on the emulator it can now be run from the Quartz interface. On

starting the emulator a new icon for the "Java Example" is displayed.

A single tap on the icon launches the application.

Application Installation Package

While copying the files to the correct directory on a device can be employed as a means to deploy

the application it is not to be recommended. The Symbian platform employs a proprietary

installation method which uses a sis file. The sis file can then be loaded from a PC in one step

through Symbian Connect, in Crystal devices it can also be copied or emailed to and loaded on the

device.

31


32/52

Thesis file is created using a command file processed by the makesis utility, which is run in the

DOS window, a single file containing all the elements of the application, Java code, supporting

sound and image files, app, aif and command files, is built to provide the user with a single simple

mechanism for installing an application.

Thesis file allows for a high level of control over the install (creation of directories, copying of

files, display of license and other details) and de-install process. Thesis file in this example has

been kept quite straightforward, it displays a Yes/No dialog and then installs the application. The

following command file was used:

; comment line

; Basic Application definition, name, UID, major, minor and variant release numbers

#{"Quartz Java Example"},(0x01010102),1,0,0

; Language Independent Files

; Text file displayed with Yes No dialog

"qjavainstall.txt"-"!:\system\apps\qjava\qjavainstall.txt",FT,TS

; Application files

"qjava.jar"-"!:\system\apps\qjava\qjava.jar"

"qjava.txt"-"!:\system\apps\qjava\qjava.txt"

"qjava.app"-"!:\system\apps\qjava\qjava.app"

"qjava.aif"-"!:\system\apps\qjava\qjava.aif"

The installation file also supports the following features which we are not using here:

definition of languages supported,

language dependant files,

definition of files to be deleted when removing the application which were not in the install

list, e.g. file created by running the application,

dialog box with a 'Continue' button or 'Yes/No', where 'No' skips the next file to be

installed,

32


33/52

executable files to be run on install, removal or both,

requisite components, and

other sis files.

The sis file is then built with the following command:

C:\Symbian\6.0\QuartzJava\erj\examples\QJava\>makesis qjava.pkg

Processing qjava.pkg...

Created qjava.sis

C:\Symbian\6.0\QuartzJava\erj\examples\QJava\>

The sis file can now be tested, however unlike Pearl and Crystal which include the facility to

install sis files directly on a device, Quartz can only load applications through Symbian Connect.

Obviously this means that you would not be able to test a sis file on the emulator. To overcome

this obvious deficiency for the developer Symbian have made a sis file loader available. This can

be downloaded from the Symbian Platform v6.0 Product Support page on the Symbian Developer

Network site. Once unzipped this provides a new option within the Quartz Control Panel called

"Install a .SIS file".

To test the sis file it has to first be copied to one of the emulators drives. The default location used

by the installer is the c:\ root directory (C:\Symbian\6.0\QuartzJava\Epoc32\Wins\c). Once the file

has been copied the install process can be run.

First a dialog that allows the sis file to be selected is displayed.

33
http://www.symbiandevnet.com/downloads/sdks/v6sdks.htmhttp://www.symbiandevnet.com/downloads/sdks/v6sdks.htm


34/52

Once the file to load is selected a check is made on whether it has been digitally signed, as our

example has not been a warning is issued:

Having accepted that the source is safe a dialog to confirm the installation is displayed:

After which the text file included in our sis file is displayed:

34


35/52

If "Yes" is chosen from the custom message the application is now loaded. If the load takes sometime a progress screen is displayed. When the load is complete a confirmation dialog is displayed:

While "Install a .SIS file" allows the sis file to be tested in the emulator it does not include the

ability to de-install the application, for which there may be instructions in the sis file.

Also not having a de-install means that retesting the SIS file overwrites the existing install, the

installer issues a warning message if this is about to be done. Obviously this is not ideal, but can be

partially overcome by manually deleting the application. This involves:

removing the application directory from c:\system\apps in the emulator,

removing the install.log and appname.sis file from the c:\system\install directory in the

emulator (as the install.log file contains details of all installed files deleting it to remove

one install could effect other installed applications), and

removing any other files copied to other locations or created by the application.

35


36/52

Conclusion

We have now seen how a Java application is:

developed and then tested in the emulator,

deployed to the native Symbian interface, and

packaged for distribution.

Hopefully we have been able to show you that, while this process is different from the one which

would be used for a PC development, it is relatively straight forward activity.

2.7 ADVANTAGES OF SYMBIAN J2ME :

Unlike other operating systems, Symbian has a very rich Java environment, meaning more

capabilities than on most feature phones. Furthermore, as already mentioned, the Java ME

implementation shipped with Symbian OS is best-of-breed, so MIDlets will generally execute at

quite acceptable speeds on current smartphones.

Symbian OS still holds the following advantages compared to feature phones when it comes to the

management of Java ME applications:

o Robustness: process separation is there for a reason; without it, if a game MIDlet triggers a

native bug in the implementation of a JSR library, it can take out the VM and require it to be

restarted. On a feature phone this will cause all running MIDlets to die without notification,

potentially losing user data. On Symbian OS, MIDlets are fully protected from one another.

o Platform integration: S60 and UIQ are already full multitasking environments with

facilities for managing an arbitrary number of running processes. On Symbian OS, a user does not

have to learn anything new to manage MIDlet multitasking; MIDlets are handled in exactly the

same way as native applications. On feature phones, MIDlet multitasking often doesn't sit well

36


37/52

with the native UI. Instead it is common for there to be a separate "Java" application with its own

task management UI.

o No arbitrary limitations: feature phones typically have to divide up the memory assigned

to various features at device creation time, and the memory assigned to Java is fixed. On Symbian

OS, because MIDlets are process-based and managed like native applications, they co-operate with

the system-wide memory management policy. This allows complex and resource-intensive

MIDlets to be run on Symbian OS using the full capabilities of the device without hitting

artificially imposed limits.

o Future proofing: although feature phones can now just about handle CLDC/MIDP

applications via enhanced VMs, they still cannot handle CDC-based Java platforms like the

forthcoming JSR 249: Mobile Service Architecture Advanced and JSR 232: Mobile Operational

Management, and there is little prospect of them ever doing so. In contrast, CDC/Foundation is

already shipping on a number of Symbian phones.

o Architecture: on Symbian OS, Java ME applications are treated as first-class citizens.

MIDlets completely integrate into APPARC and the view server, so switching between MIDlets

and native applications is identical.

o Fragmentation: as already discussed, the available set of JSRs is well defined and highly

optimised. This largely alleviates fragmentation problems that plague other platforms.

2.8 DISADVANTAGES OF SYMBIAN J2ME :

J2ME disadvantages include lack of network security infrastructure; no support for generating

revenues (most users prefer to try an application before making a purchasing decision); lack of

functionality in current J2ME implementations; no optimization for download.

37


38/52

Fig. 6 J2ME Vs. native Symbian C++

J2ME GLOSSARY :

o CDC Connected Device Configuration

Defines a Java runtime environment for high end consumer devices with constrained

hardware resources such as set top boxes, PDAs and Communicators. Falls under the J2ME

umbrella.

o CLDC Connected, Limited Device Configuration Defines a Java runtime environment

for low end devices with highly constrained hardware resources such as mobile phones andpagers. Falls under the J2ME umbrella.

o ISV Independent Software Vendor

o JABWT Java API for Bluetooth Wireless Technology

38


39/52

An optional API that allows J2ME applications to access Bluetooth functionality.

o JCP Java Community Process

An open organisation of Java developers and licensees whose charter is to develop and revise

Java technology specifications, reference implementations, and technology compatibility kits.

o JSR Java Specification Request

The process by which new Java specifications are defined. Part of the Java Community

Process.

o JTWI Java Technology for the Wireless Industry

An initiative to provide:

A roadmap of mobile phone related JSRs, indicating their availability in different

markets around the world .

A specification describing the essential client components of an end-to-end wireless

environment.

Provides a Reference Implementation of the technology and a Technology

Compatibility Kit.

o J2ME Java 2 Micro Edition

A version of Java aimed at consumer and embedded devices including cell phones.

o MIDlet

An application written for the Mobile Information device profile (MIDP).

39


40/52

o MIDP mobile Information Device Profile

Vertical extension of CLDC. Defines an API set for Mobile information devices such as cell

phones.

o MMA Mobile Media API

An optional API providing a high level interface to sound and multimedia capabilities.

o UEI Universal Emulator Interface

Interface enabling integration of emulators with tools such as the Wireless Toolkit.

o

WMA Wireless Messaging API

An optional API providing access to wireless messaging resources including SMS.

40


41/52

CHAPTER 3

3.1 SYMBIAN SECURITY THREATS:

Security and malware

Symbian OS has been subject to a variety of viruses, the best known of which is Cabir. Usually

these send themselves from phone to phone by Bluetooth. So far, none have taken advantage of

any flaws in Symbian OS instead, they have all asked the user whether they would like to install

the software, with somewhat prominent warnings that it can't be trusted.

However, of course, the average mobile phone user shouldn't have to worry about such things, so

Symbian OS 9.x has adopted a capability model. Installed software will theoretically be unable to

do damaging things (such as costing the user money by sending network data) without being

digitally signed thus making it traceable. Commercial developers who can afford the cost can

apply to have their software signed via the Symbian Signed program. Currently, developers also

have the option of self-signing their programs. However, the set of available features is smaller,

and certain operators have opted on fully disabling certificates other than the Symbian Signed

certificates.

Some other hostile programs are listed below, but all of them still require the input of the user to

run.

Drever. A is a malicious SIS file trojan that attempts to disable the automatic startup from

Simworks and Kaspersky Symbian Anti-Virus applications.

Locknut. B is a malicious SIS file trojan that pretends to be patch for Symbian S60 mobile

phones. When installed, it drops a binary that will crash a critical system service

component. This will prevent any application from being launched in the phone.

Mabir. A is basically Cabir with added MMS functionality. The two are written by the

same author, and the code shares many similarities. It spreads using Bluetooth via the same

routine as early variants of Cabir. As Mabir. A activates it will search for the first phone it

finds, and starts sending copies of itself to that phone.

41
http://en.wikipedia.org/wiki/Caribe_(computer_worm)http://en.wikipedia.org/wiki/Capability-based_securityhttp://www.symbiansigned.com/http://en.wikipedia.org/wiki/Caribe_(computer_worm)http://en.wikipedia.org/wiki/Bluetoothhttp://en.wikipedia.org/wiki/Caribe_(computer_worm)http://en.wikipedia.org/wiki/Capability-based_securityhttp://www.symbiansigned.com/http://en.wikipedia.org/wiki/Caribe_(computer_worm)http://en.wikipedia.org/wiki/Bluetooth


42/52

Fontal. A is an SIS file trojan that installs a corrupted file which causes the phone to fail at

reboot. If the user tries to reboot the infected phone, it will be permanently stuck on the

reboot, and cannot be used without disinfection that is, the use of the reformat key

combination which causes the phone to lose all data. Being a trojan, Frontal. A cannot

spread by itself the most likely way for the user to get infected would be to acquire the

file from untrusted sources, and then install it to the phone, inadvertently or otherwise.

3.2 SYMBIAN VS 9.5 - LATEST UPDATES:

Introducing Symbian OS v9.5

The global smartphone market has never been so exciting. With over 110 million Symbian

smartphones shipped, high smartphone growth in developing markets, and increasing mass market

requirements, Symbians addressable market is broadening across segments and regions.

Symbian OS v9.5, the latest evolution of Symbian OS, delivers over 70 new features for high-

performance, more powerful smartphones at mass market costs: a truly scalable operating system

for the global market.

Technical specifications

Open Environments:

Standard C environment

Standard libraries including partial POSIX support (P.I.P.S)

Location-Based Services:

GPS, A-GPS (terminal-assisted / terminal- based) and network-based positioning

Mobile originated and mobile terminated requests (including emergency requests

Java:

CLDC HI 1.1.1s (JSR139)

42


43/52

Bluetooth (JSR082) including OBEX

Content Handler (JSR211)

JTWI (JSR185)

MIDP 2.0 (JSR118)

Mobile 3D Graphics (JSR184)

Mobile Media 1.1 (JSR 135)

PIM & FileGCF (JSR075)

Wireless Messaging 1.1 (JSR120) including CBS

Support for JSR248

PC Connectivity:

MTP over USB

Mobile Active Sync

Calendar and contacts sync framework

Persistent Data Services:

Embedded SQL database

Generic OS Services:

Extensive language support including: Thai, Arabic, Hebrew, Japanese, Chinese, Hindi, Brahmic

and Vietnamese scripts

Unicode 3.0

Kernel & Hardware Services:

ARMv5, v6 and v7 support

L2 cache support

Defragmentation of physical RAM

Demand paging of read-only code and data

Hardware-dependent support for VFP floating point acceleration and accelerated maths

functions

High performance file server with FAT filesystem support

MMC and SD card support including media >2GB

43


44/52

Security Management:

Cryptographic services

Certificate management (X509 certificates)

Secure Software Install

MIDP 2.0 support

Application Protocols:

Multimedia Transfer Protocol (MTP) over USB plus data provider for files

and folders

White/black list URI service

SIP/SDP

System GUI Frameworks:

Flexible application and UI frameworks

Control and windowing environments

CONCLUSION

44


45/52

This report has compared some of the factors to consider when choosing which of the two main

technologies C++ or JavaME to choose for developing an application for Symbian

smartphones. As we described, Symbian C++ is a more expensive skill set than Java ME, and

ultimately the development costs alone may be the deciding factor when choosing which

technology to use. It is quite possible to decide that it is preferable to have a Java ME version of a

given application that only runs at, say, 75% of the speed of the equivalent native one, but has less

than half of the development costs because of the reduced development cycle.

If you then take into account that most Java ME applications that run on Symbian OS will most

likely also run largely unchanged on Nokias Series 40 feature phones too, then the potential return

on investment for a given development project may very well overshadow the more esoteric

technical hurdles when viewed from a marketing and budget standpoint. Java ME applications will

reach a much wider audience than native applications can by their very nature. Even if you are

only targeting Symbian OS phones, there are often valid reasons to use Java ME for development.

Conversely, there are many reasons to prefer native development over Java ME on Symbian OS,

especially for applications where performance is crucial (for example, 3D console-level games) or

where the application use cases require low level access to the rich set of operating system services

exposed by Symbian OS, such as the messaging sub-system, the DBMS, image manipulation and

conversion, direct screen access, event logs, call interception and management and much more.

As a real world example, Google Maps is available as a native C++ application for Symbian OS v9

(S60 3rd Edition smartphones only) which noticeably outperforms the more generic Java ME

version. As is usually the case, this is largely due to Javas memory footprint which directly affects

memory intensive operations such as panning and zooming images. Furthermore, the native

application allows routes and favourite maps to be saved locally, has better integration with the

GPS radio and faster access into the address book.

It is also interesting to note that, as mentioned earlier, the faster start-up time of the nativeapplication had the greatest impact on user satisfaction.

Symbian C++ and Java ME complement each other as mature, robust and commercially viable

development platforms and we have discussed a number of valid economic reasons for using either

technology in the marketplace of the real world.

45


46/52

There are many reasons to take either path but the choice you eventually make must necessarily

depend on what you are trying to achieve.

J2ME (especially MIDP profile) has a lot of support in the telecommunications industry - Motorola

and Nokia in particular are devoting a lot of development effort to supporting MIDP in a wide

range of their devices.

REFERENCES

Internet References and Symbian Resources:-

http://en.wikipedia.org/wiki/Symbian_OS

46
http://en.wikipedia.org/wiki/Symbian_OShttp://en.wikipedia.org/wiki/Symbian_OS


47/52

http://www.symbian.com/

http://www.symbian.com/developer/sdks/sdks_series60.asp

http://www.symbian.com/developer/sdks/sdks_series60.asp

http://www.symbian.com/developer

http://forum.nokia.com/

http://www.newlc.com/

http://www.uiq.com/dev

Reference Books: Symbian Press

47
http://www.symbian.com/http://www.symbian.com/developer/sdks/sdks_series60.asphttp://www.symbian.com/developer/sdks/sdks_series60.asphttp://www.symbian.com/developerhttp://forum.nokia.com/http://www.newlc.com/http://www.uiq.com/devhttp://www.symbian.com/http://www.symbian.com/developer/sdks/sdks_series60.asphttp://www.symbian.com/developer/sdks/sdks_series60.asphttp://www.symbian.com/developerhttp://forum.nokia.com/http://www.newlc.com/http://www.uiq.com/dev


48/52

48


49/52

49


50/52

50


51/52

51


52/52

seminar symbian

Documents