How about this; what are the advantages to using helper applications? So far we’ve discussed the disadvantages to using helpers as opposed to forking.
Also what are the disadvantages to forking as opposed to helpers? We’ve discussed the possible advantages.
I should double check and make sure that a Sandboxed application can actually fork itself…
In theory I see nothing against a repeatly self-calling app… you have to write kind of master-control-proxy-stub-something to manage all the instances. This could result in more control and in better debugging. And you could use commandline parameters.
You might need to define “what is a helper app?” I have a client who has a web app that spins up a service that connects back to the web app to feed status messages. This is of course on Windows. The web app also monitors the running status of the windows service and users can “boot” the service as required from the web server.
I imagine this is not what you’re trying to achieve - works very well for my client though.
Looking at your projects I’m sure my design techniques won’t work, but as a rule I start with a “harness” project where I create my classes which include serialization/deserialization using JSON (new framework) and test these using a tcp server/socket to the app. Yes it talks to itself. This allows me to validate communication between my apps (host & helper). I can then take my classes & import them into the target projects pre-tested. With proper testing I rarely have issues and I can implement design shortfalls using the same technique.
I love the idea to launch a second or third instance of the same app from shell. With the proper arguments and a robust IPC, it should work flawlessly.
More interesting, since they have the same bundle ID, all instances can access the same container. Actually, that could be used to do inter process communication with files instead of using Xojo IPC.
About app size, my latest Fonts Manager contains a 1700+ Fonts collection. As a result, it is over 280 Megs, and takes 6 minutes to download from the App Store. Have not heard any complaint yet 
I thought about this whilst walking the furry ones, and came up with several questions.
The #1 question being; could this be debugged.
The answer is no, a forked application cannot be debugged. The forked application fails to launch as it fails to connect to the Xojo IDE. So it’s not any easier to debug; and in fact may actually be harder to debug 
Indeed you cannot have two instances debugged at the same time. But you can run the same application as a debug one with the different parameters that make it behave as a helper or as main app.
I believe you can even add a parameter to keep a debug UI while the app plays windowless-pseudo console.
It would seem at the least just the same as a Console app.
well it might be little help only… but you could use system.log for writing information, values and messages and reading them in your event viewer for debugging purposes
On Mac at least, the main problem could be that the system may not let you launch two instances of the same executable…
After more thought - I think Michel’s on to something; sorta a happy medium…
One project (and code base), with a constant that can be toggled to build either the helper or the main app. This way all the code is neatly contained within one project. Yet when the helper is built we can combine the libraries (as both will use the XojoFramework) and therefore it doesn’t introduce duplicate libraries into the main application.
I’ll do some more experimentation tomorrow.
Excuse me for a limited use proposal, but if its about a Mac app: Have you considered using Grand Central Dispatch? The existence of block objects thanks to Joes plug-in should make it possible to create ObjC blocks from Xojo code and pass them to GCD for parallel execution. Its no solution for Windows and Linux of course, but it could be for OS X and iOS.
It works very nicely.
Build the following project, launch and click the button. The robot window is the second instance of the app.
There is need of communication between instances, though : quitting the main app does not close the helper instance automatically. But nothing IPC could not solve.