CODEWITHSUNDEEP
javajavascriptgwtwebsession-cookies
jNess
jNess

Reputation: 65

Best practice to update web application on client side (GWT)

Now I have a problem:

  1. user opens web app page, gets javaScript (ModuleName.nocache.js); Then I update client side (roc requests, view etc).
  2. user didn't close web app tab in browser, didn't update page. He clicks somewhere and gets random explosion. For example, RPC doesn't work, servlets moves anywhere, there is many errors or not.

Now I want to implement scenario:
User must have cookie attribute with web app version.
By request I see it and in response force him to update page (don't know how).
If user's request can't be delivered gwt force him to update page (don't know how).

But I think there must be a best-practice-way to solve this problem.

Upvotes: 3

Views: 899

Answers (2)

apanizo
apanizo

Reputation: 628

Another approach:

  1. If it is empty (if not, go to next step), save the com.google.gwt.core.client.GWT.getPermutationStrongName(); in your LocalStorage or in your Cookies and finish the flow.
  2. When your app loads, get the permutationStrongName again, and check if the saved one is different.
  3. If it is different force to request to the server everything (if you want/need "break" async process you can use GQuery - promises). Then, replace in your LocalStorage or Cookies the new gwt's permutation id.

You can do this always that your app is loaded (is not a big deal). And you can now when the version on your server has changed.

Upvotes: 0

Thomas Broyer
Thomas Broyer

Reputation: 64541

Catch IncompatibleRemoteServiceExceptions and StatusCodeExceptions in your AsynCallbacks. The first one tells you the client-side code is not compatible with the server-side code; the second can tell you that there no longer is a RPC servlet there (look for a 404 status code). You can then show a message to the user prompting him to reload the page (this is what Google Groups does for example).

That said, there are some ways to mitigate this if the changes are relatively small: you can keep the old serialization policy files around server-side so the server can process requests from different client versions. The changes have to be somehow backwards compatible though.
You could then detect the client version on the server-side (either using a list of the latest serialization policy files and checking whether the client is using one of them or an older one; or using a request header or cookie) and include something in the response (response header or cookie) telling it there's a new version.
Or you could regularly poll the server (obviously not using RPC though) for the latest version of the app.

Upvotes: 6

Related Questions