It appears for asp.net pages the term "app data" refers to data which is common to ALL users whereas the term "session data" refers to data which is specific to a given user session (and does not persist between log-ins).
However, the definition appears to change when discussing the Windows 8 app life-cycle.
For Windows 8 apps, it appears the term "app data" refers to data specific to a given user (and does persist between log-ins), whereas "session data" appears to refer to data specific to a given log-in session.
The on-line Microsoft tutorials appear (to me) a little vague in their classification of "app data" and "session data". It appears (again to me) that "app data" is simply any data that you want to persist between sessions (or suspend-terminated events) and session data is just data that you don't want to see between sessions (or suspend-terminated events)
Is my understanding correct? Is the definition of "app data" and "session data" simply just a matter of how that data is stored and retrieved between sessions (ergo - not really a data decision, but a design decision)?
Thanks.
Putting terminology aside for a moment, it's good to just look at app state and what's required of it.
First, there are settings and configurations that should always persist whenever the app is run, like accounts a user has set up, his or her preferences, and so forth. These settings would be loaded whenever and however the app is launched, e.g. from a tile, through a contract, etc. Typically this state is saved whenever it changes.
Second, if an app is suspended and then terminated by the system, and later switched to again by the user (tile or left swipe, etc.), we ask that apps preserve the perception that it was always running and hadn't been shut down. For this case, apps need to save more ephemeral state like the nav stack, unsubmitted forms data, current panning positions, and so forth, such that if it's restarted after being terminated it can reload this state and appear as it was before. The suspending event is when you make sure such state is saved, though oftentimes it's convenient to save it when it changes.
All of this state can be classified as "app data," but I prefer to use "app data" for the first (persistent) state and "session data" or "session state" for the second (ephemeral). I use these terms in the talks I've given at //build called, "The Story of State" (see here for 2013 talk, which is the 2012 talk slightly modified).
You correctly identify that terminology aside, it's really a matter of defining the stateful experience for your app, and then using the app data (and/or WinJS) APIs to save/load whatever state you need at whatever time. What you call it is quite irrelevant, because it's all stored in the same place in the end. The main difference is when you load or do not reload it.