tag:robotlegs.tenderapp.com,2009-10-18:/discussions/questions/683-multiple-application-instancesRobotlegs: Discussion 2018-10-18T16:35:32Ztag:robotlegs.tenderapp.com,2009-10-18:Comment/103027232011-09-29T17:03:58Z2011-09-29T17:03:59ZMultiple application "instances"<div><p>Love RL! I created a modular Air application with a shell and
modules, each with there own context and MVCS impl. Works
great!</p>
<p>Now I've run into a significant challenge. It seems the new
requirement for the application is that it allow multiple instances
to be launched. I know that, with Air, this is not possible.
However, the common workaround is to try to create a headless main
class that can spawn windows as needed. I guess this should work,
but I would think the application would need significant re-working
to support multiple instances, with most everything being
singletons and whatnot. That is, unless I can figure out how to set
up the correct application domains to encapsulate each
instance.</p>
<p>Has anybody run into a similar scenario or can offer any advice?
Thx</p></div>jason.gardner.lvtag:robotlegs.tenderapp.com,2009-10-18:Comment/103027232011-09-29T19:47:26Z2011-09-29T19:47:26ZMultiple application "instances"<div><p>Hi Jason,</p>
<p>as there are no static singletons, there's no reason why you
can't just spawn two of your app - assuming they don't require a
comms channel between them. The 'singleness' of a singleton is
maintained by the injector, not the getInstance() pattern - so
provided each app has its own injector, it will also have its own
'singletons'.</p>
<p>So - it would literally just be a case of doing new MyApp() for
each instance.</p>
<p>If you need communication (but not shared instances) between
them then you'd probably be best to take the original long-hand
modular approach - you can find that on my github: <a href=
"https://github.com/Stray/robotlegs-utilities-Modular">https://github.com/Stray/robotlegs-utilities-Modular</a></p>
<p>This version of modular just facilitates communication between
modules by using a shared eventDispatcher. I tend to use a mediator
around each module to relay external events to the internal
dispatcher and vice versa.</p>
<p>Note that this won't be the most efficient route at execution -
you'll be doing all your reflection and type checking and so on
from scratch in each app. Depending on whether performance is
important, it might be viable to implement a shared cache for that
stuff, and serialise it to shared storage, so that when a new
instance of the app is spawned it can pre-load the injector and
mediator map caches and so on. Or you can just live with it how it
is :)</p>
<p>But yes - it <em>should</em> be straight forward.</p>
<p>Stray</p></div>Straytag:robotlegs.tenderapp.com,2009-10-18:Comment/103027232011-09-29T19:54:32Z2011-09-29T19:54:35ZMultiple application "instances"<div><p>Stray,</p>
<p>Thanks so much for the reply.</p>
<p>Yes, in my case there won't be any communication between
instances, so I'll just try to create some sort of headless main
class for my Air app and create multiple instances of my app
"shell" in separate windows. ::fingers crossed::</p></div>jason.gardner.lvtag:robotlegs.tenderapp.com,2009-10-18:Comment/103027232011-09-29T20:03:44Z2011-09-29T20:03:44ZMultiple application "instances"<div><p>Excellent - if you run in to anything peculiar, shout and we'll
see what we can do,</p>
<p>Stray</p></div>Straytag:robotlegs.tenderapp.com,2009-10-18:Comment/103027232011-09-29T20:46:54Z2011-09-29T20:46:55ZMultiple application "instances"<div><p>Worked like a charm, Stray! I wouldn't have guessed it, but
after understanding your explanation of the singleton pattern in
RL, I was way overthinking it. "it just works" :)</p></div>jason.gardner.lv