DeutschEnglish

Jan 27

A multi-tap behavior for Windows Store Apps #3

After setting up the basic structure of our behavior and filling it with interactions, the most important step is still missing: In this blog post, we’ll learn how to teach our behavior to trigger commands and other actions!

A simple approach towards triggering Commands:

Similar to the TapCount property, we can also define a dependency property called Command of type ICommand:

public static readonly DependencyProperty CommandProperty = DependencyProperty.Register(
	"Command", typeof(ICommand), typeof(MultiTapBehavior), new PropertyMetadata(default(ICommand)));

public ICommand Command
{
	get { return (ICommand) GetValue(CommandProperty); }
	set { SetValue(CommandProperty, value); }
}

For the sake of completeness, we should also add a similar dependency property of type object that is called CommandParameter – I won’t show the code for this as it’s really similar to the two existing dependency properties, you can check out the full code on GitHub. The only important issue is to pass null as the dependency property’s default value, so that null is passed to the Command if specifying no command parameter in XAML.

This should allow anyone who makes use of our behavior to specify a Command to be invoked when the multi-tap interaction is recognized. Of course, the actual invocation needs to be done by our RegisterTap method – we simply replace the breakpoint by the following lines:

if (_currentTapCount >= TapCount)
{
	// If TapCount threshold is met, execute the given Command...
	if (Command != default(ICommand))
	{
		if (Command.CanExecute(CommandParameter))
			Command.Execute(CommandParameter);
	}

	// ...and reset the tap counter
	_previousTapTime = null;
	_currentTapCount = 0;
}

In XAML, usage of this first fully working version of our behavior looks as follows:

<Image Source="somepic.png">
    <interactivity:Interaction.Behaviors>
        <helpers:MultiTapBehavior TapCount="3"
								  Command="{Binding SomeCommand}"
								  CommandParameter="optional_parameter_value" />
    </interactivity:Interaction.Behaviors>
</Image>

Triggering arbitrary actions:

This far, the Command invocation works fine. However, some developer might wish to invoke more than one Command, or even trigger any other action (such as invoking a method on another control, navigating to another page, etc.).

The Microsoft.Xaml.Interactions.Core namespace offers various predefined actions, and in addition it’s possible to define custom actions to be triggered by behaviors. Unfortunately, our MultiTapBehavior can’t cope with these actions.

We can change this in three simple steps:

  • First we need to introduce a dependency property of type ActionCollection. For obvious reasons, we call it Actions:

    public static readonly DependencyProperty ActionsProperty = DependencyProperty.Register(
    	"Actions", typeof(ActionCollection), typeof(MultiTapBehavior), new PropertyMetadata(null));
    	
    public ActionCollection Actions
    {
    	get
    	{
    		ActionCollection actionCollection = (ActionCollection) GetValue(ActionsProperty);
    		if (actionCollection == null)
    		{
    			actionCollection = new ActionCollection();
    			SetValue(ActionsProperty, actionCollection);
    		}
    		return actionCollection;
    	}
    }
    

    Note the missing setter as well as the getter that ensures that a new ActionCollection is instantiated when passing null.

  • In addition, we need to tell our behavior that actions can be specified as XML child nodes. This is done by the ContentProperty attribute:

    [ContentProperty(Name = "Actions")]
    public class MultiTapBehavior : DependencyObject, IBehavior
    {
    	...
    }
    

    Without this attribute, developers would need to explicitly reference the behavior’s Action property from within XAML:

    <MultiTapBehavior TapCount="3">
    	<MultiTapBehavior.Action>
    		<core:InvokeCommandAction ... />
    	</MultiTapBehavior.Action>
    </MultiTapBehavior>
    

    By specifying the behavior’s Acion property as its ContentProperty, this can be reduced to:

    <MultiTapBehavior TapCount="3">
    	<core:InvokeCommandAction ... />
    </MultiTapBehavior>
    
  • Finally, we need to invoke all those actions that might be specified within the ActionCollection, using the ExecuteActions method. We change the last part of our RegisterTap method as follows:

    if (_currentTapCount >= TapCount)
    {
    	// If TapCount threshold is met, trigger the specified actions...
    	Interaction.ExecuteActions(AssociatedObject, Actions, null);
    
    	// ...and reset the tap counter
    	_previousTapTime = null;
    	_currentTapCount = 0;
    }
    

…and that’s it! we should now be able to specify any actions to be invoked by our behavior:

<Image Source="somepic.png">
    <interactivity:Interaction.Behaviors>
        <helpers:MultiTapBehavior TapCount="3">
			<core:InvokeCommandAction Command="{Binding SomeCommand}" />
			<core:CallMethodAction MethodName="MyMethod" TargetObject="{Binding SomeObject}"/>
			<core:NavigateToPageAction TargetPage="SomePage"/>
			...
        </helpers:MultiTapBehavior>
    </interactivity:Interaction.Behaviors>
</Image>

The full project:

