New tutorial for full-screen flash with browser scrollbars

[Getify Solutions]

http://blog.wezside.co.za/2008/10/fullscreen-flas.html

 

Thought this article was well done, and I like that it builds on Bobby's examples and uses SWFObject.  Thought it might be interesting to the audience. 

 

--Kyle

 

 

[Bobby]

Thanks Kyle, I've added it to the links page on the wiki:
http://code.google.com/p/swfobject/wiki/links

Unrelated, but I think that you'll find the following interesting:
http://code.google.com/p/swfobject/issues/detail?id=155#c7

[Getify Solutions]

Yeah, Bobby, I read that update earlier today, actually. I like the
direction you're going with it. My thoughts (which I'm going to add to that
post as well) are:

1. in regards to the "gap" of having to wait for the DOM to load to do the
version checking, maybe we should have both detection methods (existing one
before DOM ready, new one after DOM ready). Only if they disagree, then it
can complain (or initiate ExpressInstall, etc), otherwise it can go forward
with the embed as normal. This should also help with multiple installed
versions, right, as the second one is always going to use the newest plugin,
it would seem.

2. #1 above seems like it might work for dynamic embedding, but I'm unclear
as to how it might work with or affect static embedding. Perhaps the same
logic applies, but maybe it needs different thinking.

3. The "delay" in processing of logic may require some re-working of how and
when swfobject does its magic. For instance, we might want to go ahead an
embed a SWF as soon as possible, and get it to start loading, but maybe not
display it until both version checks have passed. In this way, we could do
version detection both before DOM ready *and* after DOM ready, but *not*
actually prevent an embed (force EI) until after both version checks have
occurred. So to the calling code, it proceeds as normal, and the decision to
swap to call removeSWF() on the already loaded SWF and instead swap in EI
could be done transparently to both the user and the calling code. Combined
with the visibility thing I just mentioned, this could keep the transition
still pretty seamless for users, with the side effect being that some extra
(possibly unnecessary) SWF downloading had to occur.

4. Or, perhaps, to prevent so much impact on that existing logic flow, we
could instead have users of swfobject be able to register a callback
function to be notified if version conflicts are found. That way the author
can respond appropriately (calling removeSWF(), hiding, retrying to initiate
EI, etc) if their code is notified that a version mismatch has later been
detected.

--Kyle

--------------------------------------------------
From: "Bobby" <bobbyvan...@gmail.com>
Sent: Thursday, October 30, 2008 11:44 AM
To: "SWFObject" <swfo...@googlegroups.com>
Subject: Re: New tutorial for full-screen flash with browser scrollbars

[Philip Hutchison]

bobby, i your investigation is very interesting.

the new approach sounds more reliable RE: version numbers, but as you said, waiting for DOM to be ready changes the flow.  personally, i don't think waiting for the domready is a bad thing, as we have to wait for domready for any embed to happen anyway (for dynamic publishing).  javascript doesn't manipulate the DOM until domready anyway, right?

if it means more rock-solid detection, i say waiting for domready is a fine trade-off.

kyle, your proposal (doing both types of version detection) is logical and thorough, but also adds a lot of overhead.  i imagine most people would prefer to use just one method, as it executes faster and reduces swfobject.js file size.  maybe you can add it to your flensed project as a swfobject add-on?

- philip

[Bobby]

Well, I'm afraid we still need both methods, because we will not
likely change the functionality of the getFlashPlayerVersion and
hasFlashPlayerVersion methods.

However I am quite positive that for Firefox and Safari (still need to
investigate if this works/how to make it work on other browsers), we
can use the new method to possibly correct corrupt version numbers,
before any DOM related stuff has been decided and executed. So I am
very positive that this will enable us to provide better version
detection in the end. However, version detection results may vary
before the DOM has been loaded and after, which improves the overall
stability of flash version matching, however can cause undesired
results for JavaScript developers...