1. Binary File Name Clashes - Symbian OS v9.x
The potential problem here has always existed for shared .DLLs which resided in \System\Libs\ on earlier releases of Symbian OS. In Symbian OS v9.x, however, allbinaries (.DLLs and .EXEs alike) now live in \sys\bin\ only. The potential for name-clashes is therefore greater. It is imperative that this is avoided - the software installer will not install your binary if one of the same name exists already but was put in place from a .SIS file with a different UID to your own (i.e. by someone else's application).
The Recommended Best Practice here is to simply name your binaries in the format MyBinaryName_UID.dll (or MyApplicationName_UID.exe). For example, your application may install the following two binaries: MySpecialEngine_12345678.dll and MySpecialApplication_0x12345677.dll
2. Stub .SIS files
Stub .SIS files are the files left behind once your application is installed. If your application is being included in a device firmware build, it may be desirable for the Phone Manufacturer to include your stub in the firmware too (to allow for potential future upgrades of your product in RAM). For this reason, MakeSIS can generate a stub .SIS file for you - see your SDK documentation for more details. In Symbian OS v9.x, this becomes even more important for applications which are being shipped on memory cards too, as the stub must be in place on the card for the application to run correctly when the card is inserted in to a phone. In Symbian OS v9.x, the stub must also contain the correct signature information to grant your application the right capabilities, in order for it to work.
If your product is to be included in a device firmware or on a preinstalled memory card, the Recommended Best Practice here is to generate both your 'normal' .SIS file and stub .SIS file using MakeSIS (see the SDK documentation for details) and include both of these (e.g. MyApp.sis and MyApp_Stub.sis) in your submission to the Test House. If your application passes the tests and both types of .SIS are present, both will be correctly signed and returned to you - the application for distribution (if desired) and the stub for inclusion in firmware or to be pre-loaded on memory cards if needed.
3. Applications without a User Interface
<TBD>
4. Small Changes to a tested application
<TBD>
5. Signing DLLs
<TBD>
6. Flash Content
<TBD>
7. Content without an application
<TBD>
8. UID for Localization Purposes
If your application is packaged in individual .SIS files for different locales and/or channels (e.g. the application is identical except for a download link depending on the channel involved), the same package UID can be used for all .SIS variants at the same time, provided only the Passive Content inside each .SIS file (e.g. resource files, bitmaps) differs
9. File Creation Location
The application should only create files on the drive it was installed to, except where the user has explicitly requested or been given the option to select otherwise (e.g. created a document manually on another drive, selected a specific memory location for future storage of new files, etc.).
Unbounded content should not be stored on the Internal (C:) drive by default or without user permission
- Note1: If data is stored on a different drive to the installation location, the user should explicitly make this decision - either by being prompted for a save location or by specifying the default save location in the application's settings.
- Note2: Under no circumstances should unbounded content (e.g. cached pages, log files) be stored on C: drive by default or without user permission
This recommendation does not apply to binary files (resources, dlls) that are required by the platform to be installed on the internal drive regardless of the actual installation drive for the main application. For example, the resource file used to register the application with the Startup List Management API will have to be always installed on the internal drive.
Small files which maintain configuration, license and settings information may be created on the phone's internal C: drive (as this is the only guaranteed writable drive), irrespective of the user-specified application installation drive.
