S60 1st Edition and 2nd Edition Differences
S60 1st Edition is based on Symbian OS v6.1 (with some Nokia modifications), whereas S60 2nd Edition is based on Symbian OS v7.0s. Some features in S60 2nd Edition come from enhancements to Symbian OS and others come from S60 platform enhancements — the origins of the changes are summarized below.
Symbian OS v6.1 and v7.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
- JavaTM: MIDP 2.0 (supports JSR 118 Security)
S60 1st Edition and 2nd Edition differences
- 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).
S60 2nd Edition incorporates significant changes due to enhancements in the underlying Symbian OS; others are due to enhancements in the S60 platform itself. New features, such as multimode telephony and a Multimedia Framework, available in Symbian OS v7.0s, have required the introduction of new APIs and modification of some existing ones. Where possible, compatibility has been maintained between S60 2nd Edition 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 v7.0s implements a number of enhancements to existing (v6.1) features, as well as completely new functionality that has no equivalent in the earlier version (for example, IPv6 addressing). In the same way, S60 2nd Edition implements new and improved features such as UI themes that have no equivalent in S60 1st Edition. It is therefore possible that a small number of applications built on S60 1st Edition will either fail to build or may exhibit unexpected behavior on S60 2nd Edition.
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
Application Source Code Compatibility represents that situation where code will execute across versions if it is rebuilt.
Application Binary Compatibility
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.
Important application design issues
- 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.
Where binary compatibility breaks can 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).
- Multimedia 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.