[Flashcoders] Apparently Doesn't Check Cache
Hi;
I have this code:
public class Preloader extends MovieClip
{
var loader:Loader = new Loader();
var loader2:Loader = new Loader();
var loader3:Loader = new Loader();
private var myTextField:TextField = new TextField();
var imgFlag1:Boolean = new Boolean(false);
var imgFlag2:Boolean = new Boolean(false);
public function Preloader()
{
addEventListener(Event.ADDED_TO_STAGE, init, false, 0, true);
}
private function init(e:Event)
{
var clientName:TextField = new TextField();
var format:TextFormat = new TextFormat();
format.font = 'Arial';
format.size = 35;
clientName.textColor = 0x023048;
clientName.text = 'Client Name';
clientName.autoSize = TextFieldAutoSize.LEFT;
clientName.setTextFormat(format);
var nameSprite:Sprite = new Sprite();
nameSprite.x = stage.stageWidth/2 - 140;
nameSprite.y = stage.stageHeight/2 - 40;
nameSprite.alpha = 0;
TweenLite.to(nameSprite, 2, {alpha:1});
addChild(nameSprite);
nameSprite.addChild(clientName);
loader.contentLoaderInfo.addEventListener(Event.COMPLETE, imageLoaded);
loader.load(new URLRequest(images/logo.png));
loader2.contentLoaderInfo.addEventListener(Event.COMPLETE, imageLoaded2);
loader2.load(new URLRequest(images/graphic.png));
loader2.contentLoaderInfo.addEventListener(ProgressEvent.PROGRESS, loop);
removeEventListener(Event.ADDED_TO_STAGE, init);
addChild(myTextField);
myTextField.width = 250;
myTextField.x = stage.stageWidth/2;
myTextField.y = stage.stageHeight/2;
myTextField.selectable = false;
myTextField.border = false;
myTextField.borderColor = 0xAA;
myTextField.autoSize = TextFieldAutoSize.LEFT;
var myFormat:TextFormat = new TextFormat();
myFormat.color = 0x023048;
myFormat.size = 24;
myFormat.italic = true;
myTextField.defaultTextFormat = myFormat;
}
private function imageLoaded(event:Event):void
{
imgFlag1 = true;
if (imgFlag2 == true)
{
completePreloader();
}
}
private function imageLoaded2(event:Event):void
{
imgFlag2 = true;
if (imgFlag1 == true)
{
completePreloader();
}
}
function completePreloader()
{
var req:URLRequest = new URLRequest('index.py');
navigateToURL(req, '_self');
}
function loop(e:ProgressEvent):void
{
var perc:Number = e.bytesLoaded/e.bytesTotal;
myTextField.text = Math.ceil(perc*100).toString() + %;
}
}
}
Now, this does exactly what I want in that it loads the two graphics before
going to my page that has two swf files, one of which is a splash page. The
problem is that it *always* loads those images without, apparently,
bothering to check to see if they're already cached. I wonder if this is
because I never add them to the stage (addChild). How do I get the script to
check and see if the images are already cached?
TIA,
Victor
___
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] Apparently Doesn't Check Cache
Every request for a file will go back to the server at some level. For example, despite the fact that have a file preloaded' into cache when another request is made for the file it will look at the cache then send a request to the server to see if the file has changed or whether the file in cache is valid to use. If the server returns use file from cache then it will use the cached file otherwise it will load the revised version from the server. First questions would then be what is the header returned as part of the original file request. Is it no-cache or does it set a very short expiry? Are the url's exactly identical or is there any kind of query string associated with the url of one request but not the other? This might be walking on thin ice here, but can you see the file in the browser's cache? Back in the day, when I was doing Director development, there was a period of time that elapsed from when Shockwave loaded the file and the time that it went into the browser's cache. The file was always available within the Shockwave environment but it was immediately visible in the browser's cache. Don't know if a similar situation arises with Flash where the content is loaded but hasn't yet been written into the browser's cache. I'd honestly start out by using something like Internet Explorer where you can easily browse the cached files - blow away the cache and then load your swf preloader app. See if the files are in cache. If they are cool, note the URL associated with them. Then I'd go back and clear the cache again and re-run the app with the new window code in place. I'd run it through to completion and see if there are two copies of said image in cache one from the swf preloader and the other from the new window. If so it would imply that they must be seeing slightly different urls. If not then I'd be looking for no cache headers. Concurrent to this I'd be using something like Fiddler (IE), Charles or Tamper Data or similar app that will allow you to see the requests and the responses and be able to examine the headers and check for no-cache or very short expiry on the headers. Theoretically what you are doing should work, I can't see how placing the image on stage would make any difference. Everything is always a possibility but using a test strategy that stepwise verifies what is getting written into cache and what the request are for the files is a good first step in eliminating many issues. Sincerely Mark R. Jonkman ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] Apparently Doesn't Check Cache
I actually have experienced the reverse of this issue. Flash caches the dynamic content so hard that I have reverted to using no_cache meta tags in my HTML. Not to OT the topic, but are meta tags the best way to prevent this? I have even though of adding a variable at the end of my dynamic urls with a date element so flash would constantly think its a new XML doc to load everytime. Nathan Mynarcik Interactive Web Developer nat...@mynarcik.com 254.749.2525 www.mynarcik.com -Original Message- From: mark.jonk...@comcast.net Date: Wed, 10 Mar 2010 13:46:08 To: Flash Coders Listflashcoders@chattyfig.figleaf.com Subject: Re: [Flashcoders] Apparently Doesn't Check Cache Every request for a file will go back to the server at some level. For example, despite the fact that have a file preloaded' into cache when another request is made for the file it will look at the cache then send a request to the server to see if the file has changed or whether the file in cache is valid to use. If the server returns use file from cache then it will use the cached file otherwise it will load the revised version from the server. First questions would then be what is the header returned as part of the original file request. Is it no-cache or does it set a very short expiry? Are the url's exactly identical or is there any kind of query string associated with the url of one request but not the other? This might be walking on thin ice here, but can you see the file in the browser's cache? Back in the day, when I was doing Director development, there was a period of time that elapsed from when Shockwave loaded the file and the time that it went into the browser's cache. The file was always available within the Shockwave environment but it was immediately visible in the browser's cache. Don't know if a similar situation arises with Flash where the content is loaded but hasn't yet been written into the browser's cache. I'd honestly start out by using something like Internet Explorer where you can easily browse the cached files - blow away the cache and then load your swf preloader app. See if the files are in cache. If they are cool, note the URL associated with them. Then I'd go back and clear the cache again and re-run the app with the new window code in place. I'd run it through to completion and see if there are two copies of said image in cache one from the swf preloader and the other from the new window. If so it would imply that they must be seeing slightly different urls. If not then I'd be looking for no cache headers. Concurrent to this I'd be using something like Fiddler (IE), Charles or Tamper Data or similar app that will allow you to see the requests and the responses and be able to examine the headers and check for no-cache or very short expiry on the headers. Theoretically what you are doing should work, I can't see how placing the image on stage would make any difference. Everything is always a possibility but using a test strategy that stepwise verifies what is getting written into cache and what the request are for the files is a good first step in eliminating many issues. Sincerely Mark R. Jonkman ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] Apparently Doesn't Check Cache
On Wed, Mar 10, 2010 at 9:46 AM, mark.jonk...@comcast.net wrote:
Every request for a file will go back to the server at some level. For
example, despite the fact that have a file preloaded' into cache when
another request is made for the file it will look at the cache then send a
request to the server to see if the file has changed or whether the file in
cache is valid to use. If the server returns use file from cache then it
will use the cached file otherwise it will load the revised version from
the server.
First questions would then be what is the header returned as part of the
original file request. Is it no-cache or does it set a very short expiry?
I have not explicitly set any such header parameters. Here is the code for
index.html:
htmlhead
SCRIPT language=JavaScript
!--
window.location=preload.py?width= + screen.width;
//--
/SCRIPT
/head/html
and here is preload.py:
#!/usr/bin/python
import cgitb; cgitb.enable()
import cgi
import sys,os
sys.path.append(os.getcwd())
form = cgi.FieldStorage()
width = form.getfirst('width','800')
lines = '''#!/usr/bin/python
def width():
return %s
if __name__ == '__main__':
width
''' % width
f = 'width.py'
try:
os.remove(f)
except OSError:
pass
f = open(f, 'w')
f.writelines(lines)
f.close()
os.chmod('width.py', 0755)
print Content-Type: text/html
print
print '''
!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Frameset//EN
http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd;
head xmlns=http://www.w3.org/1999/xhtml;
meta http-equiv=REFRESH content=0;url=preloader.swf /
/head
/html
'''
I supplied earlier the code that generates that swf.
Are the url's exactly identical or is there any kind of query string
associated with the url of one request but not the other?
See above.
This might be walking on thin ice here, but can you see the file in the
browser's cache?
I can't figure out where Safari's cache is :( I just tried googling without
success. Lots asking the same question...
Back in the day, when I was doing Director development, there was a period
of time that elapsed from when Shockwave loaded the file and the time that
it went into the browser's cache. The file was always available within the
Shockwave environment but it was immediately visible in the browser's cache.
Don't know if a similar situation arises with Flash where the content is
loaded but hasn't yet been written into the browser's cache.
I'd honestly start out by using something like Internet Explorer where you
can easily browse the cached files - blow away the cache and then load your
swf preloader app. See if the files are in cache. If they are cool, note the
URL associated with them. Then I'd go back and clear the cache again and
re-run the app with the new window code in place. I'd run it through to
completion and see if there are two copies of said image in cache one from
the swf preloader and the other from the new window. If so it would imply
that they must be seeing slightly different urls.
Well in that case, before I d/l Exploiter, they are indeed seeing different
urls, as you can see from the above.
If not then I'd be looking for no cache headers. Concurrent to this I'd be
using something like Fiddler (IE), Charles or Tamper Data or similar app
that will allow you to see the requests and the responses and be able to
examine the headers and check for no-cache or very short expiry on the
headers.
Please advise me on what I've answered above if you believe that's where the
problem lies. Otherwise, I'll start experimenting with what you've
recommended here below.
TIA,
V
___
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
RE: [Flashcoders] Apparently Doesn't Check Cache
Hi Nathan, The urls are the best way IMHO. Check out my blog entry on the subject: http://neo-archaic.ie/blog/2006/08/nocache-for-javascript-and-flash/ Cheers, Karina -Original Message- From: flashcoders-boun...@chattyfig.figleaf.com [mailto:flashcoders- boun...@chattyfig.figleaf.com] On Behalf Of Nathan Mynarcik Sent: 10 March 2010 2:03 To: Flash Coders List Subject: Re: [Flashcoders] Apparently Doesn't Check Cache I actually have experienced the reverse of this issue. Flash caches the dynamic content so hard that I have reverted to using no_cache meta tags in my HTML. Not to OT the topic, but are meta tags the best way to prevent this? I have even though of adding a variable at the end of my dynamic urls with a date element so flash would constantly think its a new XML doc to load everytime. Nathan Mynarcik Interactive Web Developer nat...@mynarcik.com 254.749.2525 www.mynarcik.com -Original Message- From: mark.jonk...@comcast.net Date: Wed, 10 Mar 2010 13:46:08 To: Flash Coders Listflashcoders@chattyfig.figleaf.com Subject: Re: [Flashcoders] Apparently Doesn't Check Cache Every request for a file will go back to the server at some level. For example, despite the fact that have a file preloaded' into cache when another request is made for the file it will look at the cache then send a request to the server to see if the file has changed or whether the file in cache is valid to use. If the server returns use file from cache then it will use the cached file otherwise it will load the revised version from the server. First questions would then be what is the header returned as part of the original file request. Is it no-cache or does it set a very short expiry? Are the url's exactly identical or is there any kind of query string associated with the url of one request but not the other? This might be walking on thin ice here, but can you see the file in the browser's cache? Back in the day, when I was doing Director development, there was a period of time that elapsed from when Shockwave loaded the file and the time that it went into the browser's cache. The file was always available within the Shockwave environment but it was immediately visible in the browser's cache. Don't know if a similar situation arises with Flash where the content is loaded but hasn't yet been written into the browser's cache. I'd honestly start out by using something like Internet Explorer where you can easily browse the cached files - blow away the cache and then load your swf preloader app. See if the files are in cache. If they are cool, note the URL associated with them. Then I'd go back and clear the cache again and re-run the app with the new window code in place. I'd run it through to completion and see if there are two copies of said image in cache one from the swf preloader and the other from the new window. If so it would imply that they must be seeing slightly different urls. If not then I'd be looking for no cache headers. Concurrent to this I'd be using something like Fiddler (IE), Charles or Tamper Data or similar app that will allow you to see the requests and the responses and be able to examine the headers and check for no-cache or very short expiry on the headers. Theoretically what you are doing should work, I can't see how placing the image on stage would make any difference. Everything is always a possibility but using a test strategy that stepwise verifies what is getting written into cache and what the request are for the files is a good first step in eliminating many issues. Sincerely Mark R. Jonkman ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] Apparently Doesn't Check Cache
Really quick answer because I need to run to a meeting:
Safari - I assume you are on Mac then.
Safari open the activity monitor and you can see the requests. Validate that
the urls for the image are the same.
Download either Charles or another monitor type utility - if you have FireFox
use FireBug extension. You can then see the actual requests and the detailed
headers. Then you can look for things like no-cache headers.
Don't bother with IE unless your on windows.
There are some extensions for FireFox I believe that will let you view the
cache as well. IE's cache on *windows* is just easy to see the files and the
urls they came from so if you were on windows its a great low budget easy thing
to do.
Sincerely
Mark R. Jonkman
- Original Message -
From: Victor Subervi victorsube...@gmail.com
To: Flash Coders List flashcoders@chattyfig.figleaf.com
Sent: Wednesday, March 10, 2010 9:08:55 AM GMT -05:00 US/Canada Eastern
Subject: Re: [Flashcoders] Apparently Doesn't Check Cache
On Wed, Mar 10, 2010 at 9:46 AM, mark.jonk...@comcast.net wrote:
Every request for a file will go back to the server at some level. For
example, despite the fact that have a file preloaded' into cache when
another request is made for the file it will look at the cache then send a
request to the server to see if the file has changed or whether the file in
cache is valid to use. If the server returns use file from cache then it
will use the cached file otherwise it will load the revised version from
the server.
First questions would then be what is the header returned as part of the
original file request. Is it no-cache or does it set a very short expiry?
I have not explicitly set any such header parameters. Here is the code for
index.html:
htmlhead
SCRIPT language=JavaScript
!--
window.location=preload.py?width= + screen.width;
//--
/SCRIPT
/head/html
and here is preload.py:
#!/usr/bin/python
import cgitb; cgitb.enable()
import cgi
import sys,os
sys.path.append(os.getcwd())
form = cgi.FieldStorage()
width = form.getfirst('width','800')
lines = '''#!/usr/bin/python
def width():
return %s
if __name__ == '__main__':
width
''' % width
f = 'width.py'
try:
os.remove(f)
except OSError:
pass
f = open(f, 'w')
f.writelines(lines)
f.close()
os.chmod('width.py', 0755)
print Content-Type: text/html
print
print '''
!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Frameset//EN
http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd;
head xmlns=http://www.w3.org/1999/xhtml;
meta http-equiv=REFRESH content=0;url=preloader.swf /
/head
/html
'''
I supplied earlier the code that generates that swf.
Are the url's exactly identical or is there any kind of query string
associated with the url of one request but not the other?
See above.
This might be walking on thin ice here, but can you see the file in the
browser's cache?
I can't figure out where Safari's cache is :( I just tried googling without
success. Lots asking the same question...
Back in the day, when I was doing Director development, there was a period
of time that elapsed from when Shockwave loaded the file and the time that
it went into the browser's cache. The file was always available within the
Shockwave environment but it was immediately visible in the browser's cache.
Don't know if a similar situation arises with Flash where the content is
loaded but hasn't yet been written into the browser's cache.
I'd honestly start out by using something like Internet Explorer where you
can easily browse the cached files - blow away the cache and then load your
swf preloader app. See if the files are in cache. If they are cool, note the
URL associated with them. Then I'd go back and clear the cache again and
re-run the app with the new window code in place. I'd run it through to
completion and see if there are two copies of said image in cache one from
the swf preloader and the other from the new window. If so it would imply
that they must be seeing slightly different urls.
Well in that case, before I d/l Exploiter, they are indeed seeing different
urls, as you can see from the above.
If not then I'd be looking for no cache headers. Concurrent to this I'd be
using something like Fiddler (IE), Charles or Tamper Data or similar app
that will allow you to see the requests and the responses and be able to
examine the headers and check for no-cache or very short expiry on the
headers.
Please advise me on what I've answered above if you believe that's where the
problem lies. Otherwise, I'll start experimenting with what you've
recommended here below.
TIA,
V
___
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
___
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http
Re: [Flashcoders] Apparently Doesn't Check Cache
On Wed, Mar 10, 2010 at 11:15 AM, mark.jonk...@comcast.net wrote: Safari - I assume you are on Mac then. Affirmative. Download either Charles or another monitor type utility - if you have FireFox use FireBug extension. You can then see the actual requests and the detailed headers. Then you can look for things like no-cache headers. Decided to go with FF, d'l'd same, doesn't want to render Flash right now and the plug-in didn't seem to plug in. At any rate, it did cache the assets when I loaded the page, FireBug reported nothing amiss. What now? TIA, V ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
