Series 60 Platform Versions

Series 60 1.x is based on Symbian OS 6.1 (with some Nokia modifications), whereas Series 60 2.x is based on Symbian OS 7.0s. Some features in Series 60 2.x come from enhancements to Symbian OS and others come from Series 60 Platform enhancements ”the origins of the changes are summarized below.

Symbian OS version 6.1 and 7.0s differences

• On-board camera API

• Multi Media Framework replaces Multimedia Server

• Multiple PDP contexts (3+1 primary)

• HTTP transport framework: HTTP 1.0 and 1.1 client stack

• Language support: Arabic and Hebrew text rendering

• ECom plug-in architecture

• Dual-mode IPv4/v6 Stack

• Multimode ETEL ”(GSM, CDMA, and so on)

• W-CDMA 3GPP R99/R4-support

• Java ^TM : MIDP 2.0 (supports JSR 118 Security)

Series 60 1.x and 2.x Differences

The changes in Series 60 from 1.x to 2.x are summarized here. Many of the platform and Operating System changes will have no effect on developers, but others will ”compatibility issues are discussed next .

• Combined Application Manager for both native Symbian applications ( .sis ) and MIDlet installations

• CLDC 1.0 HotSpot JVM performance is increased

• Open Mobile Alliance (OMA) Client Provisioning: Configuration of WAP Client over the air, with a minimum of user interaction

• SIM Application Toolkit enhancements

• Media Player and Media Gallery

• MMS: HTTP support, SMIL enhancements

• PC Suite: Contacts Manager, PIM (Outlook Express, Outlook 2002, Notes 6.0); Windows Bluetooth stack support

• SyncML 1.1 Device Management

• UI for speaker dependent voice commands

• 3GPP streaming

• Embedded download links in Applications

• Wallet 2.0

• Enhanced Camera application with support for two times digital zoom and self-timer

• Theme Support ”UI customization for vendors , operators, and users (wallpapers, bitmaps, color schemes, icons and so on): new themes can be delivered via a .sis (Symbian installation system) file and are downloadable over the air (OTA).

Compatibility Issues

Series 60 Platform 2.x incorporates significant changes due to enhancements in the underlying Symbian OS; others are due to enhancements in Series 60 Platform itself. New features, such as multimode telephony and a Multi Media Framework, available in Symbian OS 7.0s, have required the introduction of new APIs and modification of some existing ones. Where possible, compatibility has been maintained between Series 60 Platform 2.x and earlier implementations , but, unfortunately , this has not been possible in all cases. A great deal of effort has been put into maintaining compatibility across the versions. Symbian OS 7.0s implements a number of enhancements to existing (6.1) features, as well as completely new functionality that has no equivalent in the earlier version (for example, IPv6 addressing). In the same way, Series 60 2.x implements new and improved features such as UI themes that have no equivalent in Series 60 1.x. It is therefore possible that a small number of applications built on Series 60 1.x will either fail to build or may exhibit unexpected behavior on Series 60 2.x.

From the developer's point of view, therefore, there are two main issues: application source code compatibility and application binary compatibility.

• Application Source Code Compatibility represents that situation where code will execute across versions if it is rebuilt.

• Application Binary Compatibility ( BC ) represents that situation where code will execute across versions without intervention.

Note that in either case, backward compatibility may not be achievable, especially where the implemented features rely on functionality of the newer OS.

In many cases, [forward] compatibility has been maintained by implementing wrapper functions around newer functionality (deprecating the older functions), so that older source code will build/execute without modification. However, where this type of feature could not be implemented, a compatibility break will occur, this is generally manifested by a difference between the library a component was linked against, and the DLL against which the component is being run. In this situation, all client code using this DLL service must be amended; thus, source code compatibility is no guarantee of eventual binary compatibility in these areas.

When designing your application it is advisable to keep the following points in mind:

• If possible, avoid using lower-level API calls where higher-level calls are available.

• Underlying functionality changes provided in modified functions may break binary compatibility.

• If backward compatibility is not an issue, use the new APIs rather than the wrapper functions.

• The use of deprecated functions is not recommended, as these may be removed in future releases.

• Avoid using hard-coded paths. Applications should access media files via interfaces that resolve paths dynamically.

The following are known areas where binary compatibility breaks can or do occur:

• Comms Framework ” Support for Multihoming has rendered some APIs (Nifman/RGenericAgent) obsolete. CommDB, the database that stores communications- related settings, has been amended, and, although BC has been maintained, data formats have changed.

• Secure Sockets Layer ” The API for Secure Sockets has been updated and binary compatibility broken.

• Telephony API ” Multimode telephony has been introduced with a resultant break in BC.

• SMS Applications ” Changes to the telephony architecture have meant a break in BC by the SMS module (this does not affect the Messaging APIs).

• Multi Media Framework ” The Multimedia Server has been deprecated. Efforts have been made to retain BC through wrapper functions, but plug-ins to the Multi-Media server will no longer be compatible.

Compatibility Summary

Series 60 Platform 2.x has evolved to improve platform functionality and employ the latest mobile technologies. As with any evolution, a consequence of the progression is that some APIs published in earlier releases are now obsolete.

To develop applications for cross-platform release while maximizing the potential of each requires careful consideration. Given that this (in)compatibility situation exists, the developer has two real choices:

• Generating different source code modules and different builds for each platform release, tailoring the application engine implementation separately for each build and using platform-specific APIs, avoiding the use of deprecated libraries and wrapper functions.

• Using the same source code modules and different builds for each platform. By separating common source code from platform-specific using a preprocessor macro, applications can be tailored to exploit the functionality available in each platform release.

More detailed information on the differences between version 6.1 and 7.0s of Symbian OS can be obtained from the Symbian Web site ”see http://www.symbian.com/technology/whitepapers.html.

For detailed coverage of compatibility between Series 60 Platform 2.0 and previous versions, search the Forum Nokia Web site (http://www.forum.nokia.com) for a document entitled "Series 60 Platform 2.0: Compatibility Issues."

Additionally, see the Series 60 2.x SDK documentation and search for "Deprecated List" ”a list of classes and methods that either no longer exist (very rare) or are not recommended for future use, typically because they have been replaced with better alternatives.