Posts

Soon after the release of Visual Studio 2017, the Visual Studio Team Services team has added a Hosted VS2017 build agent that has support for all the latest and greatest technologies. Unfortunately although the build task with Visual Studio 2017 is itself present, the newest version of NuGet wasn’t added, yet. Fortunately, it is possible to use a custom nuget.exe to circumvent this issue and be able to restore packages for project using the new csproj format with <PackageReference>. Continue reading “Using custom nuget.exe in VSTS build process”

While developing mobile apps, you may encounter the need to clear or pop the navigation stack to remove specific pages from appearing when the user navigates back. BecauseMvvmCross framework has a lot of abstractions above the target operating systems, it does not contain a built-in mechanism to manipulate the back stack. How can we use the framework capabilities to implement this requirement in a clean fashion?

Universal Windows Platform runs on many different device families. To make the app look great on different devices, we can usually use AdaptiveTriggers, which react to different screen sizes. But if we require even more specificity, we can create a device family-based state trigger. Continue reading “Device family state trigger in UWP”

The UWP ListView and ListBox controls can be used to present lists of items in the user interface. By default the items are left-aligned and take up just the space they require, which is unfortunate if you want to stretch them to the full available width of the list control. How to achieve that?

The
CommandBar control is a vital component of UWP app design. It is an evolution of the
AppBar concept, which was available ever since Windows Phone 7, but with UWP is much more feature complete. One thing that is still missing however is the option to choose the direction in which the command bar opens.

Problem

The default behavior of the
CommandBar is to open in the up direction whenever the control is not at the very top of the window. This is an issue, because this holds true even when we define a custom title bar on Desktop, in which case the
CommandBaropens below the window’s minimize, maximize and close buttons which doesn’t look good at all.

The default template

The default template of the
CommandBar control defines the states of the control as a collection of
VisualStates and
VisualStateTransitions . It turns out that there is always a separate visual state for down and up direction.

Inside these states you can see that the system just uses different values for some of the properties like
CommandBarTemplateSettings.ContentHeight vs
CommandBarTemplateSettings.NegativeOverflowContentHeight for the
Y property of
OverflowContentRootTransform .

Solution

We cannot easily change the inner logic of the control itself, but we can make the control in up-open state look identical as it does for down-open state. This can be achieved purely by copy-pasting the
Storyboards from
...OpenDownvisual states and visual state transitions to the respective
...OpenUp counterparts. Unfortunately the manual copy-pasting is the only option, because extracting the
Storyboards into separate resources and referencing them with
{StaticResource} isn’t supported.

To get a full copy of the default control style you can use either the XAML Designer (right-click the control, select Edit Template and Edit a Copy…), or search for it in
C:\Program Files (x86)\Windows Kits\10\DesignTime\CommonConfiguration\Neutral\UAP{version}\Generic\generic.xaml

The Visual Studio XAML Designer for Universal Windows Platform offers design-time device previews for several different screens size and scaling combos. Unfortunately, the default selection might not be sufficient for you in some cases, especially when you want to optimize for a specific screen. Is it possible to expand the selection with more devices?

While working on an UWP app, I wanted to create a
string.Format based value converter, so that I could provide a format string in the
ConverterParameter , augment the data bound value with it and use the result as a key for a localized string from resources. When I tried to build the project however, I was met with the following cryptic error message:

C#

1

2

3

Child node "2" exited prematurely. Shutting down.

Diagnostic information may be found in files in the

temporary files directory named MSBuild_*.failure.txt.

Although the nor the error nor the generated diagnostic were too helpful, because I have mostly added just the new XAML binding, I suspected the error must be hidden there.

C#

1

2

3

{Binding

Converter={StaticResource TypeNameLocalizingConverter},

ConverterParameter={0}_Description}

As you might expect, it is not possible to use curly brackets directly inside the XAML binding expression.

Solution is simple – escaping with backslash.

C#

1

2

3

{Binding

Converter={StaticResource TypeNameLocalizingConverter},

ConverterParameter=\{0\}_Description}

With this little change, the code will compile and the value converter works as expected.

Universal Windows Platform includes the ApplicationData API, that provides easy way to store and retrieve application and user settings. If you use it to read settings very often however, you might run into performance problems. How to deal with them? Continue reading “UWP application settings performance”