I decided to combine the two approaches suggested in this blog post: The Actions property is absolutely necessary for specifying a collection of arbitrary actions, but the Command property in combination with CommandParameter is a convenient solution for the most common action (and one that saves two lines of XAML code, making the markup more readable).

By the way, if you want to reconstruct the code I’ve shown only in parts: The full MultiTapBehavior is available on GitHub!

Permanent link to this article: http://www.mobilemotion.eu/?p=1710&lang=en

Jan 22

A multi-tap behavior for Windows Store Apps #2

In the first part of this article, we discussed the basic structure of a custom XAML Behavior. Now, let’s fill it with the actual interaction logic!

The core logic:

As mentioned before, we’d like to wait until the user has tapped our UI element a given amount of times. To do so, let’s create a few fields and a helper method:

private const int TapCount = 5;
private int _currentTapCount = 0;
private DateTime? _previousTapTime = null;

private void RegisterTap()
{
	// TODO: count number of taps, and invoke command
}

private void ElementOnTapped(object sender, TappedRoutedEventArgs tappedRoutedEventArgs)
{
	RegisterTap();
}

For the sake of simplicity, we begin with a fixed threshold of 5 taps (a command shall be invoked after tapping the UI element for 5 times). The RegisterTap method is responsible for incrementing the number of taps and remembering the time when the last tap occured – we will implement it shortly. Finally, the UI element’s Tapped event handler simply calls this helper method.

In detail, the RegisterTap method does the following:

  • Store the current time
  • Compare the current time to the time when the previous tap has occured (two taps shall only be counted as part of a multi-tap interaction if they occur within 2 seconds)
  • Increase the tap counter, or set it to 1 if the previous tap dates back more than 2 seconds
  • Invoke some command, if 5 (or more) subsequent taps have been detected

Translated to C# code, this might look as follows:

private void RegisterTap()
{
	var now = DateTime.Now;
	if (!_previousTapTime.HasValue)
	{
		// This is the first tap ever
		_previousTapTime = now;
		_currentTapCount = 1;
	}
	else
	{
		// Two taps must occur within 2 seconds to be counted as part of a multi-tap gesture
		if ((now - _previousTapTime).Value.Seconds <= 2)
		{
			_previousTapTime = now;
			_currentTapCount += 1;
		}
		else
		{
			_previousTapTime = now;
			_currentTapCount = 1;
		}
	}

	if (_currentTapCount >= TapCount)
	{
		// If TapCount threshold is met, execute the given Command...
		// TODO
		// ...and reset the tap counter
		_previousTapTime = null;
		_currentTapCount = 0;
	}
}

Since there is no command registered yet, we skip the last part of this method for now. I suggest to set a breakpoint there instead, we’ll complete the RegisterTap method later on.

By now we should be able to test our custom behavior. To do so, add its namespace to the XAML Page’s header, and attach it to any UI element! In the following example, I decided to use an Image control as host:

<Image Source="somepic.png">
    <interactivity:Interaction.Behaviors>
        <helpers:MultiTapBehavior />
    </interactivity:Interaction.Behaviors>
</Image>

When tapping the image 5 times, our breakpoint should be reached. If you are not able to reproduce this, try tapping more than 5 times (in a later section, I’ll explain why this might be necessary).

A parameterized behavior:

As an improvement to this first version, we could allow setting the desired tap count threshold in XAML instead of hard-coding it in the core behavior. To do so, we replace the TapCount constant with a Dependency Property of type int:

public static readonly DependencyProperty TapCountProperty = DependencyProperty.Register(
	"TapCount", typeof (int), typeof (MultiTapBehavior), new PropertyMetadata(5));

public int TapCount
{
	get { return (int) GetValue(TapCountProperty); }
	set { SetValue(TapCountProperty, value); }
}

As the last parameter of the DependencyProperty.Register method, we can pass the property’s default value. In this case, setting it to 5 ensures that the TapCount can, but doesn’t need to be set in XAML (if it is not, it will equal to the defaul value specified here).

In the XAML declaration, it’s now possible to specify the desired TapCount value:

<Image Source="somepic.png">
    <interactivity:Interaction.Behaviors>
        <helpers:MultiTapBehavior TapCount="3" />
    </interactivity:Interaction.Behaviors>
</Image>

The double-tap issue:

As you might have noticed, even if specifying 5 as TapCount sometimes the behavior needs 6 or 7 actual taps to react. The reason for this is that if tapping too fast, the control interprets this as double tap, however we don’t explicitly handle its DoubleTapped event.

