Signaling a slot in a different application on a Symbian device

[mikelupo]

I don't think this could get more complicated. I have application (a) and application (b). Both QT applications resident (and running) on a Symbian device. From Application (a) I would like to signal a slot in application (b). Note: application (b) uses a namespace. It's also a flat .exe (no lib or dll)

Is this even possible?
if yes, do I need to include any .h files from application (b) inside of application (a) to get the object for application (b)'s slot?

Thanks in advance,
Mike

[goetz]

You cannot do this with standard Qt signal/slot or C++ method calls. You need some interprocess communication (IPC) protocol. There are some hints on the "Inter-Process Communication in Qt":http://doc.trolltech.com/stable/ipc.html page of the docs.

Another approach (instead of TCP/IP) would be to use local sockets:
"QLocalServer":http://doc.qt.nokia.com/stable/qlocalserver.html seems to be a good choice. Application a would create the server and application b would use a "QLocalSocket":http://doc.qt.nokia.com/stable/qlocalsocket.html to connect to the server. The server creates another local socket once a connection comes in. You must serialize your messages though. But as you use Qt on both ends, this is quite easy, you can put a QDataStream on top of both local sockets (they are QIODevice subclasses).

[andre]

You might also look into other solutions:

• Qt supports DBUS, but I don't know if that works on Symbian. It is mainly a Linux thing.
• The Qxt library has some RPC classes that may be of use. QxtRPCPeer might work for you. With some limitations, it will take care of all the (de)serialization for you.
• QSharedMemory also comes to mind; though it is quite low level, it is a fast way to communicate between apps.

[goetz]

QtDBUS is - according to the docs - only for the Unix ports. I'm not sure if the Symbian world counts i.

I thought about QSharedMemory too, but it has no signalling mechanisms, so one would have watch the memory segment for state changes manually. On the other hand, the local sockets send signals when something comes in. It seemed the most easy to use approach to me.

[andre]

Sure, it all depends on what you want to achieve in the end. You could even combine the two approaches: signal through a local socket, and use the shared memory to actually move the data around. Might be more efficient for larger blobs of data.