Developers guidelines Signing applications
Planning for development
There are a number of considerations to take in the beginning of the development process for a Symbian OS applications. Apart from the normal system analysis and design, also the design implications on sign- ing requirements and testing procedures specific for the Symbian OS v9 platform must be taken into account.
Signing or not
As mentioned above, many applications do not require any capabilities and thus can be installed and exe- cuted in the “unsigned – sandboxed” environment. This may be an alternative for applications intended for personal use or for limited groups of users. For most commercial purposes and for widely spread applica- tions, taking the costs and extra work needed for going through the Symbian Signed processes gives sev- eral advantages and is therefore highly recommended also for applications that do not require signing.
Symbian Signed advantages:
•Symbian Signed applications have passed a number of tests, which guarantees a certain quality level, giving added value for customers.
•Symbian Signed applications are made visible to Symbian partners, like network operators, distribu- tors, phone manufacturers, and so on, via a special catalog, thus opening up a marketing channel for developers making use of the programme.
•Sony Ericsson, Nokia and several major operators and service providers, only allow applications that have passed the Symbian Signed programme to be exposed via their application shops.
The Symbian Signed programme requires that developers of applications to be submitted for signing have an ACS publisher ID from Verisign. Under certain conditions an ACS publisher ID is also required for a developer to retrieve a developer certificate for application testing on real devices. Since it may take some time to be approved for it, an ACS publisher ID should be requested in good time before it is actually required.
Required capabilities
To avoid some of the extra work and additional costs for using extended or phone manufacturer capabili- ties, it is a good idea always to analyze carefully which capabilities are necessary for the application. If it is possible to implement a needed functionality using an API of a lower level capability set, or an unrestricted API, this should always be preferred.
Another reason for early planning of which capabilities are needed for an application, is that a developer certificate might be required for testing on real devices. To make testing as realistic as possible, the devel- oper certificate should grant access to the same set of APIs as the finished application. For applications using only unrestricted APIs, developer certificates are not required.
15 | October 2006 |
