A question on the MSDN JavaScript apps forum recently asked why the app data APIs were in Windows.Storage.ApplicationData whereas the app's package folder property is off in Windows.ApplicationModel.Package. I responded with the following comments, which Howard Kapustein confirmed (he did much of this wrangling early on).

I don't know the exact history (this would've been taking place in early 2011) but I imagine it could've gone either way and someone eventually had to make a decision. Generally speaking, Windows.ApplicationModel has package information along with a bunch of APIs that deal with app-to-app communication, contracts, activation, suspend/resume, and background tasks. Windows.Storage, on the other hand, has everything to do with the file system.

Because appdata folders are probably more closely aligned with the file system than with the "app model" stuff, I can see why Windows.Storage was the landing place. After all, that's where you find all the other file I/O APIs, and I can imagine that if the ApplicationData APIs were in Windows.ApplicationModel, we'd be having the same question about why they weren't in Windows.Storage. 🙂

I would guess that there was probably an argument for putting the package information classes into Windows.Management.Deployment, which is probably it's most natural home. However, the rest of the APIs there are desktop-only and not accessible to Store apps, so it made some sense to put the Package class elsewhere. I expect this decision was probably made well after the decision to put ApplicationData into Windows.Storage.

It's also worth noting that the appdata folders are not technically part of the package, so it's really the installedLocation property that's the aberration. The rest of the Package and PackageId properties come from the Store and describes the package characteristics more than runtime state. Thus installedLocation just so happens to be the link between all the package info and the file system.

In the end, I think the structure that we have actually makes the most sense, because when you start talking about appdata you automatically end up in Windows.Storage.

Knowing the guys in API naming team that bandied all this kind of stuff about (guys like Harry Pierson, Jason Olson, and Brent Rector–and now I can add Howard Kapustein as well), I expect that they discussed all these pros and cons before making a decision. Howard describes it as "sausage making" if you want a great visual image!

When working with the Windows.Storage.AccessCache.StorageApplicationPermissions.FutureAccessList, it’s important to know that it has a 1000 file limit. This has presented a challenge to some developers working with libraries that contain many more files than that, when they try to save every file in the library in this list. Of course, the problem is solved easily by saving the parent StorageFolder in the list instead, which will then include all those files. Sometimes, however, you might want to save a handful of files directly for performance reasons–files that you know you’re going to want, so you don’t have to go through the folders each time.

I’ll mention in this context that I’ve seen discussions about this sort of thing where developers talk about file paths and so forth. When working with files and folders in WinRT, always remember that the StorageFile and StorageFolder objects (and their shared StorageItem base class) are abstractions for path names and should be what you use whenever you think about path names. The key reason for this is that file-like entities can be backed by non-local providers such that the concept of a “pathname’ doesn’t even exist. The StorageFile/Folder/Item abstractions let the provider worry about the mapping details. For the consuming app, then, you use the FutureAccessList to do the equivalent of saving pathname strings in some other local storage. (The same goes for the recently used list that exists alongside FutureAccessList.)

Equally interesting is the question of what happens if files are moved on the file system between when you save a StorageFile to the FutureAccessList and when you later retrieve it. Generally speaking, Windows does its best to track changes to the file system and update the FutureAccessList accordingly, so the bottom line is that you should not worry about it. Of course, if you attempt to open a file obtained from the FutureAccessList, it can fail for any number of reasons, including the file having been moved without the system being able to track it. You have to handle all such exceptions anyway, so an orphaned file is just one in the mix.