Excellent - I am not alone in my troubles.  On second thought, perhaps
rejoicing in the sharing of pain is not the most healthy viewpoint to
take ...

The post to the older discussion was quite useful.  The blog linked
there has some pretty good information on how this same issue has been
dealt with in the past, and some other issues that I haven't yet had
to deal with.  In the end, it seems that it all comes down to crafting
your application in such a way that it is able to perceive its out-of-
dated-ness (English is awesome) and inform the user of the potential
errors, or just force them to do the Right Thing and reload the
application.  The latter seems like a more sane thing to do, given the
similarity of instructing users to herding cats.  I suppose false
positives are something that might be in issue in that case, and an
epileptic application may result, but that should be easy enough to
discover in testing.

I agree that this should be mentioned in the documentation as well.
It seems like something that is much easier to deal with if you
consider it from the beginnings of your application, as opposed to
running into it (or, perhaps, more appropriately, stumbling into it)
somewhere down the line.  One would assume the Google guys (aka Sir
Developer Not Appearing In This Thread) have dealt with this, since
their AdWords UI is (if I recall correctly) based on GWT.  I would
likewise assume that product has a fair number of active users at all
times of day, and they are probably as hesitant to drive around the
world as I am.

I would be most intrigued to see what they have done internally.  I
imagine it involves pixie dust and invisible pink unicorns.

-Ben

On Dec 13, 6:17 am, Raphael André Bauer
<raphael.andre.ba...@gmail.com> wrote:
> I had similar problems. I guess the reason for those probs was beacuse
> of partially cached files / incompatible rpc files/calls and strange
> stuff like that.
>
> The fix was fairly simple: My apps all have a Window.reload() if
> something goes wrong (eg when fetching async stuff). This
> automatically wipes out the caches, and reloads the app code from
> scratch.
>
> In my case it solved the problem...
>
> Maybe that helps...
>
> Cheers,
>
> Raphael
>
> On Sun, Dec 12, 2010 at 6:20 PM, Filipe Sousa <nat...@gmail.com> wrote:
> > I usually do three things:
>
> > First, I use a subclass of AsyncCallback to catch the most common
> > exceptions: IncompatibleRemoteServiceException, StatusCodeException and
> > InvocationException. When I catch then IncompatibleRemoteServiceException I
> > will ask the user if he wants to reload the application.
>
> > Second, whenever I deploy an application, all sessions are invalidated. The
> > next RPC call will catch an exception from the server because the session
> > ended. When my AsyncCallback catches this exception will warn the user to
> > reload the application.
>
> > Third, the first call to the server always returns a version. I compare this
> > version with the client version. If the versions are different means that
> > the client code is old and needs to be reload.
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Google Web Toolkit" group.
> > To post to this group, send email to google-web-tool...@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.

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to google-web-tool...@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.

Reply via email to