Communicating with other Flash Player and AIR instances
Flash Player 9 and later, Adobe AIR 1.0 and
later
The
LocalConnection
class enables
communications between Adobe® AIR® applications, as well as between
SWF content running in the browser. You can also use the LocalConnection
class to communicate between an AIR application and SWF content
running in the browser. The LocalConnection class allows you to
build versatile applications that can share data between Flash Player
and AIR instances.
About the LocalConnection class
LocalConnection
objects can communicate only among AIR applications and SWF files
that are running on the same client computer. However, the applications
can run in different applications. For example, two AIR applications
can communicate using the LocalConnection class, as can an AIR application
and a SWF file running in a browser.
The simplest way
to use a LocalConnection object is to allow communication only between
LocalConnection objects located in the same domain or the same AIR
application. That way, you do not have to worry about security issues. However,
if you need to allow communication between domains, you have several
ways to implement security measures. For more information, see the discussion
of the
connectionName
parameter of the
send()
method
and the
allowDomain()
and
domain
entries
in the
LocalConnection
class listing
in the
ActionScript 3.0 Reference for the Adobe
Flash Platform
.
To add callback methods
to your LocalConnection objects, set the
LocalConnection.client
property
to an object that has member methods, as the following code shows:
var lc = new air.LocalConnection();
var clientObject = new Object();
clientObject.doMethod1 = function() {
air.trace("doMethod1 called.");
}
clientObject.doMethod2 = function(param1) {
air.trace("doMethod2 called with one parameter: " + param1);
air.trace("The square of the parameter is: " + param1 * param1);
}
lc.client = clientObject;
The
LocalConnection.client
property includes
all callback methods that can be invoked.
isPerUser property
The
isPerUser
property
was added to Flash Player (10.0.32) and AIR (1.5.2) to resolve a
conflict that occurs when more than one user is logged into a Mac computer.
On other operating systems, the property is ignored since the local connection
has always been scoped to individual users. The
isPerUser
property
should be set to
true
in new code. However, the
default value is currently
false
for backward compatibility.
The default may be changed in future versions of the runtimes.
Sending messages between two applications
You use the LocalConnection class to communicate between different
AIR applications and between different Adobe® Flash® Player (SWF)
applications running in a browser. You can also use the LocalConnection
class to communicate between an AIR application and a SWF application
running in a browser.
The following code defines
a LocalConnection object that acts as a server and accepts incoming
LocalConnection calls from other applications:
var lc = new air.LocalConnection();
lc.connect("connectionName");
var clientObject = new Object();
clientObject.echoMsg = function(msg) {
air.trace("This message was received: " + msg);
}
lc.client = clientObject;
This code first creates a LocalConnection object named
lc
and
sets the
client
property to an object,
clientObject
.
When another application calls a method in this LocalConnection
instance, the runtime looks for that method in the
clientObject
object.
If you already have a connection with the specified name, an
Argument Error exception is thrown, indicating that the connection
attempt failed because the object is already connected.
The following snippet demonstrates how to create a LocalConnection
with the name
conn1
:
connection.connect("conn1");
Connecting to the primary application from a secondary application
requires that you first create a LocalConnection object in the sending
LocalConnection object; then call the
LocalConnection.send()
method
with the name of the connection and the name of the method to execute.
For example, to send the
doQuit
method to the LocalConnection
object that you created earlier, use the following code:
sendingConnection.send("conn1", "doQuit");
This code connects to an existing LocalConnection object with
the connection name
conn1
and invokes the
doMessage()
method
in the remote application. If you want to send parameters to the
remote application, you specify additional arguments after the method
name in the
send()
method, as the following snippet
shows:
sendingConnection.send("conn1", "doMessage", "Hello world");
Connecting to content in different domains and to AIR applications
To allow communications
only from specific domains, you call the
allowDomain()
or
allowInsecureDomain()
method
of the LocalConnection class and pass a list of one or more domains
that are allowed to access this LocalConnection object, passing
one or more names of domains to be allowed.
There are two special
values that you can pass to the
LocalConnection.allowDomain()
and
LocalConnection.allowInsecureDomain()
methods:
*
and
localhost
.
The asterisk value
(*)
allows access from all domains.
The string
localhost
allows calls to the application
from content locally installed, but outside of the application resource
directory.
If the
LocalConnection.send()
method attempts
to communicate with an application from a security sandbox to which
the calling code does not have access, a
securityError
event(
SecurityErrorEvent.SECURITY_ERROR
)
is dispatched. To work around this error, you can specify the caller's
domain in the receiver's
LocalConnection.allowDomain()
method.
If
you implement communication only between content in the same domain, you
can specify a
connectionName
parameter that does
not begin with an underscore (
_
) and does not specify
a domain name (for example,
myDomain:connectionName
).
Use the same string in the
LocalConnection.connect(connectionName)
command.
If you implement communication between content in different domains,
you specify a
connectionName
parameter that begins
with an underscore. Specifying the underscore makes the content
with the receiving LocalConnection object more portable between
domains. Here are the two possible cases:
-
If the string for
connectionName
does
not begin with an underscore, the runtime adds a prefix with the
superdomain name and a colon (for example,
myDomain:connectionName
).
Although this ensures that your connection does not conflict with
connections of the same name from other domains, any sending LocalConnection
objects must specify this superdomain (for example,
myDomain:connectionName
).
If you move the HTML or SWF file with the receiving LocalConnection
object to another domain, the runtime changes the prefix to reflect
the new superdomain (for example,
anotherDomain:connectionName
).
All sending LocalConnection objects have to be manually edited to
point to the new superdomain.
-
If the string for
connectionName
begins
with an underscore (for example,
_connectionName
),
the runtime does not add a prefix to the string. This means the
receiving and sending LocalConnection objects use identical strings
for
connectionName
. If the receiving object uses
LocalConnection.allowDomain()
to
specify that connections from any domain will be accepted, you can
move the HTML or SWF file with the receiving LocalConnection object
to another domain without altering any sending LocalConnection objects.
A
downside to using underscore names in
connectionName
is
the potential for collisions, such as when two applications both
try to connect using the same
connectionName
. A
second, related downside is security-related. Connection names that
use underscore syntax do not identify the domain of the listening
application. For these reasons, domain-qualified names are preferred.
Adobe AIR
To communicate with
content running in the AIR application security sandbox (content
installed with the AIR application), you must prefix the connection name
with a superdomain identifying the AIR application. The superdomain string
starts with
app#
followed by the application ID
followed by a dot (.) character, followed by the publisher ID (if
defined). For example, the proper superdomain to use in the
connectionName
parameter
for an application with the application ID,
com.example.air.MyApp
,
and no publisher ID is:
"app#com.example.air.MyApp"
.
Thus, if the base connection name is “appConnection,” then the entire
string to use in the
connectionName
parameter is:
"app#com.example.air.MyApp:appConnection"
.
If the application has the publisher ID, then the that ID must also
be included in the superdomain string:
"app#com.example.air.MyApp.B146A943FBD637B68C334022D304CEA226D129B4.1"
.
When
you allow another AIR application to communicate with your application through
the local connection, you must call the
allowDomain()
of
the LocalConnection object, passing in the local connection domain
name. For an AIR application, this domain name is formed from the
application and publisher IDs in the same fashion as the connection
string. For example, if the sending AIR application has an application
ID of
com.example.air.FriendlyApp
and a publisher
ID of
214649436BD677B62C33D02233043EA236D13934.1
, then
the domain string that you would use to allow this application to
connect is:
app#com.example.air.FriendlyApp.214649436BD677B62C33D02233043EA236D13934.1
.
(As of AIR 1.5.3, not all AIR applications have publisher IDs.)
|
|
|
|
|