1. 111 State Management Beginning ASP.NET 4.5.1 in C# and VB Chapter 4 Pages 124 - 131

2. 222 Objectives You will be able to: Understand the need to retain class member variables across page requests. Use.NET state variables to retain the values of member variables across page requests. View State Session State Application State

3. 333 Repeat the Hello Page Download Hello.zip from the class web site: http://www.cse.usf.edu/~turnerr/Web_Application_Design/Downloads/025/ Expand Hello.zip. In Visual Studio, File > Open Web Site Navigate to the website folder and Open Be careful to drill down to the second level Hello folder. See next slide

4. Drill Down to the Website Folder 4

5. 55 View Solution Explorer Be sure you have the right files.

6. 666 The Code-Behind File Add this.

7. 777 Run the App Enter name and then click OK.

8. 888 After Clicking OK The textbox is still filled.

9. 99 The TextBox is Still Filled We didn’t set the Text property of the TextBox. The server (ASPX) received the user input. Set the Text in the TextBox to the input value before it rendered the HTML for this page and sent it to the browser in response to the postback. Restored the appearance of the page as it was before the postback.

10. 10 The TextBox is Still Filled This doesn’t happen with an HTML page. The textbox is empty when a fresh copy of the page is loaded on postback.

11. 11 Add a Cancel Button Set ID and Text properties. Double click on Cancel button to add event handler.

12. 12 Let Cancel Clear the TextBox

13. 13 Try it! Fill in name. Then click Cancel rather than OK

14. 14 After Cancel Clicked Now the TextBox is clear.

15. 15 Try it again! Fill in name. This time click OK, then click Cancel.

16. 16 After Cancel The TextBox is clear, but the greeting is still there!

17. 17 The Greeting Was Restored The greeting was restored by the server before the HTML was sent down to the browser. But the greeting is not an input. How did the server know that it should restore the greeting? How did it know the contents of the greeting?

18. 18 Viewstate The server encoded the appearance properties of the page, other than inputs, in a hidden input: ViewState

19. 19 Look at the Source Hidden input __viewstate encodes the properties of the page that were set by our code. Sent back to the server on postback. If the application code does not change the properties, the previous appearance of the page will be restored when the page is refreshed on the browser. Including content that was set programatically on an earlier request.

20. VIEWSTATE 20 The VIEWSTATE string is Base64 encoded. Can easily be decoded.

21. 21 Clearing the Greeting If we want a clean copy of the page following Cancel, the event handler for Cancel must reset the greeting. End of Section

22. 22 Visit Count Let’s add a counter and keep track of how many times the page has been visited. New label shows the count.

23. 23 Visit Count: Designer

24. 24 Visit Count: Code Behind

25. 25 After First OK

26. 26 After Second OK

27. 27 What’s going on here? Why is count still 1 after additional OK clicks? Each OK sends a fresh copy of the page to the browser. count is reinitialized each time. To persist member variables across page loads, we can use session variables. Each user session will have its own copy.

28. 28 Using a Session Variable Note C# indexer syntax.

29. 29 Session State The Session object is a collection of name-value pairs. We can read and write a value using its name as an indexer. Values are stored as objects. We have to typecast them on retrieval. Session state is normally stored in server memory. Persists as long as the session lives.

30. 30 Initial Page

31. 31 After First OK

32. 32 After Second OK

33. 33 Very Important Any member variable that we want to remember from one page request to the next should be preserved in a session variable. Alternative to hidden inputs Create session variables for member variables that need to be preserved across interactions. Get values on Page_Load Check for existance and create if necessary. Update values when they change.

34. 34 Session Variables Each session gets its own copy of all session variables. But what is a session? Look at the web site on a server, from various browsers and browser windows.

35. 35 First Browser

36. 36 First Browser After a few clicks on OK.

37. 37 Another Tab on Same Browser Same session.

38. 38 Same Browser, Another Window Same session. May have to run as administrator to get Chrome to open another window.

39. 39 Different Browser New session.

40. 40 New Window at Later Time New browser instance gets existing session. (After some amount of time the session will expire.)

41. 41 From a Different Computer Browsers on different computers always have separate sessions.

42. 42 Conclusions Be cautions about multiple tabs and multiple browser windows. Different tabs of a browser get a single session. Same browser in separate windows of the same computer get a single session. Different browsers on the same computer get different sessions. Browsers on different computers have separate sessions.

43. 43 Using ViewState SessionState is stored in the server. Rather than using SessionState we can use ViewState to persist class variables. Values are stored in the __VIEWSTATE hidden variable sent to the browser and returned on PostBack. Each window and each tab will have a separate copy of ViewState.

44. 44 Using ViewState

45. 45 Looks the Same

46. 46 After First OK

47. 47 New Tab Gets own copy of the count.

48. 48 ViewState A variable stored in ViewState is reinitialized on each direct request for the page (vs. PostBack). Old values are restored only on postback. A request for a different page automatically gets a new ViewState.

49. 49 Try it!

50. New Tab 50

51. Original Tab, Reload 51

52. ViewState The __VIEWSTATE hidden variable is Base64 coded. Normally no reason to decode it. Use the ViewState collection to get values. 52

53. 53 SessionState vs. ViewState Each has advantages and disadvantages. SessionState Stored on the server. Relatively safe from hacking. Is shared across tabs and windows Persists for some time after browser window is closes. Is not reinitialized on a direct request for the page. Is shared among different pages of an app.

54. 54 SessionState vs. ViewState Each has advantages and disadvantages. ViewState Is included in the page sent to the browser. Easily hacked. More communication overhead. Less server overhead. Not shared across tabs and windows. Is not shared among different pages without special effort Is reinitialized on each direct request for a page. End of Section

55. 55 Application State Similar to Session State but shared among all sessions running a given app. Concurrency issues! Stored in server memory. Collection created when the application is started. First request for the URL after server started Persists so long as the application runs. Lost when the application is stopped or restarted. Whenever the server is stopped or restarted

56. 56 Application Level Events Event handlers for application level events are in file Global.asax. Application start Application end Application error Session start Session end In Global.asax

57. 57 Example Let’s record the application start time in Application state and display it on each page. Will need to add Global.asax

58. Add New Item to Website 58

59. 59 Add Global.asax Name should be Global.asax

60. 60 Initial Global.aspx.cs

61. 61 Application Start Time

62. 62 Default.aspx.cs Response.Write puts its parameter into the output stream going to the browser.

63. 63 Default.aspx

64. 64 Page in Chrome

65. 65 App on a Real Web Server http://rollinsturner.net/Hello_Application_State

66. 66 Later That Evening 66 The app has been restarted.

67. 67 Same Page in IE 67 Same start time.

68. 68 Summary Application State can be used for objects to be shared among all users of an app. Stored in server memory. Take care not to use excessive memory. If objects are updated, use concurrency control. End of Presentation