I sincerely appreciate the effort of the organizers and thank the attendees for making it a successful event.

One of the attendees asked me a question about problems with Flex HTTPService and the IE browser cache. I promised to provide a detailed solution to the problem, so here it is:

Problem: Repeated HTTPService calls when made from Flex (running within an instance of the IE browser) many a times ends up with no external HTTP call. It appears the data is served from cache.

Reason:  The Flash Player piggybacks on the browser to make the HTTP call. IE caches the response from the HTTP GET calls and on occurrence of the same URL returns the response from the cache.

Solution: The problem can be solved either at the server side or at the client side.

Server side solution:  Set the HTTP headers of the response to avoid returning response from cache.

In HTML: (in the header)

<META HTTP-EQUIV=”Cache-Control” CONTENT=”no-cache”>
<META HTTP-EQUIV=”expires” CONTENT=”0″>

In PHP: (in the script)

header(”Cache-Control: no-cache, must-revalidate”);
header(”Expires: Mon, 26 Jul 1997 05:00:00 GMT”);

In JSP: (before writing to the output stream)

response.setHeader(”Cache-Control”,”no-cache”);
response.setDateHeader (”Expires”, 0);

Client side solution: (1) Make HTTP POST call — only HTTP GET calls are served from cache or (2) Make sure the HTTP GET URL is different every time.

(1) Make HTTP POST call –
set method=”POST” and handle the call appropriately

(2) Append a unique parameter to the HTTP GET call so that the URL is different every time. A unique time stamp is a good choice.
The following sample code, may do the job:

var timeStampForNocache:Date = new Date() ;
params.noCacheControlVar = timeStampForNocache.getTime().toString() ;
I have named the parameter “noCacheControlVar”. You can name it anything else you please. The name does not matter. What matters is that the timestamp makes the HTTP GET URL unique.

That’s it! Hope it helps and IE does not trouble you when using HTTPService anymore.

Web spiders will now be able to playback SWF(s) like users and cull out the data to add to their index. This announcement has two huge impacts:

• Traditionally, a big disadvantage of making flash player applications was that they were not properly visible to the search engines. This won’t be true going forward.
• By enabling search indexing via playback, a new era is going to begin. Traditionally text has been the favorite media for search engines. Hopefully this announcement heralds the good news of better rich media indexing in general. We would all like to search audio and video content based on the information they contain and not just the way they are tagged.

Congratulations to Adobe, Google and Yahoo for this new development.

Thanks!

I am presenting on day 2 of the conference. The topic of my presentation is — “Flex integration with a few Java EE Scenarios”. I ran the same session at 360 Flex Atalanta on 26 February 2008. The feedback from that session confirmed that many people enjoyed the session and are interested in Flex and Java integration. If you are interested, come to the show and join me on day 2.