There are two solutions to this:

  • The control’s double-tap recognition can be disabled completely through the IsDoubleTapEnabled property. This could be done in the behavior’s Attach method:

    public void Attach(DependencyObject associatedObject)
    {
        var el = associatedObject as UIElement;
        if (el != null)
    	{
    		el.IsDoubleTapEnabled = false;
            el.Tapped += ElementOnTapped;
    	}
    }
    

    This forces the control to not fire the DoubleTapped event at all, which is not the optimum solution as it limits developers who make use of our behavior.

  • A better approach is to handle the control’s DoubleTapped event explicitly. In the behavior’s Attach method, we register to it:

    public void Attach(DependencyObject associatedObject)
    {
        var el = associatedObject as UIElement;
        if (el != null)
    	{
            el.Tapped += ElementOnTapped;
            el.DoubleTapped += ElementOnDoubleTapped;
    	}
    }
    

    …and in the ElementOnDoubleTapped event handler, we simply call our well-knwon helper method for counting taps:

    private void ElementOnTapped(object sender, DoubleTappedRoutedEventArgs tappedRoutedEventArgs)
    {
    	RegisterTap();
    }
    

    This is a bit tricky and misleading: You might think we should invoke this method twice, as a double-tap event corresponds to two singe taps which both need to be registered. However, as stated on MSDN, when registering to both the Tapped and the DoubleTapped event of the same control, Tapped will fire first to represent the first tap, but the second tap won’t fire an additional Tapped. This means that the first part of a double-tap interaction is already handled by our Tapped event handler, such that the DoubleTapped event handler needs only register the second tap.

Triggering actions and commands:

There is only one thing left our behavior can not yet do: Triggering actions instead of simply running into a breakpoint. Join me on the third and final part of this article to complete this last step!

Permanent link to this article: http://www.mobilemotion.eu/?p=1700&lang=en

Jan 19

A multi-tap behavior for Windows Store Apps #1

Today I’d like to demonstrate the use of custom XAML Behaviors to allow Windows Store Apps support advanced user interactions. As an example, we’ll create a multi-tap behavior that allows invoking a custom command whenever the user taps an element several times.

The background:

Most XAML controls offer a Command property that allows binding a command defined in the Viewmodel to the control’s most common event – e.g., in case of a Button, the given command would be executed on the Tapped event. Most controls, however, offer a variety of additional events that can be triggered by the user, which can not be bound directly to an MVVM command. The typical workaround would be to register a traditional event handler, and invoke the desired command in code-behind – but wouldn’t it be delightful to specify the connection between event and command directly in XAML code? Fortunately, behaviors are at our service!

Let’s assume we want to invoke a certain command on a button’s DoubleTapped event. For using XAML Behaviors, we first need to reference the Behavior SDK which is available as an extension to the WinRT framework: Right click References in the Solution Explorer, choose Windows > Extensions in the Reference Manager window, and select the Behaviors SDK (XAML) entry:

Add a reference to the Behaviors SDK 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

In addition, we need to register two namespaces within the page that contains the button:

<Page
	xmlns:interactivity="using:Microsoft.Xaml.Interactivity"
	xmlns:core="using:Microsoft.Xaml.Interactions.Core" />

Now we can use predefined behaviors and actions (the EventTriggerBehavior and the InvokeCommandAction) to react to the button’s DoubleTapped event by invoking a command:

<Button>
	<interactivity:Interaction.Behaviors>
		<core:EventTriggerBehavior EventName="DoubleTapped">
			<core:InvokeCommandAction Command="{Binding SomeCommand}" />
		</core:EventTriggerBehavior>
	</interactivity:Interaction.Behaviors>
</Button>

A custom behavior:

Now it’s getting interesting: What if we’d like to react to a custom interaction that is not yet covered by an existing event? We’re simply building our own behavior!

A behavior basically is a class that implements the IBehavior interface. Its name typically ends with …Behavior. In addition, we’ll need a few dependency properties, so our behavior class should also inherit from DependencyObject.

Due to implementing IBehavior, a behavior must contain the Attach and Detach methods as well as an AssociatedObject property:

public class MultiTapBehavior : DependencyObject, IBehavior
{
	public void Attach(DependencyObject associatedObject)
	{

	}

	public void Detach()
	{

	}

	public DependencyObject AssociatedObject { get; private set; }
}

Our behavior shall react when the user taps an element for a given amount of times – technically speaking, when the element’s Tapped event has been fired several times. Therefore, we register an event handler within the Attach method:

public void Attach(DependencyObject associatedObject)
{
	var el = associatedObject as UIElement;
	if (el != null)
		el.Tapped += ElementOnTapped;
}

private void ElementOnTapped(object sender, TappedRoutedEventArgs tappedRoutedEventArgs)
{
	// TODO: count number of taps, and invoke command
}

The Attach method is called when the behavior is attached to the visual element – if specifying the behavior in XAML code as shown in the DoubleTapped example above, this happens when loading the element for the first time. The actual element the behavior is attached to is passed as argument, since we assume that this is a visual element that has a Tapped event we cast it as UIElement. The important thing here is to use the associatedObject variable that is passed as method parameter, and not the property AssociatedObject, since the latter will contain the element only after the Attach method has been invoked!

As it is good manners, we should clean up after using the behavior: In the Detach method we should not forget to unregister the event handler:

public void Detach()
{
	var el = AssociatedObject as UIElement;
	if (el != null)
		el.Tapped -= ElementOnTapped;
}

