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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
