On Wednesday, February 29, 2012 4:38:32 AM UTC+1, coderinabstract wrote:
Experiencing a similar problem and this seems to be very frustrating for user experience management especially if you are doing agile build life cycle with frequent releases.
The situation is that AsyncCallback failure is NOT firing and when we have code split points and there are ONLY User interface changes i.e. ux changes, and a user has navigated on all pages of the previous version of the app, even with the cache control header (with a servlet filter), the failure does not fire i.e. the old UI works fine with the services and cannot detect the new UI client on the server unless the user explicitly refreshes UI does not refresh.
Any thoughts... examples, best practice. I sincerely hope I am missing something as this is very tricky trapping all the what if scenarios when there is a new app.
You could, e.g. add headers to your RPC responses (and/or requests), handled through an RpcRequestBuilder, that communicates a "version number" for the app.
Or more easily add a "heartbeat" RPC that periodically checks if the UI needs a refresh (e.g. using the permutation ID as the "version number": send the permutation ID and check on the server if the corresponding *.cache.* file exists in the webapp, returning a simple boolean for instance).
-- 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/-/GhxiNGb0fzQJ.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to google-web-toolkit+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
No comments:
Post a Comment