This method does not contain any parameter, since here we can make use of the global AssociatedObject property.

The core logic:

By now, the basic structure of our behavior is done, and we can use the event handler to react on user input – I’ll show you more about this in the second part of this article!

Permanent link to this article: http://www.mobilemotion.eu/?p=1704&lang=en

Jan 03

MVVM and compiled bindings

While the new Windows 10 Universal Windows Platform compiled bindings feature sets standards in terms of resources and performance, it makes following the MVVM pattern more difficult than with traditional binding. In this article, I’d like to propose a standardized way of maintaining the separation of view from business logic while still profiting from the x:Bind binding syntax.

Undoubtedly we should use the new x:Bind syntax in Windows 10 Apps whenever possible, as it promises not only improved runtime performance but also compile-time safety for XAML code. At the same time we need to be aware that x:Bind follows a different binding paradigm than traditional {Binding} syntax: Data bindings specified by the {Binding} markup extension are evaluated on an object’s current DataContext, while {x:Bind} data bindings always relate to the view object itself (e.g., the Windows.UI.Xaml.Controls.Page class). This means that properties referenced in an x:Bind statement are typically expected to be declared in the page’s code-behind.

The technical reasons for this difference are obvious: Any visual object’s DataContext might change at runtime, so it’s not possible to ensure whether a data binding to any property declared by the DataContext object is valid at compile-time. However, according to the MVVM pattern bindable properties are mostly declared in Viewmodels, not in the View’s code-behind. This conflict becomes even more obvious when looking for a reusable MVVM solution defining base classes for Views and Viewmodels (for this example, let’s assume that such base classes exist and are called BasePage and BaseViewmodel).

I was facing this problem when adapting the MVVMbasics framework to work with the UWP platform. The key problem is that the Viewmodel type assigned to the View (i.e. the Page object) needs to be specified at compile time. The proposed solution satisfies this requirement by defining a simple generic interface each Page needs to implement:

public interface IBindableView<T> where T : BaseViewmodel
{
	T Vm { get; set; }
}

I called the interface IBindableView to indicate that all View objects that want to specify data bindings to a certain Viewmodel need to implement it. The interface expects one type parameter that corresponds to the type of Viewmodel to be assigned to a certain View, and it contains one property of the same type. This forces any View that implements the interface to also define a Vm property, which in turn can be used for binding later on.

Now we need to ensure that this Vm property is populated with the correct Viewmodel instance. I assume that the View’s Viewmodel instance is assigned to its DataContext property as in traditional binding (most applications will do this anyway as they still might contain one or the other traditional {Binding} expression, since x:Bind can’t yet cover all use-cases). Therefore, let’s register to the View’s DataContextChanged event – unsurprisingly, this event is fired each time the view’s DataContext changes. The event handler is responsible for the following steps:

  1. Check whether the current content of DataContext is derived from our BaseViewmodel,
  2. check whether the page implements the IBindableView interface,
  3. retrieve its Vm property, and
  4. set it to the current DataContext value!
public abstract class BasePage : Page
{
	public BasePage()
	{
		DataContextChanged += Page_DataContextChanged;
	}
	
	private void Page_DataContextChanged(FrameworkElement sender, DataContextChangedEventArgs args)
	{
		// Retrieve the current DataContext value - this is the Viewmodel instance
		var vm = DataContext as BaseViewmodel;
		if (vm == null)
			return;

		// If implementing the IBindableView interface, store the current viewmodel in the view's Vm property
		if (this.GetType().GetTypeInfo().ImplementedInterfaces
			.Any(i => i.GetTypeInfo().IsGenericType && i.GetGenericTypeDefinition() == typeof(IBindableView<>)))
		{
			var vmProperty = this.GetType().GetRuntimeProperty("Vm");

			if (vmProperty != null)
			{
				vmProperty.SetMethod.Invoke(this, new[] { vm });
			}
		}
	}
}

Let’s take a look at a sample Page that makes use of our interface:

public sealed partial class MyPage : BasePage, IBindableView<MyViewmodel>
{
	public MainPage()
	{
		this.InitializeComponent();
	}

	public MyViewmodel Vm { get; set; }
}

In XAML, all it takes now is to route all data bindings to the Viewmodel instance by referencing the Vm property:

<TextBox Text="{x:Bind Vm.SomeText}" />
<Button Command="{x:Bind Vm.MyCommand}">Button caption</Button>

This approach offers full MVVM-binding with minimum effort for developers, as it’s only necessary to comply with three simple requirements:

  • Make each View implement IBindableView and specify its Viewmodel type
  • Create a public property Vm in each View’s code-behind
  • Prefix all data bindings with Vm.XYZ in XAML

Permanent link to this article: http://www.mobilemotion.eu/?p=1689&lang=en

Dec 07

UWP and the missing StringFormat binding property

