About some features of Windows 8 and WinRT (metro) applications

We are talking about a new type of application that are designed for the new Windows 8 operating system and the new Start menu. I want to immediately note that in spite of everything described below, I liked the technology, but Microsoft’s traditional approach - “to do everything well, but something most often used is bad” - is observed in all its glory. If you programmed for WPF or Silverlight, then creating WinRT (metro) applications - in terms of programming the interface - will not cause any difficulties for you. Moreover, individual new controls greatly simplify the design of interfaces, but it’s better to read some useful book about it . All pitfalls are different.

Firstly, you can safely forget about full access to any folders and files on the computer that the user with whose rights your program is running will have access to. Yes, even if it is an administrator. And yes! Another surprise is that UAC for metro applications does not work either. In the sense - that it is now only for regular (old) applications.

The second one. You can still work with files on a computer, but not without difficulties. In particular, your application may have access to the following places:
  1. Libraries: Documents, Videos, Images, Music
  2. User Downloads folder
  3. Application folders in user profile
  4. The folder where your application was installed
  5. The folder / file that the user has shared with you

So, let's start on the points.

1. Libraries.

Remember this strange thing that appeared back in Vista, but which almost no one used? (Well, at least I just didn’t use it - from Far it is somehow completely uncomfortable)

Rejoice! Now you will love to use them.

Standard applications Music, Video, Photos work only with libraries. Although, of course, you can open any file there, but if you do this from the applications themselves, it’s inconvenient, and if you open through the explorer, well, this is the explorer, it is itself inconvenient. However, not everything is so simple - your application needs to explicitly indicate which libraries it needs access to. Moreover, it will receive full and unlimited access and can add / delete / move any files and folders, as well as read and write to any file.

Note: I still did not find information whether it is possible to access the library that the user himself created (i.e. not one of the above). At the moment, everything looks so that such access cannot be obtained without the participation of the user.

The “Documents” library stands apart, access to which you simply cannot get - you must first specify the types of files (extensions) that our application will work with: Where library folders are located, you do not need to find out - you can access them through the KnownFolders class

2. User Downloads folder

Well, everything is simple - write access only. You can create a file without user intervention and write something there.

3. Application folders in the user profile

We have two folders: Local and Roaming. One lies on the current computer, the other moves if the user profile is stored centrally, for example, on a domain controller. In general, everything is as before (see the folder C: \ Users \ ”user” \ AppData \ subfolders of Local and Roaming), only now only your application has access to these folders.

4. The folder where your application was installed

Your application has full access to any file / folder and can do whatever it wants with them.

5. The folder / file that the user has granted access to you

And now, in fact, the most interesting.

The only way to get to a folder / file that is not in the places listed above is only through the use of the FolderPicker and FilePicker classes .

This is done like this:
FolderPicker fp = new FolderPicker();
fp.ViewMode = PickerViewMode.Thumbnail;
StorageFolder folder = await fp.PickSingleFolderAsync();
if (folder == null) return;
var files = await folder.GetFilesAsync();
foreach(var file in files)

After which the user will see this window: And you get full access to the selected user. By the way, did you notice async / await ? Get used to it - there are no more synchronous functions. Well, at least those that are most often required. For example, if earlier you could read data from a file with one line of the form:

string[] lines = File.ReadAllLines("filename.txt"); 

Now it will be something like this:
IList lines = await ReadFileAsync("filename.txt"); 

By the way, a surprise - MessageBox is no longer :) Now again this will be something like:
await ShowMessage(“Текст”);

And here we come across another problem: await can only be used in functions marked async. Naturally, not every function can be marked like this.
In this case, it helps to put all the necessary code into a separate function, and then in the right place for us to wait for its completion:
public async Task MyAsyncFunction()
	return await …;
public MySyncFunction()
	var res=MyAsyncFunction();
	if(res.Result==...) ...;

Однако такой код иногда виснет, но не падает. Поэтому отлаживать его — одно удовольствие.


Как я уже писал выше — в целом, технология интересная, однако, если ваше приложение хочет активно работать с файлами на дисках, да еще и в тайне от пользователя — то это не ваш выбор. Зато сделать приложение, которое будет загружать и рисовать кошечек с интернета можно буквально не прикасаясь к клавиатуре

Also popular now: