StorageApplicationPermissions in WinRT

Windows 8 and now also Windows Phone 8.1 enable apps access to the filesystem. This API is very limited unfortunately (primarily for security reasons), so by setting several Capabilities in app’s manifest you can access directly just a few basic pseudo-folders – libraries Pictures, Music and Videos (and for enterprise apps in Windows 8 also Documents), but access to other folders directly is only possible through pickers. These return a non-persistent file/folder object, that can’t be accessed after the app closes or terminates.  StorageApplicationPermissions class comes to the rescue. Continue reading “StorageApplicationPermissions in WinRT”

Removing touch highlights on smartphones

When you are testing your websites on your favorite smartphone, you might find out, that Windows Phone and iOS are including a special behavior when any links on the page are pressed – sort of a highlighting – graying out of the active touched area. This is of course quite helpful sometimes when the bounds of active links on the small screen are hard to discern, but at the same time it can in some cases be quite unfriendly and interfering with your site’s design.

How can we prevent it? Let’s see for both operating systems! Continue reading “Removing touch highlights on smartphones”

Showing more stuff on Windows 8.1 tablets and laptops

I recently discovered a great feature of new Windows 8.1 Modern UI, that enables owners of high resolution tablets and laptops to display much more content at once (for the price of making things smaller).

Microsoft Surface Pro 2 with Full HD display will by default show the Start Screen in a fashion similar to this: startscreennormal

As you can see I get four rows of medium sized tiles. Also in normal setup, the device is capable of showing at most two Windows Store apps at once with multitasking.

Now let’s try to tune it up a little!
Continue reading “Showing more stuff on Windows 8.1 tablets and laptops”

ItemsSource and SelectedItem

Quite a common mistake that XAML developers do here and there (especially myself, I just can’t stop causing this bug…) is to switch the order the ItemsSource and SelectedItem properties in XAML while building a MVVM pattern based app.

Let’s see it in context the WinRT ListView control. To bind some items to it we use the ItemsSource dependency property. To select one of them we bind to SelectedItem.

Looks great right? Not yet.

XAML parser processes the file in the left right order. This way the first dependency property it faces is the SelectedItem. Here it tries to select the item in the collection, but unfortunately, it cannot be found. In that moment the SelectedItem of the ListView is actually set back to null. Now the ItemsSource is reached normally, but it is too late to get the SelectedItem back “from the dead”.

The correct order only when SelectedItem is placed behind the ItemsSource. Then we get the desired results and will no longer get unexpected, hard to decode behavior.

 The devil is in the details.

Localization in WinRT not working?

This week I had to deal with very strange behavior when trying to localize a Windows 8.1 app in Czech and English.

As always, I prepared a special localization class, added the *.resw files for en and cs and finally hooked it all up to XAML via binding. Everything seemed hunky-dory except for the tiny fact that only English (language neutral) variant of the app was functional. The situation got even stranger when I replicated the exact same set-up in a new project and it worked normally.

After a longer search I found the hidden cause of the problem.
The Package.appmanifest file, that stores different package-related settings of the resulting Windows 8.1 app package has numerous options, that are not available directly via the designer. In fact, the AppManifest file is just a XML file with a fancy extension, that can be edited directly. In Visual Studio 2013 click the right mouse button on this file and select the Open With… or View Code command.

Opening Package.appmanifest in XML editor

The source of my problems was one of the elements in manifest file – element Resources to be exact. This element influences the behavior of resource files in the project and more importantly its contents describe which languages the app supports. In my case it contained just one – the english variant:

To support other languages, I would have to repeat the Resource element with other ISO codes of languages I need. This would be too much of a burden and not very practical. A better solution is the form that is actually set as default in newly created Windows 8.1 projects:

Special constant x-generate specifies, that while the package is constructed, the required localizations are automatically generated on the basis of what language *.resw are present in the project.