One of the major new features of the Windows 10 Universal Windows Platform is the use of compiled bindings through the x:Bind markup extension. Due to UWP still being rather new, it lacks some of the options traditional data bindings in WPF can offer. One example is passing a custom format for bindings that are displayed as string.

For example, when using the traditional {Binding} syntax in WPF to display a DateTime value in a TextBlock, we can specify the exact display format using the StringFormat binding property:

<TextBlock Text="{Binding DateValue, StringFormat=Date: {0:dddd yyyy-MM-dd}}" />

The text that is passed to the StringFormat binding property will be displayed, and the {0} part will be replaced by the actual content of DateValue, just as the String.Format method would do. After {0:, we add the actual format string, following the rules for custom date and time formats – of course, we could format numeric values in the same way.

In UWP, neither {Binding} nor {x:Bind} syntax provide a StringFormat binding property. Fortunately, we can use a simple value converter to achieve the same thing:

public class StringFormatConverter : IValueConverter
{
	public object Convert(object value, Type targetType, object parameter, string language)
	{
		var format = parameter as string;
		if (!String.IsNullOrEmpty(format))
			return String.Format(format, value);

		return value;
	}

	public object ConvertBack(object value, Type targetType, object parameter, string language)
	{
		throw new NotImplementedException();
	}
}

When referenced as static resource either within the page or globally in the app, we can use this converter to specify the binding’s date format:

<Page.Resources>
	<local:StringFormatConverter x:Key="StringFormatConverter"/>
</Page.Resources>
<TextBlock Text="{x:Bind DateValue, 
						 Converter={StaticResource StringFormatConverter}, 
						 ConverterParameter='Date: {0:dddd yyyy-MM-dd}'}" />

This approach is perfect for varying format strings. But what if you want to display several percentage values, all formatted in the same way? You’d need to pass the format parameter to every single binding, and you couldn’t even define it in the ViewModel and bind it, since binding is not allowed for the ConverterParameter binding property. In this case, I suggest to modify the converter a bit:

public class StringFormatConverter : IValueConverter
{
	public string StringFormat { get; set; }
	
	public object Convert(object value, Type targetType, object parameter, string language)
	{
		if (!String.IsNullOrEmpty(StringFormat))
			return String.Format(StringFormat, value);

		return value;
	}

	public object ConvertBack(object value, Type targetType, object parameter, string language)
	{
		throw new NotImplementedException();
	}
}

(We could also define StringFormat as a dependency property instead of the simple auto-property to enable auto-update, but that’s another story.)

With this modification, it’s possible to define several instances of StringFormatConverter within the same page, all with a different purpose (by giving them different format strings):

<Page.Resources>
	<local:StringFormatConverter x:Key="PercentageStringFormatConverter" StringFormat="Value: {0:P2}"/>
	<local:StringFormatConverter x:Key="DateStringFormatConverter" StringFormat="Date: {0:dddd yyyy-MM-dd}"/>
</Page.Resources>

Finally, applying these converters is easy, as the ConverterParameter binding property is not necessary any more:

<TextBlock Text="{x:Bind DateValue, Converter={StaticResource PercentageStringFormatConverter}}" />

Obviously, both variants of the shown converter might be useful in certain cases, so it’s a good idea to include them both to be able to choose – or even combine both versions into one if you want to play around with it. Have fun!

Permanent link to this article: http://www.mobilemotion.eu/?p=1680&lang=en

Nov 24

C# 6 behind the scenes (part #2)

After examining how the compiler converts C# 6 language expressions to IL code in the first part of this article, let’s check a few additional examples in order to find out how C# 6 code behaves when parsed using reflection.

The nameof expression:

The nameof expression returns the name of some program element as string, which is useful e.g. for raising PropertyChanged events, throwing an ArgumentNullException etc. since it helps eliminating string literals.

If we add the following method to our sample program:

private string TestNameOf()
{
	return nameof(Program);
}

and compile and decompile it, ILSpy will show the following:

private string TestNameOf()
{
	return "Program";
}

which means that the type Program is replaced by the string "Program" during compilation. This won’t surprise you after the observations we made as part of the samples presented in the first part of this article.

In addition, let’s check what happens with the nameof expression during live code analysis using reflection: I added a new method called Start to our sample project which is invoked from within the program’s constructor. In this method, we define a lambda expression that makes use of the nameof operator, and analyse its content (in this sample, I anticipated that the lambda expression’s body will be a ConstantExpression – alternatively, you could of course parse the expression tree and will find out that this assumption is true):

private void Start()
{
	Expression<Func<string>> expression = () => nameof(Program);
	var constantExpression = expression.Body as ConstantExpression;
}

Now, set a breakpoint after the second line of code, start the program, and examine constantExpression! You’ll find out that the nameof expression evaluates to a constant expression that simply returns the string "Program" as its value:

C# 6 Nameof expression example 
 
 
 
 
 
 
 
 
 
 
 

String interpolation:

String interpolation is mature version of String.Format, as it eliminates the {0} etc. placeholders and instead allows to put the string expressions right into place:

