Publishing sis along with an embedded sis

[jawadakhtar]

Hi,

My application is composed of two separate applications. One is a backend (non-UI) application and another one is UI based, both developed in Qt. I also acquired two separate UIDs for both. I need to know the process how to publish one single final sis of UI application that should have an embedded sis of non-gui application.

Right now using Qt Creator I have successfully created unsigned sis of non-gui application which is ready to be published. Should I publish it to OVI to get signed version of it so that it can be embedded in unsigned sis of GUI application ?

Please guide, how should I proceed from here.

Thanks,

Jawad.

[wizard_hu_]

For publishing in the Store, embedded .sis files also need trusted signing. And Nokia Publish do not sign for embedding as I know, so you would need to sign with Symbian Signed.
However here is a side remark: a single .sis file can contain multiple executables, .dll-s without any problems. You only need embedding if the embedded component is intended for re-use, and thus may get distributed with other application(s) too (like the CameraWrapper or the AudioProxyServer packages just to mention some infamous examples).

[jawadakhtar]

Thanks wizard_hu_. The daemon application is autorun app that executed automatically on the start of the device. Let me see how can I include daemon app EXE file into GUI app SIS and make it only autorun (not GUI app). If needed, I will require additional help in this regard.

[symbianyucca]

If I remember right(and unless it has been changed), the store design does not really like the autorun exe, when it is not the GUI, unless you would unconditionally run the GUI (which then makes no sense at all anymore)

Basically the launching UID given is used for checking if the application is installed (and which version is there), and if it does not match the package UID then the store can not really check the application from the device..

So there is no really nice solution for the problem, unless you have your own Symbian signed account, and use it for signing the embedded sis file..

[wizard_hu_]

On the technical side (regardless of Store/not-Store), the startup registration file has to be in the outer package and thus its name has to use the PkgUID of the outer package.
Also, remember the Symbian Signed criteria, including Test #6 about autostarted code (http://www.developer.nokia.com/Commu...tart_behaviour).

[jawadakhtar]

This is getting more complicated. Going for Symbian Signed for a small application is really not worthy for me. I am figuring out an alternate way and need to know how the process tree is maintained in Symbian? Like, if I autorun my GUI application and on the start it starts EXE (non-gui) file and terminates its self, so does non-gui exe continues its execution or not ?

[wizard_hu_]

It is not that complicated in fact. You need a config file and a process which starts on boot. Then read the config file and ensure at the end that the daemon is running/not running according to the actual setting. Technically the process checking the config file can be any of them, the daemon itself (then it decides to exit or keep running), the GUI code (then it decides to start/not start daemon - however in this case the GUI code also has to detect if it is getting autostarted or not, because you do not want to keep it running), or even a 3rd executable, which is responsible for the autostart feature only.
And yes, there are two contradicting details:
- autostarting the GUI code enables you to store the config file in the private folder of the GUI code - since the config file is accessed by this process only. However in this case there is the requirement of detecting autostart (in which case the RunApplication call should be skipped and an autostart-related code should run)
- autostarting anything else is a simpler case in terms of startup, but in this case protecting the config file becomes complicated (if you want to protect it for some reason), as different processes are going to access it (GUI for setting and the actual starter code for checking)