Adobe air runtime prevents more than one instance of an air application to be started at the same time. Is it safe to circumvent this restriction by arbitrarily changing the publisher ID? Does anyone know if Adobe plans to allow multiple concurrent instances in Air 2.0?
A:
Would it help if you encapsulate the logic of your application as a class that could run in a window and allow the user to create multiple instances of that window, within one app ? would that help ?
What is the main reason you would need multiple applications ?
George Profenza
2010-02-14 19:35:30
Thanks for the answer, but I am specifically looking for separate processes. There are a number of benefits, for example parallel execution on multi-processor computers.
abc
2010-02-15 00:13:46
I see, thanks for the explanation. Good question. You can have separate processes in Java...this might be way to long winded, would interfacing AIR and Java through Merapi(http://merapiproject.net/) do any good ?
George Profenza
2010-02-15 11:24:17
Again, interesting post, but it is off topic. Merapi is an IPC framework rather than a link framework (such as JNI), so it isn't possible to link to a multi-threaded java library; there would have to be a separately started java process. Furthermore, using a java helper would only provide parallel processing, not other advantages of multiple processes. Let's return to the original question: I am looking for a way to start several instances of a Flex AIR app, and specifically whether running the same swf with multiple publisher IDs is legal in the AIR runtime.
abc
2010-02-15 19:00:28
just out of curiosity: are air apps limited to one thread only?
Lorenzo Boccaccia
2010-02-18 16:22:06
Lorenzo: Yes, limited to one, it seems. http://www.flexjunk.com/2009/01/15/multi-threading-in-flexair/
aaaidan
2010-02-18 21:50:54
+2
A:
We successful implemented a hack to circumvent this limitation, in a pure AIR way, without having to change the publisher id (which needs multiple certificates, I think).
As you know, AIR is implementing its Mutex by using a unique application identifier. This identifier is calculated using the application id, and the publisher identifier (extracted from the certificate that signed the application).
In the installation directory of an AIR application, there is a META-INF folder (or in /share/ using Linux). This META-INF folder contains an AIR folder, which contains an "application.xml" file. This file contains a <id /> tag that defines the application identifier, which is used in the calculation of the mutex identifier. If your application can write in the installation folder, you can use the File API to edit it at runtime, randomly changing the <id /> tag, allowing multiple processes of the same application to be run at the same time.
This is having some annoying side effects, like creating a new folder in the File.applicationStorageDirectory folder every time. But using a LocalConnection, you can minimize this by reusing the same identifier multiple times by logging which ones are free to be reused. Also, SharedObject are stored in this folder, so cannot be used (or have to be copied every time a new instance is created, and synchronized though LocalConnection).
As far as I know, Adobe isn't planning to remove this native limitation. It was implemented for multi-platforming purposes, specifically on MacOS, where the dock is making that more complicated (it's not very easy to start the same application twice with the dock).
The official way to do that is to catch the InvokeEvent.INVOKE event, and do stuff like opening a new window. And there's no change planned for AIR 2.0 in this behaviour.
Tyn
2010-02-17 08:33:27