private string TestStringInterpolation()
{
	string word = "interpolation";
	return $"The word {word} contains {word.Length} characters, which is more than {word.Length - 1}";
}

As you can see in the example above, it’s even possible to do calculations and other operations directly within the expressions to be replaces. During compilation, this code is converted to a traditional String.Format method call, as ILSpy shows:

private string TestStringInterpolation()
{
	string text = "interpolation";
	return string.Format("The word {0} contains {1} characters, which is more than {2}", text, text.Length, text.Length-1);
}

Now, let’s try string interpolation within a lambda expression:

private void Start()
{
	string word = "interpolation";
	Expression<Func<string>> expression = 
		() => $"The word {word} contains {word.Length} characters, which is more than {word.Length - 1}";
	var methodCallExpression = expression.Body as MethodCallExpression;
}

Again, I assumed that the expression’s body would be evaluated as a MethodCallExpression – and indeeed, when running the program and watching the methodCallExpression variable, it shows that the expression’s content is implemented as a call to the String.Format method with three placeholders:

C# 6 String interpolation example 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

The null-conditional operator:

The null conditional operator helps shorten null-checks, as it allows you to access object members only when the object is not null, and returns a null result otherwise. For example, the following method will return 43 which is the length of the given string:

private int TestNullConditional()
{
	string text = "The quick brown fox jumps over the lazy dog";
	return text?.Length ?? 0;
}

However, if we replace the given text with null and run the example again, the first part of the expression (text?) will instantly evaluate as null, and the null coalescing operator ?? will be reached, resulting in a return value of 0.

As we would expect by now, even this expression is converted to conventional syntax by the compiler:

private int TestNullConditional()
{
	string text = "The quick brown fox jumps over the lazy dog";
	return (text != null) ? text.Length : 0;
}

However, testing the same expression as part of a lambda expression ends with a surprising observation: The following code brings up a compile-time error:

private void Start()
{
	string text = null; //"The quick brown fox jumps over the lazy dog";
	Expression<Func<int>> expression = () => text?.Length ?? 0;
}

C# 6 Null-conditional operator example 
 
 
 
 
 
 
 
 

