How can I prevent from reloading the page when the reload button on browser is clicked?

[Mike J]

Hi,
I ran into a problem about clicking the "reload" button on a web
browser.

My app is a stateful GWT app. Users need to be authenticated for
login. After login they can surf on various pages. But users sometimes
were used to press the "reload" button on the browser to refresh the
page.

The reloading process just bring the screen back to a reboot state,
with all state info lost. That's not what we expect.

The quick solution is, catch the reload event before the browser
sends the "reload" request to the web server and prevent the browser
from sending it.

I have read the relevant posts in this group and found the useful
info that "reload" event is equivalent to the Window Closing event. So
in the following code snippet I can catch the event,

Window.addCloseHandler(new CloseHandler<Window>() {
public void onClose(CloseEvent<Window> event) {
//prevent browser sending the reload request to the
web browser
}
});

But I don't know how I can stop the browser from sending the
"reload" request to the web server.

Thanks for any help,

Mike J.

[federico]

bad design.
"refresh" is a feature and you should provide bokmarkable refresh-save
pages.

[Mike Jiang]

Don't get it. Please show your good design in an understandable style.

 

--
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-we...@googlegroups.com.
To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.

[Ranjan]

It is not possible to avoid refresh(reload) through scripts. The only
possible thing is you could display an alert message through the
browser which provides the User with option to either stay on the page
or leave it. Which is what is done in the CloseHandler in your example
script.

What federico wants to say is you should use history-tokens to save
your states.

Use Refresh, Back, Forward as a feature and not a catastrophe, with
the the help of GWT History support.

On Jun 1, 6:57 am, Mike Jiang <mikej1...@gmail.com> wrote:
> Don't get it. Please show your good design in an understandable style.
>

> > google-web-tool...@googlegroups.com<google-web-toolkit%2Bunsubs cr...@googlegroups.com>
> > .

[Mike Jiang]

Thanks for a clear desc. What I'd like to say is that the "refresh-save" is not a new scenario at all for web apps. Actually I have heavily used the history tokens for back/forward/reloading following the sample code of GWT ShowCase. But saving states is a subtle thing for a stateful app. Accord to the info found, there are some concerns when doing historical back/forward/reloading,

1). reloading is equivalent to rebooting of an operating system or closing of an app, implies lost every and each bit in nature;

2). reloading is a feature of the "traditional" web app with multiple separate web pages, not a preferred one for ajax apps since a GWT project has only one html file; Actually it was said that the reloading was used less and less in ajax apps if not totally abandoned;

3). Saving the states before reloading is not a simple task to do for a dynamic loaded screen; so does for loading states back and re-displaying the state exactly;

4). there remains an issue for where the states are saved. Save them to the server side or save it as cookie on the client side? a fashionable way is to save the states to the persistence on the server side;

5). saving states involves saving all the state data from every possible screen the app might have, which is not a simple job;

I have studied the example of the ShowCase and found that the app actually loads every possible content screen into a collection and adds them all as history tokens while the app initializes. This is good for a small app but not preferable for a very large web project for sure. 

Secondly it's found when clicking the reloading button from the browser, actually the app only reloads the content widget with "static" data, not exactly re-display the previous state.   You can see it by clicking the "Source Code" tab then pressing "reload" button.

Welcome any comments. 

Thanks,

Mike J.

Based on the above points, I want to avoid reloading or refreshing and let the page simply stays as it is. It's a lazy person's scenario. It might be totally wrong. But I have not been convinced what's the fatal error in this method. 

 

On Mon, May 31, 2010 at 10:53 PM, Ranjan <ranja...@gmail.com> wrote:

It is not possible to avoid refresh(reload) through scripts. The only
possible thing is you could display an alert message through the
browser which provides the User with option to either stay on the page
or leave it. Which is what is done in the CloseHandler in your example
script.

What federico wants to say is you should use history-tokens to save
your states.

history

To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.

[g p]

You could look into the Html5' s local storage mechanism for saving your application's state before a reload happens. 

You can also decide what part of the state you want to save, thus reloading gracefully the most important parts of your application and letting the user do the needed actions to reach at her previous state (i.e in a tree you could just load the tree at its initial state and have the user manually open the nodes to her previous selection ... )

As you mentioned your approach is a lazy one, and in ajax refresh is less and less used, but the application should not try to teach users new ways to interact with the browser and if possible handle the history events in a non catastrophic way ... 

Cheers!

[Ranjan]

Simply put, it is impossible to avoid Page reload if the User clicks
the 'Refresh' button on the browser. There is no way to avoid it if
the user wants to refresh the page.

And yes, when the page is refreshed, every object contained within the
Page is lost. So you will have to create the whole page from the
scratch.

Now the problem you are facing (as I have understood) is, as the user
works on your application, a number of widgets are created, removed,
moved from one place to another, so on. And if at any point, the user
Refreshes the page, your page would start up with the initial
condition.

This is normally solved by using history tokens. Now when I say saving
a state, I meant saving it in a small piece of string, that would be a
part of the URL (Something like #page/10caf10b or #navigation/91abc,
etc). Now this small bits of information are usually sufficient for
loading the entire page. It might make few ajax calls with the server.
Sessions are used in cases like this.

And believe me a very complex applications could be developed using
just small bits of tokens that can easily be accommodated in the URL
itself. Take GMail for example. You can just browse through different
states of the Gmail application, and if you press refresh button at
any state, you will get the same page when it refreshes.

I hope you got my point.

Page reloading is something that is done by the User and it can't be
avoided. Its up to the programmer that the user receives the same
interface even if he/she refreshes the page at any state of the
application.

> > > > google-web-tool...@googlegroups.com<google-web-toolkit%2Bunsubs cr...@googlegroups.com><google-web-toolkit%2Bunsubs

[Mike Jiang]

Thanks, everybody. I have to do that way probably later.

Mike J.

To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.

[kozura]

Everyone is of course correct about not trying to circumvent reload/
refresh, and using history tokens to track the current document and
any state. If your app displays one or a few "documents" like emails,
and has an easily enumerable set of display configurations, this works
great.

Just wanted to mention that there is a class of apps where this is not
an option, because the state is too complicated to capture in url
tokens and it is impractical to send the complete state back to the
server for permanent storage/unique token generation every time it
changes. In these cases, you can still store the state locally, to
make history work, but maybe have a "Link" button ala google maps for
when someone wants to permanently store a particular view to send to
someone. Unfortunately this won't survive refresh or pasting the link
into another browser unless the user creates the permalink, in which
case you might weigh if you should bother the user with some sort of
Save dialog as mentioned above.

[Dan]

Warn the user that his action will log him out, or whatever. Like
this, using a WindowClosingHandler:

Window.addWindowClosingHandler(new Window.ClosingHandler(){
@Override
public void onWindowClosing(ClosingEvent event) {
event.setMessage("If you leave or refresh this page, " +
"you will be logged out of " +
"this application. Confirm that you want to do that.");
});

The browser will take it from there.