- users won't have the new version unless they refresh (F5) the page. For this though, you have to ensure the *.nocache.js is effectively not cached by browsers or proxies (or at a minimum cached with a "must-revalidate" condition)
- any change to a GWT-RPC class (particularly objects that are transfered through RPC) will break older versions that are still in use, with an IncompatibleRemoteServiceException, because client and server must use the same serialization policies; you can track this to tell users to refresh the page (I guess this is what the GWT-based Google Groups UI does)
- if you use code splitting (runAsync) and you remove the old *.cache.* files, users won't be able to download the fragments while they're using the old version of the app. You can, again, catch this in the onFailure of the RunAsyncCallback to tell users to refresh the page.
- Every compilation should produce differently named *.cache.* files, so you can safely set long cache times for these files: http://code.google.com/webtoolkit/doc/latest/DevGuideCompilingAndDebugging.html#perfect_caching
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/NLQyzwimpyAJ.
To post to this group, send email to email@example.com.
To unsubscribe from this group, send email to firstname.lastname@example.org.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Post a Comment