Handling AsyncCallFail

22 views
Skip to first unread message

Shawn Johnson

unread,
Jun 3, 2013, 6:53:08 PM6/3/13
to gwt-pl...@googlegroups.com
I am trying to gracefully handle AsyncCallFail after an application update.  The latest test I tried, I call Window.alert() - giving an "Oops.." type of message.  The AsyncCallFailEvent occurred on an attempt to navigate the application after the initial application was loaded in the browser, and the user clicked on a new 'page' - that page's code wasn't yet loaded.  After I clicked the OK form the alert box, the application became un-clickable?   Is there a best practice or any advice on handling this kind of situation?

Jonas

unread,
Jun 4, 2013, 6:39:05 AM6/4/13
to gwt-pl...@googlegroups.com
Handling hot deploys is always a tricky issue. A solution that I find works best is to simply show a message to the user that the application needs to reload, and then force a redirect to the main page which will download the new Javascript. Google groups is using a similar soluition. If you leave your browser open for the night and come back you'll get a small message that it needs to reload.

Shawn Johnson

unread,
Jun 4, 2013, 9:20:05 AM6/4/13
to gwt-pl...@googlegroups.com

Thanks for the reply.

How about differentiating between a network hiccup and a hot deployment, on the client?

On Jun 4, 2013 6:39 AM, "Jonas" <sar...@gmail.com> wrote:
Handling hot deploys is always a tricky issue. A solution that I find works best is to simply show a message to the user that the application needs to reload, and then force a redirect to the main page which will download the new Javascript. Google groups is using a similar soluition. If you leave your browser open for the night and come back you'll get a small message that it needs to reload.

--
You received this message because you are subscribed to a topic in the Google Groups "GWTP" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/gwt-platform/3ipBcv16KtI/unsubscribe?hl=en-US.
To unsubscribe from this group and all its topics, send an email to gwt-platform...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

Jonas

unread,
Jun 4, 2013, 9:53:32 AM6/4/13
to gwt-pl...@googlegroups.com
You will need to make a custom exception that you throw to the client side.

For example, if you are using RPC and perform a hot deploy you most often get a IncompatibleRemoteServiceException thrown on the backend. What I do is have a HotDeployException that extends from GWTP's ActionException that I throw instead which due to ActionException and the dispatcher propagates back up to the client. You can then inspect the exception on the client and act accordingly.

In case of network hiccups, you would probably get some kind of RuntimeException that you need to handle.

Heiko Braun

unread,
Jun 4, 2013, 10:02:19 AM6/4/13
to gwt-pl...@googlegroups.com
sounds like you need to unlock the place manager. I think there was a mail form Harald about that a while ago. see also:


Regards, Heiko

Harald Pehl

unread,
Jun 4, 2013, 10:54:33 AM6/4/13
to gwt-pl...@googlegroups.com, ike....@googlemail.com
I sent a pull request at that time to address the issue :https://github.com/ArcBees/GWTP/pull/196. Though I don't know if the fix is already in the current version. 

- Harald 
Reply all
Reply to author
Forward
0 new messages