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, the Nokia 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

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 added EDGE support and IPv6. 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 Cabir and 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

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 reasonable binary 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 13 September 2006, Nokia released a small program to fix this defect. Support for Bluetooth 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

Released on 12 July 2006. Upgrades include improved memory management and native support for Wifi 802.11, HSDPA, Vietnamese language support. The Nokia 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

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.

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 singlecore 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 embedded operating 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

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.

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 Framework Layer Application Services Layer

o

Java ME generic OS services communications services multimedia and graphics services connectivity services

OS Services Layer
o o o o

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

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 ME providing 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 player for 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

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.

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

UIQ is a customizable pen-based user interface platform for media-rich mobile phones based on Symbian OS.

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 been designed 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

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

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

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

 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

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 OS v8.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

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 that require 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

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

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 and Quartz java SDK are available. The Quartz SDK can be obtained by registering on the Symbian Developer Network web 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

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 present on 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

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

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

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

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

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

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

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

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 The files

folder can

is be

c:\Symbian\6.0\QuartzJava\Epoc32\Wins\c\system\apps\appname. copied over, with the JAR file, to the target directory).

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

27

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

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

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

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

The sis 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. The sis 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. The sis 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:

; #{"Quartz ; ; ; Text Language file Java

comment

line Example"},(0x01010102),1,0,0 Independent Files No dialog files with Yes

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

displayed Application

"qjavainstall.txt"-"!:\system\apps\qjava\qjavainstall.txt",FT,TS "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

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 Processing Created C:\Symbian\6.0\QuartzJava\erj\examples\QJava\>

qjava.pkg qjava.pkg... qjava.sis

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

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

If "Yes" is chosen from the custom message the application is now loaded. If the load takes some time 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

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

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

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 and pagers. Falls under the J2ME umbrella. o ISV Independent Software Vendor o JABWT Java API for Bluetooth Wireless Technology
38

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

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

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

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 highperformance, 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

 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

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

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 native application 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

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://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

48

49

50

51

52