problems integration swfobject 2.1 and jquery (document.ready)

[aldana]

hi,

I got problems to integrate swfobject 2.1 with jquery 1.2.6.Calling
ExternalInterface of a flash app fails.

When using window.onload callback accessing ExternalInterface works
fine, so it must be a jquery/swfobject integration problem. I read
some posts but they only mention solutions to outdated swfobject
+jquery versions.

//SAMPLE CODE:

$(document).ready(function() {
var flashvars = {};
var params = {allowscriptaccess:"always",bgcolor:"#dddddd"};
var attributes = {};
swfobject.embedSWF("http://urlToFlashCookie.swf", "flashCookie", "0",
"0", "8",null,flashvars,params,attributes);
writeFlashValue("documentReadyCall","value");
});

function writeFlashValue(key,value){
var obj = swfobject.getObjectById("flashCookie");
if (obj && typeof obj.setFlashCookieValue != "undefined") {
obj.setFlashCookieValue(key,value);
document.getElementById("myInput").value ="";
}
else alert("callback assert error");
}

[Bobby]

Just start by moving your SWFObject definitions and embed outside the $
(document).ready(function() { } block. SWFObject has a built-in
domload itself and already does this for you.

[aldana]

i followed your advice, but same issue.

the problem is always the line inside writeFlashValue():

var obj = swfobject.getObjectById("flashCookie");

when calling writeFlashValue() through $document.ready() I get a wrong
object back, when calling through window.onload I get a proper
callback.


//SAMPLE CODE WITH EXTRACTED STUFF:

var flashvars = {};
var params = {allowscriptaccess:"always",bgcolor:"#dddddd"};
var attributes = {};
swfobject.embedSWF("http://urlToFlashCookie.swf", "flashCookie", "0",
"0", "8",null,flashvars,params,attributes);

$(document).ready(function() {

writeFlashValue("documentReadyCall","value");
});

function writeFlashValue(key,value){
var obj = swfobject.getObjectById("flashCookie");
if (obj && typeof obj.setFlashCookieValue != "undefined") {
obj.setFlashCookieValue(key,value);
document.getElementById("myInput").value ="";
}
else alert("callback assert error");
}

[Bobby]

Your SWF and External Interface functionality will need some time to
initialize, so calling it directly when the DOM is loaded is too
quick.

You'd better only call it as soon as it is available, e.g.:
var obj = document.getElementById("flashCookie");
(function() {
if (obj && typeof obj.JStoASviaExternalInterface != "undefined") {
obj.JStoASviaExternalInterface();
}
else {
setTimeout(arguments.callee, 10);
}
})();

[Getify Solutions, Inc.]

Bobby's code below is a good start, but it's not robust enough according to
what I've found in testing. For instance, in IE, there's actually a split
second where the function is "defined" on the flash swf dom object, but it's
not actually got anything in it yet (like it's an empty function value).
There are several complications which ensue.

As an alternative to rolling your own code for waiting for ExternalInterface
to be ready, there's a library that I wrote and maintain called CheckPlayer
http://checkplayer.flensed.com/ which wraps around SWFObject and adds some
additional "advanced" functionality, including in this case,
ExternalInterface availability checking.

Basically, the strategy is to give the library a specific function name to
try to call on the swf (**caveat), which it will loop trying to do until the
try/catch around it *doesn't* fail (in which case you now know for sure the
function is ready!). Now that the readiness is detected, it calls an a
callback function you define, which notifies the rest of your code that the
SWF is fully ready to go.

It's not the prettiest solution, but it was what I found to be most reliable
in terms of full cross-browser testability.

My suggestion is, rather than trying to figure out these frustrations for
yourself as I did, you might consider using CheckPlayer. Otherwise, you can
look to trying to duplicate the logic I implemented for your own code.

--Kyle


**caveat: The only "downside" really (which is usually not a problem) is
that you have to have some function defined which is ok to be called just
plain, without any parameters, who's successful calling will not create a
problem with the state of your SWF (since it'll be guaranteed to be called
once successfully before the rest of your code continues). So, on my SWF's,
I usually have some sort of simple "Reset" or "Init" function, which doesn't
really even have to do much, but is a valid function I can call on the SWF
without using any parameters, and once it's ready, I know the rest of my
important functions are also ready.





--------------------------------------------------
From: "Bobby" <bobbyvan...@gmail.com>
Sent: Wednesday, January 21, 2009 6:58 AM
To: "SWFObject" <swfo...@googlegroups.com>
Subject: Re: problems integration swfobject 2.1 and jquery (document.ready)

[aldana]

cool, thanks.

I got the window.onload callback in place now, which works fine
(anyway the item i need swfobject for is at the bottom of the page).
so maybe I'll stick with this. I highly appreciate your little lib,
but including it would even increase the javascript lib complexity we
already have, which I want to avoid.

what does speak against accessing .swf through window.onload callback?
will it be non-deterministic in terms of accessibility of the .swf
(some browsers load faster/slower, page load time)?

On 21 Jan., 14:16, "Getify Solutions, Inc." <get...@gmail.com> wrote:
> Bobby's code below is a good start, but it's not robust enough according to
> what I've found in testing. For instance, in IE, there's actually a split
> second where the function is "defined" on the flash swf dom object, but it's
> not actually got anything in it yet (like it's an empty function value).
> There are several complications which ensue.
>
> As an alternative to rolling your own code for waiting for ExternalInterface

> to be ready, there's a library that I wrote and maintain called CheckPlayerhttp://checkplayer.flensed.com/ which wraps around SWFObject and adds some

> additional "advanced" functionality, including in this case,
> ExternalInterface availability checking.
>
> Basically, the strategy is to give the library a specific function name to
> try to call on the swf (**caveat), which it will loop trying to do until the
> try/catch around it *doesn't* fail (in which case you now know for sure the
> function is ready!). Now that the readiness is detected, it calls an a
> callback function you define, which notifies the rest of your code that the
> SWF is fully ready to go.
>
> It's not the prettiest solution, but it was what I found to be most reliable
> in terms of full cross-browser testability.
>
> My suggestion is, rather than trying to figure out these frustrations for
> yourself as I did, you might consider using CheckPlayer. Otherwise, you can
> look to trying to duplicate the logic I implemented for your own code.
>
> --Kyle
>
> **caveat: The only "downside" really (which is usually not a problem) is
> that you have to have some function defined which is ok to be called just
> plain, without any parameters, who's successful calling will not create a
> problem with the state of your SWF (since it'll be guaranteed to be called
> once successfully before the rest of your code continues). So, on my SWF's,
> I usually have some sort of simple "Reset" or "Init" function, which doesn't
> really even have to do much, but is a valid function I can call on the SWF
> without using any parameters, and once it's ready, I know the rest of my
> important functions are also ready.
>
> --------------------------------------------------

> From: "Bobby" <bobbyvandersl...@gmail.com>

[Getify Solutions, Inc.]

Yes, in my testing, I found the window-load type events (and dom-ready
events as well) unreliable in determining if the EI was ready or not. If you
are not having those troubles, then I wouldn't worry about it. But it is
something to be aware of, that IE does have some delay in getting those
initialized.

--Kyle




--------------------------------------------------
From: "aldana" <ald...@gmx.de>
Sent: Wednesday, January 21, 2009 8:51 AM

[aldana]

Yes this loading order is a nightmare.

Has somebody made work checkplayer lib with a flash app using
ExternalInterface? Does it support it?

> >> CheckPlayerhttp://checkplayer.flensed.com/which wraps around SWFObject

[Getify Solutions, Inc.]

I wrote CheckPlayer, and I have it used in a number of applications, where
EI availability testing was an important factor. That's why I built that
feature in fact, for this exact reason.

The caveat to the generic code in CheckPlayer is that your SWF has to have
some sort of function exposed on it that you can call, without any
parameters, and that not affect the SWF's behavior in a bad or irreversible
way.

For instance, if you have a MP3 player, and it has a "StopSong()" function
on it, it shouldn't be a problem to call "StopSong()" over and over during
loading of the SWF because once it succeeds the first time (and an actual
call to StopSong goes through to the SWF), generally speaking that action
didn't require any parameters, and asking the player to stop a song while
it's already stopped shouldn't be a problem. By the same token, if you
actually are wanting your mp3 player to start playing as soon as possible,
via a call to "StartSong()", then you are essentially needing the same
mechanism, to basically keep trying to call the function until a JS error
doesn't occur.

Where it wouldn't work is if all your functions on your SWF require
parameters, and throw errors (or cause bad behavior of the SWF) if no
parameters are sent. In this case, you'd not want to use the generic code
that CheckPlayer provides, but instead write your own similar logic but with
an exact function call (and parameters) customized to whatever your
situation is.

If you need some help with CheckPlayer, I suggest you post to the flensed
list or in the forums. We'll be happy to help you over there.

--Kyle








--------------------------------------------------
From: "aldana" <ald...@gmx.de>

Sent: Tuesday, March 03, 2009 12:07 PM

[aldana]

as suggested i created follow up thread with new question in the
flensed forum:
http://checkplayer.flensed.com/discuss/viewtopic.php?f=11&t=59&p=176#p176

> >> >> CheckPlayerhttp://checkplayer.flensed.com/whichwraps around SWFObject