Changes to flex mxml do not appear when redeploying

I'm new to Flex so hopefully this will be an easy one...

I created a simple Flex UI and I've been noticing that sometimes after I make changes and redeploy to the app server (JBoss 5.1) the changes aren't showing up.  My mxml file is relatively simple and has an <mx:Script> block for a couple ActionScript functions.  It seems like the changes don't show up whenever I modify something in a function but when I add a new function (even if it is empty), the change then shows up.  

It seems like the only way I can force the change to show up in the browser is if I delete the *_temp_flex_config.xml files.  Even if I select 'Build->Rebuild Project' it still doesn't update the browser with the change.  After I redeploy the war file (it has the flex module and a java module) I make sure to refresh the web browser by selecting the address and hitting 'enter'.

The only thing I can think is that either IntelliJ (or the Flex SDK) isn't picking up the change and thus not deploying the update or that the web browser is keeping a local cache of the SWF file or something.

Please let me know if you have any idea of what I'm doing wrong!  

Thanks,
-Glenn

2 comments

So after troubleshooting and searching more online, I found that the problem is due to the web browser caching the SWF file.  From what I've seen, there are several ways to prevent the browser from caching (for use while developing), one of which is to set the flex compiler to debug mode.  I checked the *_temp_flex_config.xml' files and it appears they are set to debug=true but this doesn't seem to solve it.

Is there a good way to configure IntelliJ to build the swf so that the browser doesn't cache or is this something I need to do in the code itself?  Thanks for any help with this!

0

We have run into this as well. Very annoying. I have not found a fix within IDEA itself. There are a couple of stratgies you can take however to try and solve.

1) Force your browser to always check for a new version

In IE, go to the Temporary Internet Files settings and change the "Check for newer versions of stored pages" option to "Every visit to the page".
In Firefox, enter about:config in the address bar. Filter on the work "cache". Change the option browser.cache.check_doc_frequency to a value of 1. (See http://kb.mozillazine.org/Browser.cache.check_doc_frequency for details on the possible values)
Chrome: Not sure since I don't use it. Try googling for info.

The downside of this strategy is that your users will not have this setting. And you can unknowingly introduce bugs. For example, we had a page that worked fine on the developer's PCs (that had this setting change) but failed in testing and on user's PCs. Turns out a REST page that the Flex code accessed was getting cached by the browser. Due to the above setting, it did not surface for the developers since they always hit the server. We had to make a code change (using the strategy shown below) to resolve the issue. So there is a risk problems will get past developers when doing their work.

The other downside is that this affects ALL your web browsing. And therefore will slow your browser down a bit.

2) Use a unique parameter with each request.

In our Flex code, whenever we need to access a REST or other HTML based service, we add a parameter of ?noCache=<UUID> onto the URL (with the UUID being generated on the fly via Flex's UIDUtil class).  (We extended the Flex HTTPService class so this is automatically done for us for all HTTP Services.) This forces the browser to go to the sever to look for a new version of the page. You really don't need the parameter name/value combo and could simply use the UID as a parameter name (with no value). We like using the noCache name so that in log files it is clearer what that UID value is. Spring ActionScript uses a similar strategy by simply adding a random number as a parameter name to the URL when fetching configuration files

I have not found a way for IntelliJ IDEA to do something like this. I'm not sure if simply having a parameter on there (even if it doesn't change) will force the browser to check for a new version, or if it will see all requests for example.com/myApp.SWF?name=value as the same request. I've been thinking of modifying our build so that the name of our SWF file gets a UUID or random number thrown into it. Since we auto-generate the index.html wrapper page, it could be created so the name of the SWF matches the one with the unique UUID in it. Obviously the downside there is we will always need to go through the wrapper page rather than accessing the SWF directly since its name will be different after each build. Plus this would not work for SWFs built outside the build script (such as builds done by IDEA.)

I hope that helps.

-Mark

0

Please sign in to leave a comment.