How to show previous url after user has canceled dialog with message from Activity#mayStop()?

In our app we need to check if the data is saved when we are in a particular place before navigating away from it. So the user should be 开发者_如何学编程able to negate a browser back button request. But by the time that the history value change event is received the url has already been changed. The History class doesn't seem to have a way to restore the url back. Anybody have any ideas?

In GWT 2.1 you get Activities and Places. And activity has a maystop method, which is exactly what you want, if I understand you correctly.

Use a window.onunload or window.onbeforeunload javascript callback to confrim/save state. onbeforeunload example

I haven't actually implemented this behavior yet, but here is my plan and maybe it will work for you.

1) Each time you receive an onHistoryChanged event and decide to allow it, save the current historyToken in an instance variable somewhere.

2) Keep track of activity on the page that should block navigation. Use a data structure that can keep track of multiple activities, like multiple file uploads, multiple edits, etc.

3) When you receive a new onHistoryChanged event, if your data structure from #2 indicates that it's not safe to navigate, avoid changing the page and restore the historyToken that you saved in #1. I'm assuming that you can do this either by:

a) Calling History.newItem(oldHistoryToken, false) or

b) Calling History.newItem(oldHistoryToken, true) and keeping a flag to force the next onHistoryChanged to be ignored.

Again, I haven't actually implemented this so let me know how it works out.

If you have links that allow the user to leave the app and you want to prevent that as well, you'll need to also add an onbeforeunload.

Have a look at the PlaceManagerImpl class from the gwt-platform framework. Especially the onValueChange() method and the methods dealing with the onLeaveQuestion field.

Hope that helps.

In this issue report, t.broyer explains in his comment that such behavior was planned during design of Places framework. The most important part is:

mayStop was a mistake, or it should have only been called when unloading the app, not for internal navigation within the app.

So probably it's better to not use it at all...