The reason for this as well as several potential solutions are discussed in detail on codeplex. The short version is: A conversion to a ConditonalExpression is not accurate in all cases, therefore a new type of expression (e.g. NullPropagationExpression) needs to be defined – however, since this would require changes in the .NET framework (not only in the C# compiler), current versions of .NET simply disallow the use of the ? operator in lambda expressions.

In summary, the good news is that all of the sample expressions discussed so far were replaced by conventional language expressions by the compiler. Therefore, anyone parsing code written in C# 6 will not be surprised by unexpected language structures. This, however, goes hand in hand with a small restriction when developing libraries and using lambda expression trees to be defined by other developers, as these developers will not be able to use the null-conditional operator due to the reasons discussed above.

Permanent link to this article: http://www.mobilemotion.eu/?p=1660&lang=en

Nov 18

C# 6 behind the scenes (part #1)

C# 6 brings a lot of new language features that can ease up a developer’s life. Technically, these are pure compiler features, meaning that no new version of the .NET framework is necessary – but what is going on behind the scenes, and what does the compiler actually do when it encounters code lines that contain the new syntax?

This question is especially interesting since C# code may be analysed or changed at runtime (using reflection) or after build (e.g., using libraries such as Mono.Cecil). This means that either

  • your code might be deconstructed by some framework you are using,
  • or (even more interesting), if you create libraries that can be used by other developers, you might want to parse parts of their code.

I came across this exact situation as part of my implementation of the ICommand interface: Any developer that makes use of this implementation may define certain conditions under which a command can be executed. These conditions are defined as lambda expressions, passed to the ICommand library, and then parsed and analysed by the code contained in this library (which, in course, has been written by me) – so I was wondering whether I needed to change the parsing process in order to cope with C# 6 expressions any developer might have used to express their condition.

The simple answer – fortunately – was no, although it’s good to know that there are certain restrictions. But let’s take a look at some examples to discuss this topic in detail:

Auto-property initializers:

C# 6 allows to add property initializers as part of the property declaration syntax. This applies to both “standard” and getter-only auto-properties:

public string GetterOnlyProperty { get; } = "SomeValue";

public string GetterSetterProperty { get; set; } = "AnotherValue";

Let’s take a look at how these expressions are handled by the compiler! In general, .NET code is not compiled into machine code directly. Instead, the C# compiler generates CIL (Common Intermediate Language) code which is interpreted by a virtual machine at runtime. One of the most convenient ways of analysing CIL code is the ILSpy application, as it lets you even decompile CIL code to C#.

Let’s copy the two lines of C# code shown above to an (otherwise empty) console application project, compile it, and load the resulting .exe file into ILSpy. As mentioned before, its possible to show the exact CIL code contained in our compiled application, but I recommend to switch the dropdown box in the menu bar from IL to C# – this activates decompilation mode and allows to directly compare input (the two lines shown above, as entered into Visual Studio) and output (CIL code converted back to C#).

What we see is the following:

public string GetterOnlyProperty
{
	[CompilerGenerated]
	get
	{
		return this.<GetterOnlyProperty>k__BackingField;
	}
}

public string GetterSetterProperty
{
	get;
	set;
}

public Program()
{
	this.<GetterOnlyProperty>k__BackingField = "SomeValue";
	this.<GetterSetterProperty>k__BackingField = "AnotherValue";
	base..ctor();
}

Since C# 6 is only understood by the compiler while the .NET framework itself has not changed, this means that there is no new version of the .NET virtual machine that could interpret the new language expressions. Instead, the C# compiler included with Visual Studio 2015 converts the extended auto-property initializers to conventional CIL expressions: The two auto-properties are complemented with traditional initializers called in the program’s constructor, working on the properties’ backing fields.

Expression initializers:

Similarly, initializers may be defined for methods, operators, conversions, and method-like getter-only properties. To test this, we could add the following method and property to our sample application…

public int AutoProperty => GetterOnlyProperty.Length;

public int Multiply(int a, int b) => a * b;

…and again compile and inspect it – ILSpy will show the following result:

public int AutoProperty
{
	get
	{
		return this.GetterOnlyProperty.Length;
	}
}

public int Multiply(int a, int b)
{
	return a * b;
}

Even in this case, C# 6 language features are converted to traditional expressions by the compiler.

No surprises so far, anyone parsing through our code after compilation will not stumble across any new language expressions, as everything is converted to conventional IL syntax. However, what about live code analysis during runtime using reflection? We’ll examine this use case and discuss a few examples in the second part of this artilce!

Permanent link to this article: http://www.mobilemotion.eu/?p=1658&lang=en

Oct 23

Tutorial: Create Windows 10 Apps using MVVMbasics

A tutorial that explains the main steps of implementing Windows 10 Apps using the MVVMbasics framework in three parts has just been published on codefest.at (only available in German language).                                                                                          

Permanent link to this article: http://codefest.at/post/2015/10/15/Windows-10-Apps-mit-MVVMbasics.aspx

Oct 04

Windows 10 Apps and the revised NuGet package structure

Visual Studio comes with the NuGet 3.1 client preinstalled. This new version enforces a few major changes concerning NuGet package design, which trigger some unexpected (yet barely documented or discussed) side effects that may even affect existing (published) packages.

The project.json format:

The major difference in architecture is documented on the NuGet Team Blog: NuGet package references are now stored in a file called project.json instead of the well-known packages.config. Apart from the content type (JSON instead of XML), this file only contains those pachage IDs a project references directly (while the old version even listed those packages’ dependencies). In addition, the NuGet package content of any referenced package is stored not within the solution directory, but globally in the %userprofile%\.nuget\packages folder to avoid redundancy.

In addition, the NuGet installation workflow has significantly changed: In earlier version, library references were included into the .vsproj project file during package installation. When using the new format, NuGet dependencies are only stored within the project.json file and the referenced libraries are resolved and linked first during build – one of the reasons for this approach is to not pollute project files with NuGet-specific artifacts.

Does this affect my package?

The good thing (from the point of view of a developer who doesn’t like to rewrite all his packages) is that the new format and workflow are only applied to UWP App projects and certain types of Portable Class Libraries that target the UWP platform – if you’re maintaining a NuGet package that targets, for example, only WPF applications, there’s nothing to do for you here (yet – of course, this might change in the future and other platforms might be migrated to the new structure).

On the other hand, if your package targets Windows Store Apps / the WinRT framework, there might be a need to change its structure, even if it has been publically available for some time and everything worked fine when installing it to Windows 8 Apps!

Things that don’t work with UWP:

Please note that the following enumeration may not be complete and list all features that have been changed and/or removed in NuGet 3 – I only refer to one common use case, in order to show how packages need to be re-structured to support this use case:

  • Libraries placed directly within the lib folder are ignored (in earlier versions, these libraries would have been used on all platforms for which no specific subfolder was present, this is not the case any more!). The same applies to the build folder, but I’ll go into detail about this one in a few moments.

  • In older versions it was possible to place two PowerShell script files install.ps1 and uninstall.ps1 in the package’s tools folder, which were executed during package installation / de-installation. Since with the project.json format there is no real package installation phase (package contents are not copied to the project folder and are not referenced in the project file any more, only the file project.json is adapted), these PowerShell scripts will not be executed in UWP Apps! (You can, however, keep those scripts within the package as they will still be used for non-UWP projects and just ignored by the UWP platform.)
    If the install script’s purpose was to add certain items or tasks to the project, an alternative approach is the use of .props or .targets files – if following this approach, be sure to read on as there are more potential pitfalls coming!

  • In contrast to install.ps1 and uninstall.ps1, the PowerShell file init.ps1 will still be invoked when the package is added to a Visual Studio solution for the first time, but only if you place the file init.ps1 within a platform-specific subfolder (e.g., /build/uap/init.ps1), as all files located directly within the build folder will be ignored.

  • .props and .targets files can still be used for adding project items and build tasks, but the subfolder-pattern also applies here: Files located directly within the build folder will be ignored, instead they must be placed in a platform-specific subfolder.

    If re-writing an existing package to comply with NuGet 3.x structure, you’ll probably not want to provide different .props and .targets files for all supported platforms, so a quick and easy solution for you might be to keep the existing /build/*.props and /build/*.targets files, and in addition create a new folder /build/uap/ and copy all .props and .targets files into this new folder. This way, those files will be applied to UWP App projects, and all other platforms will still use the old files in the parent folder.

  • Wile the files /tools/install.ps1 and /tools/uninstall.ps1 are ignored (as mentioned above), the tools folder can still be useful, as this folder’s contents will still be copied to %userprofile%\.nuget\packages\[packagename]\[packageversion]\tools. Since your .props and .targets files will also be placed within %userprofile%\.nuget\packages, the contents can be referenced, for example, by build tasks, using relative paths: ../../tools/somecontentfile

Permanent link to this article: http://www.mobilemotion.eu/?p=1644&lang=en

Sep 25

[MVVMbasics] UWP with MVVMbasics: IBindableView, x:Bind and async Commands

Notice

All blog posts with a title that starts with [MVVMbasics] are related to the MVVMbasics framework. If you are only interested in my regular blog posts and not in MVVMbasics, ignore these. To list all articles covering MVVMbasics, go to http://mvvmbasics.mobilemotion.eu/documentation!

Since version 2.3 of the MVVMbasics framework finally supports Universal Windows Apps for Windows 10 (UWP platform), I’d like to summarize the new features (apart from bug fixes) in this release. Let’s start with those that are only available to Windows 10 projects:

The IBindableView interface:

In addition to inheriting from BaseView, each View should now implement the IBindableView interface. This interface expects one generic parameter, which is the type of Viewmodel that shall be assigned to the View as DataContext. There are three reasons why you should use IBindableView:

  • In older versions, Views are marked with the [MvvmNavigationTarget] attribute to assign the appropriate Viewmodel type. When implementing IBindableView, this is done automatically (NavigatorService will create a Viewmodel instance when navigating to the View, and register it as DataContext) and the [MvvmNavigationTarget] attribute can be omitted (although no bad things will happen if specifying both [MvvmNavigationTarget] and IBindableView):

    public sealed partial class MyPage : BaseView, IBindableView<MyViewmodel>
    {
        // ...
    }
    
  • One of the major new features of Windows 10 UWP, compiled bindings, is now also supported by MVVMbasics: Implementing the IBindableView forces you to define a public property Vm in your View, which will automatically be filled with the current Viewmodel instance at startup and whenever the View’s DataContext changes. This means, you can simply use the Vm property for binding:

    <TextBox Text="{x:Bind Vm.SomeTextProperty, Mode=TwoWay}"/>
    <TextBox Text="{Binding SomeTextProperty, Mode=TwoWay}"/>
    

    Of course, also DataContext always contains the current Viewmodel instance and can still be used for binding in case you don’t want to use compiled bindings.

  • An additional advantage of specifying the Vm property is that it can be used to access the Viewmodel (e.g., invoke Commands) from View code-behind in an easier way than using the old Viewmodel property (no need to cast to the actual Viewmodel type any more), therefore the BaseView.Viewmodel property is now marked deprecated.

    public sealed partial class MyPage : BaseView, IBindableView<MyViewmodel>
    {
        private void Button_OnClick(object sender, RoutedEventArgs e)
    	{
    		var viewmodel = this.Viewmodel as MyViewmodel; // These 3 lines
    		if (viewmodel != null)                         // are not necessary
    			viewmodel.SomeCommand.Execute();           // any more
    		
    		// Much simpler:
    		Vm.SomeCommand.Execute();
    	}
    }
    

Asynchronous commanding:

Another new feature of the 2.3.0 version is the support of asynchronous commands for all platforms (not just Windows 10 UWP). The BaseCommand class provides four new constructor overloads that allow passing asynchronous methods (with return type of Task instead of void) as execute action. Accordingly, from within Viewmodels you can simply call one of the four CreateAsyncCommand method overloads, that create and return an asyncronous BaseCommand instance.

When an async command is called from the UI (e.g., by clicking a button that binds to this Command which internally calls the Command’s Execute method), the MVVMbasics framework takes care of invoking the async method and awaiting it, and you won’t ever notice it. The advantage of those asynchronous Commands over conventional Commands is that they provide an additional ExecuteAsync method provides a return type of Task. When testing such a Command from within a unit test, you might want to call this ExecuteAsync method instead of the traditional Execute method, since this allows you to await the method’s execution.

Permanent link to this article: http://www.mobilemotion.eu/?p=1623&lang=en

Older posts «