save state in Browser
When surfing the web, always from one page to another page, from one site to another. In this process, the Web browser faithfully records the history of where you have been, creating a breadcrumbs (breadcrumbs) digital trajectory that can go back to the starting point step-by-step along this path. The Back button allows you to go back to where you were before the previous action, in the sense that it is the Undo button on the Web.
The Web is a page-divided medium. The back and forward buttons in the browser toolbar guide the browser to move from page to page. When Macromedia Flash Popular, developers and users found that rich Internet applications (Rich Internet Application,ria) broke this pattern. Users can browse through several sites and then log on to a Flash based site that kills a few minutes on the site. When the user clicks the Back button, the game is over. The user did not return to the previous Flash site, completely unaware of where.
The same is true for another form of--ria, a completely Ajax-based Web site. Sites that allow users to interact with a page more than once are susceptible to the back button or bothered by any history button (for that matter). The problem with the forward and overload buttons is the same as the back button. The internal history mechanism built into the Web browser is an inescapable problem. For security reasons, developers cannot tamper with browser history or any related buttons. There are also usability issues. Imagine how confusing it would be if the back button suddenly popped up with a cryptic warning or the user was sent to a new website.
Build History Stack
Although you can't change the history of your browser, you can build a history that you use in RIA. Obviously, it should somehow be separated from the browser's standard navigation tools, but as mentioned earlier, rich applications have somewhat deviated from the standard mode of Web page to page.
There is also a pointer to the stack, indicating our current position on the stack. When we click in the application, the new event is pressed onto the top of the stack, and the pointer points to the last element added. When you click the application's back and Forward buttons, the new event is not added to the stack, but the pointer to the stack is moved. Think about what happens in the history stack when you use the Back button: The browser returns to the last viewed page, and the forward button that was not used suddenly becomes available. When you browse the new page, the forward button turns gray again. Later saved elements in the browser history are ejected from the stack, and new events are pressed onto the top of the stack. We will reproduce this behavior in the history stack we created ourselves.
Our goal is to create a set of available history buttons: Back, forward, and refresh, as shown in Figure 1.
Figure 1. History buttons for back, forward, and refresh are displayed on the left and unavailable for the right
Buffer with Cookies
We need the history of the application to exist throughout the browser session. As long as the user is still viewing the album page, the history stack object will always exist. Whenever a change occurs, the class copies the entire history to the browser cookie. If a user leaves the page in the same browser session and returns, the same location in which he left the application is returned.
    Next page