XAML Back to Basics #7: ItemsPanel

The next post in the series originally written by Beatriz Stollnitz. Original post available on Github. How to change the layout of an ItemsControl I will show in this sample two ways to change the layout of an ItemsControl. This sample uses XmlDataProvider, which allows binding to XML data. The easiest way to change the layout … Continue reading “XAML Back to Basics #7: ItemsPanel”

The next post in the series originally written by Beatriz Stollnitz. Original post available on Github.

How to change the layout of an ItemsControl

I will show in this sample two ways to change the layout of an ItemsControl. This sample uses XmlDataProvider, which allows binding to XML data.

The easiest way to change the layout of an ItemsControl is simply by setting the ItemsPanel property to the Panel that will contain the items:

<ListBox ItemsSource="{Binding Source={StaticResource xmlData}}" (...) >
    <ListBox.ItemsPanel>
        <ItemsPanelTemplate>
            <StackPanel Orientation="Horizontal" />
        </ItemsPanelTemplate>
    </ListBox.ItemsPanel>
</ListBox>

Alternatively, for more extensive customizations, you can create a ControlTemplate. This ControlTemplate allows you to replace the whole VisualTree, including picking a new Panel to hold the items. For example, the following markup shows a ControlTemplate that adds a Border and changes the Panel on the ItemsControl:

<ControlTemplate x:Key="listBoxTemplate">
    <Border BorderBrush="Orange" 
            BorderThickness="2" 
            Margin="10,0,10,10">
        <StackPanel Orientation="Horizontal"
            IsItemsHost="True" />
    </Border>
</ControlTemplate>

<ListBox 
    ItemsSource="{Binding Source={StaticResource xmlData}}" 
    Template="{StaticResource listBoxTemplate}" (...) />

Most people get this far in this scenario, but often forget to set the IsItemsHost property in the Panel. IsItemsHost is a property that says “Use this Panel to lay out the items in the ItemsControl.” Notice that selection still works as usual.

If you want your items to wrap onto multiples lines, you can use a WrapPanel in place of the StackPanel. In this scenario, bear in mind that the default template for ListBox contains a ScrollViewer, so your items won’t wrap. To make them wrap, you can either provide your own ControlTemplate or, if you don’t need selection to work, use an ItemsControl instead of a ListBox.

As I mentioned before, I am using XmlDataProvider to bind to XML data. This is how I converted the GreekGods CLR data source I’ve used in previous samples:

<Window.Resources>
    <XmlDataProvider XPath="/GreekGods/GreekGod" x:Key="xmlData">
        <x:XData>
            <GreekGods xmlns="">
                <GreekGod>
                    <Name>Aphrodite</Name>
                    <Description>Goddess of love, beauty and fertility</Description>
                    <RomanName>Venus</RomanName>
                </GreekGod>
                (...)
            </GreekGods>
        </x:XData>
    </XmlDataProvider>
</Window.Resources>

The only thing to keep in mind when binding to XML is that instead of using the Path property in the Binding object, you should use the XPath property. You can use either Path or XPath syntax for DisplayMemberPath.

WPF Source Code

WPF

UWP/Uno Notes

The XmlDataProvider doesn’t exist for UWP applications. Instead the GreekGods XML data has been added as an XML file with build action of Embedded Resource. The data is loaded on startup and set as the ItemsSource for each ListBox.

There is also no support for binding using an XPath expression. For this a simple XmlElementConverter has been added.

UWP/Uno Source Code

UWP
WebAssembly (WASM)

XAML Back to Basics #6: SelectedValue v SelectedItem

The next post in the series originally written by Beatriz Stollnitz. Original post available on Github. What is the difference between SelectedValue and SelectedItem? When they are used by themselves, these two properties are very similar. The need for both and the difference between the two becomes apparent when SelectedValuePath is also set. For example, consider … Continue reading “XAML Back to Basics #6: SelectedValue v SelectedItem”

The next post in the series originally written by Beatriz Stollnitz. Original post available on Github.

What is the difference between SelectedValue and SelectedItem?

When they are used by themselves, these two properties are very similar. The need for both and the difference between the two becomes apparent when SelectedValuePath is also set.

For example, consider our well-known GreekGods data source. I set the DataContext of the StackPanel to be that collection through code:

GreekGods items;
items = new GreekGods();
mainStackPanel.DataContext = items;

And used an empty Binding to bind that collection to the ListBox. I know that I want to select the GreekGod with description “Messenger of the Gods” (even though I am only displaying the Name of each God). This is when SelectedValuePath becomes useful. Each item in the ListBox is a GreekGod object, so by setting SelectedValuePath to “Description” I am able to drill down into the Description property of each GreekGod. Then I just have to set SelectedValue to the description I am looking for and the item becomes selected.

<StackPanel Name="mainStackPanel">
    <ListBox ItemsSource="{Binding}" DisplayMemberPath="Name" SelectedValue="Messenger of the Gods" SelectedValuePath="Description" Name="listBox1" (...) />
</StackPanel>

The difference between SelectedValue and SelectedItem should be obvious now. SelectedValue returns the string it was set to (“Messenger of the Gods”), while SelectedItem returns the actual GreekGod object with that description.

string messengerOfGods = (string)(listBox1.SelectedValue);
GreekGod hermes = (GreekGod)(listBox1.SelectedItem);

SelectedValue is particularly useful when only part of your item is stored in the model you are data binding to. In this scenario, you would data bind the SelectedValue property to the partial information in your model but the ListBox can show a lot more information about that item.

If you have ideas of how to combine these two properties in one, we would love to hear it.

WPF Source Code

WPF

UWP/Uno Source Code

UWP

XAML Back to Basics #5: DisplayMemberPath

The next post in the series originally written by Beatriz Stollnitz. Original post available on Github. DisplayMemberPath As I’ve shown in previous posts, binding an ItemsControl to an IEnumerable data source is really easy (remember that ListBox and ComboBox derive from ItemsControl). With DisplayMemberPath it’s even easier for the scenario where you want to display only … Continue reading “XAML Back to Basics #5: DisplayMemberPath”

The next post in the series originally written by Beatriz Stollnitz. Original post available on Github.

DisplayMemberPath

As I’ve shown in previous posts, binding an ItemsControl to an IEnumerable data source is really easy (remember that ListBox and ComboBox derive from ItemsControl). With DisplayMemberPath it’s even easier for the scenario where you want to display only one property of each data item as text. Before DisplayMemberPath, this scenario required the use of a DataTemplate that would specify the property we’re interested in, like in the following xaml:

<Window.Resources>
    <DataTemplate x:Key="itemTemplate">
        <TextBlock Text="{Binding Path=Name}" />
    </DataTemplate>
</Window.Resources>

<ItemsControl ItemsSource="{StaticResource greekGods}" ItemTemplate="{StaticResource itemTemplate}" />

The Data Binding team realized that this was a very common scenario and could be simplified, which was the motivation for introducing the DisplayMemberPath property in ItemsControl. The scenario above can now be done in a single line of xaml:

<ItemsControl ItemsSource="{StaticResource greekGods}" DisplayMemberPath="Name" />

It’s that easy 🙂

The image below shows both versions of the ItemsControl, the one on the left is using DataTemplate and the one on the right is using DisplayMemberPath.

WPF Source Code

WPF

UWP/Uno Source Code

XAML Back to Basics #4: ComboBox Binding

The next post in the series originally written by Beatriz Stollnitz. Original post available on Github. How to bind the items of a ComboBox (and get its ComboBoxItems) Binding the items of a ComboBox is pretty much the same as binding the items of a ListBox: <Window.Resources> <local:GreekGods x:Key=”greekGods”/> <DataTemplate x:Key=”itemTemplate”> <TextBlock Text=”{Binding Path=Name}” /> </DataTemplate> … Continue reading “XAML Back to Basics #4: ComboBox Binding”

The next post in the series originally written by Beatriz Stollnitz. Original post available on Github.

How to bind the items of a ComboBox (and get its ComboBoxItems)

Binding the items of a ComboBox is pretty much the same as binding the items of a ListBox:

<Window.Resources>
    <local:GreekGods x:Key="greekGods"/>

    <DataTemplate x:Key="itemTemplate">
        <TextBlock Text="{Binding Path=Name}" />
    </DataTemplate>
</Window.Resources>

<ComboBox ItemsSource="{StaticResource greekGods}" ItemTemplate="{StaticResource itemTemplate}" Width="200" Name="comboBox"/>

The reason for this similarity is that both ComboBox and ListBox derive from ItemsControl, and ItemsSource and ItemTemplate are properties on ItemsControl.

If you read my previous post about how to get a ListBoxItem from a data bound ListBox, you’re probably thinking that you don’t need to keep reading to know how to do the same thing for a ComboBox. There is a little trick that you should be aware of, though.

If you use similar code to the solution of my previous post, you will notice that the ComboBoxItems are null:

GreekGod greekGod = (GreekGod)(comboBox.Items[0]);
ComboBoxItem cbi1 = (ComboBoxItem)(comboBox.ItemContainerGenerator.ContainerFromIndex(0));
ComboBoxItem cbi2 = (ComboBoxItem)(comboBox.ItemContainerGenerator.ContainerFromItem(comboBox.Items.CurrentItem));

This is because the generation of items for the ComboBox only happens when you open it. So the trick is to open the ComboBox before calling ContainerFromIndex/ContainerFromItem:

GreekGod greekGod = (GreekGod)(comboBox.Items[0]);
comboBox.IsDropDownOpen = true;
ComboBoxItem cbi1 = (ComboBoxItem)(comboBox.ItemContainerGenerator.ContainerFromIndex(0));
ComboBoxItem cbi2 = (ComboBoxItem)(comboBox.ItemContainerGenerator.ContainerFromItem(comboBox.Items.CurrentItem));
comboBox.IsDropDownOpen = false;

WPF Source Code

WPF

UWP/Uno Source Code

UWP

XAML Back to Basics #3: ListBox/ListView Binding

The next post in the series originally written by Beatriz Stollnitz. Original post available on Github. How to get a ListBoxItem from a data bound ListBox Data binding a list box to an enumeration of items could not be easier in WPF: <Window.Resources> <local:GreekGods x:Key=”greekGods”/> <DataTemplate x:Key=”itemTemplate”> <TextBlock Text=”{Binding Path=Name}” /> </DataTemplate> </Window.Resources> <ListBox ItemsSource=”{StaticResource greekGods}” … Continue reading “XAML Back to Basics #3: ListBox/ListView Binding”

The next post in the series originally written by Beatriz Stollnitz. Original post available on Github.

How to get a ListBoxItem from a data bound ListBox

Data binding a list box to an enumeration of items could not be easier in WPF:

<Window.Resources>
    <local:GreekGods x:Key="greekGods"/>
    <DataTemplate x:Key="itemTemplate">
        <TextBlock Text="{Binding Path=Name}" />
    </DataTemplate>
</Window.Resources>

<ListBox ItemsSource="{StaticResource greekGods}" ItemTemplate="{StaticResource itemTemplate}" Name="listBox"/>

The ItemsSource property of ListBox takes an IEnumerable, which is the list of items you want to display. In this case, the GreekGods data source is of type ObservableCollection, which implements IEnumerable. The ItemTemplate property specifies the DataTemplate that will be used to control how the data is displayed. In this case, we will have a TextBlock for each item that will display the GreekGod’s name.

Some of you might find surprising, however, that doing listBox.Items[i] in code returns the data we’re binding to, and not the TextBlock or the ListBoxItem. In my opinion, it is actually pretty cool that retrieving the data in a particular position of the list box is so easy, because most of the time this is exactly what you want.

GreekGod greekGod = (GreekGod)(listBox.Items[0]);

But what about when you want to have access to the actual ListBoxItem generated? This is a bit tricky to discover but can be just as easily done with the following code:

ListBoxItem lbi1 = (ListBoxItem)(listBox.ItemContainerGenerator.ContainerFromIndex(0));

There is also a listBox.ItemContainerGenerator.ContainerFromItem(object item) that returns the ListBoxItem given the corresponding data item. This method is frequently used, for example, to retrieve the ListBoxItem for the current item:

ListBoxItem lbi2 = (ListBoxItem)(listBox.ItemContainerGenerator.ContainerFromItem(listBox.Items.CurrentItem));

I will talk about selection and current item in detail in some other post, but for this sample it is sufficient to know that to keep the selection and current item in sync, I set IsSynchronizedWithCurrentItem=”true” in the ListBox.

WPF Source Code

WPF

UWP/Uno Notes

There are a couple of changes to the code for UWP/Uno:

  • Whilst the ListBox control still exists, it’s more common to use the ListView as it has a nice set of built in styles
  • The listBox.Items collection doesn’t have a CurrentItem property. Instead we can use listBox.SelectedItem
  • Attempting to set the IsSynchronizedWithCurrentItem property on the ListView (or even ListBox) throws an exception and is generally not required since the SelectedItem property is in sync with what is selected in the ListView.

UWP/Uno Source Code

UWP

XAML Note
The structure of the XAML has been left the same from the original post. However, you should really avoid embedding a ListView or ListBox within a StackPanel. This layout will limit the ability of the view to resize without the button being pushed off screen.

XAML Back to Basics #2: Binding Markup

The next post in the series originally written by Beatriz Stollnitz. Original post available on Github. What does “{Binding}” mean? Most Bindings you see in samples have the Source and Path properties set. The Source property specifies the object you’re binding to and the Path specifies a property in that object whose value you’re interested … Continue reading “XAML Back to Basics #2: Binding Markup”

The next post in the series originally written by Beatriz Stollnitz. Original post available on Github.

What does “{Binding}” mean?

Most Bindings you see in samples have the Source and Path properties set. The Source property specifies the object you’re binding to and the Path specifies a property in that object whose value you’re interested in. I’ve seen several people get confused when encountering an empty Binding for the first time – “{Binding}”. It seems at first sight that we’re not giving the Binding enough information to do anything useful. This is not true and I will explain why. If you read my previous post you should understand that it is not necessary to set a Source in a Binding, as long as there is a DataContext set somewhere up in the tree. As for the Path, it should be left out when you want to bind to a whole object, and not only to a single property of an object. One scenario is when the source is of type string and you simply want to bind to the string itself (and not to its Length property, for example).

<Window.Resources>
    <system:String x:Key="helloString">Hello</system:String>
</Window.Resources>

<Border DataContext="{StaticResource helloString}">
    <TextBlock TextContent="{Binding}"/>
</Border>

Another common scenario is when you want to bind some element to an object with several properties.

<Window.Resources>
    <local:GreekGod Name="Zeus" Description="Supreme God of the Olympians" RomanName="Jupiter" x:Key="zeus"/>
</Window.Resources>

<Border DataContext="{StaticResource zeus}">
    <ContentControl Content="{Binding}"/>
</Border>

In this case, ContentControl does not know how to display the GreekGod data. Therefore you will only see the results of a ToString(), which is typically not what you want. Instead, you can use a DataTemplate, which allows you to specify the appearance of your data.

<Window.Resources>
    <local:GreekGod Name="Zeus" Description="Supreme God of the Olympians" RomanName="Jupiter" x:Key="zeus"/>
    <DataTemplate x:Key="contentTemplate">
        <DockPanel>
            <TextBlock Foreground="RoyalBlue" TextContent="{Binding Path=Name}"/>
            <TextBlock TextContent=":" Margin="0,0,5,0" />
            <TextBlock Foreground="Silver" TextContent="{Binding Path=Description}" />
        </DockPanel>
    </DataTemplate>
</Window.Resources>

<Border DataContext={StaticResource zeus}">
    <ContentControl Content="{Binding}" ContentTemplate="{StaticResource contentTemplate}"/>
</Border>

Notice that none of the Binding statements inside the DataTemplate has a Source. That is because a DataContext is automatically set to the data object being templated.

WPF Source Code

WPF

UWP/Uno Source Code

UWP
Uno – Wasm

XAML Back to Basics #1: Data Context

Last year I posted about a series of posts that Beatriz Stollnitz made on WPF/Silverlight that had been moved to GitHub. Unfortunately most of the samples don’t work out of the box with the latest version of Visual Studio but with some minor adjustments they’re easily fixed. I took a fork of the repository and … Continue reading “XAML Back to Basics #1: Data Context”

Last year I posted about a series of posts that Beatriz Stollnitz made on WPF/Silverlight that had been moved to GitHub. Unfortunately most of the samples don’t work out of the box with the latest version of Visual Studio but with some minor adjustments they’re easily fixed.

I took a fork of the repository and have started to a) update the wpf projects to work with VS2019 b) remove the Silverlight content and c) add equivalent examples that work cross platform using UWP and the Uno Platform.

Updated Code Samples

Importantly, as I go through each of the posts I’m going to reprint the majority of the original post with edits to bring them up to date with both WPF and UWP/Uno. I want to make sure the Beatriz is recognised as the original author of this content and that I just want to make sure her contributions live on to benefit the next generation of XAML developers.

Original post available on Github

How should I decide whether to use DataContext or Source?

WPF Source Code

The DataContext is one of the most fundamental concepts in Data Binding.

The Binding object needs to get its data from somewhere, and there are a few ways to specify the source of the data. In this post I talk about setting the Source property directly in the Binding vs inheriting a DataContext from the nearest element when traversing up in the tree. The other two alternatives are setting the ElementName and RelativeSource properties in the Binding object, but I will leave that for a future post.

For example, let’s assume we have the following data sources (GreekGod being a class defined in the code behind):

<Window.Resources>
    <local:GreekGod Name="Zeus" Description="Supreme God of the Olympians" RomanName="Jupiter" x:Key="zeus"/>
    <local:GreekGod Name="Poseidon" Description="God of the sea, earthquakes and horses" RomanName="Neptune" x:Key="poseidon"/>
</Window.Resources>

<StackPanel DataContext="{StaticResource poseidon}">
    <TextBlock TextContent="{Binding Source={StaticResource zeus}, Path=Name}"/>
    <TextBlock TextContent="{Binding Path=Description}"/>
    <TextBlock TextContent="{Binding Path=RomanName}"/>
</StackPanel>

The first TextBlock inherits the DataContext from the parent StackPanel and has a Source set in the Binding object too. In this case, Source takes priority, causing the TextBlock to bind to the Name property of the resource with key “zeus” – this displays “Zeus”.

The second TextBlock does not have a Source set directly in the Binding object, so it inherits the DataContext from the StackPanel. As you might guess, this binds to the Description property of the resource with key “poseidon”, displaying “God of the sea, earthquakes and horses”.

The third TextBlock should be straightforward – it displays “Neptune”.

Most data bound applications I see from users tend to use DataContext much more heavily than Source. My recommendation is to use DataContext when you need to bind more than one property to a particular source. When binding only one property, it may be better to use the Source attribute . The reason for this is ease of debugging – I would rather see all the information about the Binding in one place than search for the nearest DataContext to understand what is going on. In a small sample like the one above there is no big advantage, but in complex applications this could save you some time.

UWP/Uno Notes

UWP/Uno Source Code

In UWP it’s not very common to reference the Windows of the application directly. Instead you can define static resources (in this case the instances of the GreekGod class) at the Application, Page or even Control level. For example, to make the static resource available throughout a given page, we would define them as Page Resources.

<Page.Resources>
    <local:GreekGod Name="Zeus" Description="Supreme God of the Olympians" RomanName="Jupiter" x:Key="zeus"/>
    <local:GreekGod Name="Poseidon" Description="God of the sea, earthquakes and horses" RomanName="Neptune" x:Key="poseidon"/>
</Page.Resources>

Here’s the same sample running on UWP.

Content from Former Microsoft WPF and Silverlight Team Member

Someone pointed me in the direction of a series of great blog posts that have recently been migrated to a github repository. The posts are quite old, dating back to a period between 2005 and 2013 when Beatriz Stollnitz worked for Microsoft as part of the WPF and Silverlight teams. Here are the links to … Continue reading “Content from Former Microsoft WPF and Silverlight Team Member”

Someone pointed me in the direction of a series of great blog posts that have recently been migrated to a github repository. The posts are quite old, dating back to a period between 2005 and 2013 when Beatriz Stollnitz worked for Microsoft as part of the WPF and Silverlight teams. Here are the links to each of the posts – happy reading!

Update 11th August: I’ve forked the repository and have started to work my way through the sample code to a) update it to WPF on .NET 4.7.2 and b) provide a similar example for UWP + Uno (iOS, Android, WASM). Feel free to check it out and help out!

01-DataContext

02-EmptyBinding

03-GetListBoxItem

04-BindToComboBox

05-DisplayMemberPath

06-SelectedValue

07-ChangePanelItemsControl

08-BarGraph

09-CollectionViewSourceSample

10-MasterDetail

11-MasterDetailThreeLevels

12-DataBoundDialogBox

13-TemplatingItems

14-SortingGroups

15-GroupingTreeView

16-GroupByType

17-BoundListView

18-ThreeLevelMasterDetailADO

19-ObjectDataProviderSample

20-InsertingSeparators

21-CustomSorting

24-AsynchronousBinding

25-BindToEnum

26-DataTriggerSample

27-ConvertXaml

28-FilterSample

29-MultipleFilters

30-MultiBindingConverter

31-ChangesMultithreading

32-PolygonBinding

33-PolygonBinding2

34-PolygonBinding3

35-CommonQuestions

36-ADOIndependentView

37-PlanetsListBox

38-UpdateExplicit

39-TreeViewPerformancePart1

40-TreeViewPerformancePart2

41-TreeViewPerformancePart3

42-WPFPresenter

43-BindToXLinq

44-XLinqXMLMasterDetail

45-DebuggingDataBinding

46-DragDropListBox

47-ExpandTreeViewPart1

48-ExpandTreeViewPart2

49-ExpandTreeViewPart3

51-UIVirtualization

52-DataVirtualization

54-PieChartWithLabels

55-PieChartWithLabelsSilverlight

56-PieChartWithLabelsSilverlight

57-DataVirtualization

58-MultipleStyles

59-WPFCollectionViewSource

60-SLCollectionViewSource

61-OredevComputerWeekly

62-DataVirtualizationFiltering

64-DataVirtualizationFilteringSorting

66-SortingHierarchy

67-PieChartWithLabelsUpdates

69-BindRadioButtonsToEnumsPart1

70-BindRadioButtonsToEnumsPart2

71-BindRadioButtonsToEnumsPart3

72-BindRadioButtonsToEnumsPart4

73-BindRadioButtonsToEnumsPart5

74-PositioningDataBoundItems

75-SimultaneousEnableDisable

76-FocusWatcher

77-CaptureWatcher

78-BetterBindableBase

79-BooleanConverters

MVX=0 WPF/Mac: A first MvvmCross Application (MVX+1 days of MvvmCross)

MVX=0 WPF/Mac: A first MvvmCross Application (MVX+1 days of MvvmCross)

Further to some feedback on the first couple of posts in the MVX+1 series (MVX=0, MVX=0F and MVX=1), I’ve gone back and added WPF and Mac support to the FirstDemo to show just how powerful MvvmCross is. I’ll cover very briefly here how to add these project types and then I’ll be updating the TipCalc post to include the basics for WPF and Mac setup in there too.

Let’s start with WPF:

  1. Add a WPF App (.NET Framework) called FirstDemo.Wpf
    image
  2. Add a reference to MvvmCross NuGet package
  3. Add reference to FirstDemo.Core project
  4. Add ProxyMvxApplication to App.xaml.cs
    public abstract class ProxyMvxApplication : MvxApplication<MvxWpfSetup<Core.App>, Core.App> { }
  5. Update App class in both App.xaml and App.xaml.cs to inherit from ProxyMvxApplication
  6. Remove all code in the App class (in App.xaml.cs) except for the constructor with call to InitializeComponent
    public App()
    {
         InitializeComponent();
    }
  7. Update MainWindow in both MainWindow.xaml and MainWindow.xaml.cs to inherit from MvxWindow
  8. Create Views folder
  9. Add new User Control (WPF) called FirstView.xaml
  10. Update FirstView in both FirstView.xaml and FirstView.xaml.cs to inherit from MvxWpfView
  11. Add XAML to FirstView.xaml
    <StackPanel Margin=”12,12,12,12″>
         <TextBox Text=”{Binding FirstName, Mode=TwoWay}”></TextBox>
         <TextBox Text=”{Binding LastName, Mode=TwoWay}”></TextBox>
         <TextBlock Text=”{Binding FullName}”></TextBlock>
    </StackPanel>

You should now be able to build and run the WPF application – notice how little code we have to add/change in order to get MvvmCross to work!

Next up is Mac which at the moment can only be done on a Mac (almost no surprises there – it’s the same as not being able to do UWP development on a Mac I guess):

  1. Add a Cocoa App called FirstDemo.Mac
    image
  2. Add a reference to MvvmCross NuGet package
  3. Add reference to FirstDemo.Core project
  4. At this point I would recommend unloading your project, editing the csproj file manually to removed the legacy nuget reference and add the following ItemGroup. Also remove the reference to package.config, remove the actual package.config file and delete both bin and obj folders. Reload the Mac project and force a rebuild.
    <ItemGroup>
       <PackageReference Include=”MvvmCross” Version=”6.0.0″ />
    </ItemGroup>
  5. Update AppDelegate to inherit from MvxApplicationDelegate
    [Register(“AppDelegate”)]
    public class AppDelegate: MvxApplicationDelegate<MvxMacSetup<App>, App>
    {
         public override void DidFinishLaunching(NSNotification notification)
         {
             MvxMacSetupSingleton.EnsureSingletonAvailable(this, MainWindow).EnsureInitialized();
             RunAppStart();
            // Due to a bug, do not call base DidFinishLaunching
             //base.DidFinishLaunching(notification);
         }
    }
    Note: There is a bug at the moment where if you don’t override DidFinishLaunching the application will crash on startup
  6. Open main.storyboard – this should open the storyboard in the XCode designer
  7. Select the existing view controller and set the Class and Storyboard ID to FirstView
    image
  8. Make sure the FirstView name change has been saved; return to VS for Mac and confirm that files FirstView.cs and FirstView.designer.cs have been created. If these have not been created, I would suggest doing a rebuild of your project to make sure the changes to the storyboard have been processed and the appropriate designer files created.
  9. From the Object Library drag two TextField and a Label across onto the design surface
    image
  10. Open Project navigator and make sure you have FirstView.h and FirstView.m. If you don’t I would suggest closing both XCode and VS for Mac, deleting the bin and obj folder from within the FirstDemo.Mac folder and reopening the solution in VS for Mac. Rebuild the Mac project and then launch XCode by double clicking on main.storyboard.
    image
  11. Hide both Project navigator (left pane) and Utilities (right pane) and show the Assistant Editor (the icon button that has linked circles in top right corner of XCode)
  12. From the navigator bar in the Assistant Editor, select Manual –> FirstView.Mac –> FirstView.h
    image
  13. Right-click on the first TextField
    image
  14. Click and drag the circle next to New Referencing Outlet across onto the FirstView.h immediately before the @End. When you release, you should be prompted to complete information about the new Outlet where you can specify the Name, textEditFirst, which will be the name of the backing variable you’ll be able to use to reference the TextField in code
    image
  15. Repeat the previous step for the second TextField, textEditSecond, and the Label, labelFull.
  16. Update FirstView.cs to add the MvxFromStoryboard attribute, change the base class to MvxViewController and add data binding using the CreateBindingSet extension
    [MvxFromStoryboard(“Main”)]
    public partial class FirstView : MvxViewController<FirstViewModel>
    {
         public FirstView(IntPtr handle) : base(handle)
         {
         }

  17.     public override void ViewDidLoad()
         {
             base.ViewDidLoad();
             var set = this.CreateBindingSet<FirstView, FirstViewModel>();
             set.Bind(textEditFirst).To(vm => vm.FirstName);
             set.Bind(textEditSecond).To(vm => vm.LastName);
             set.Bind(labelFull).To(vm => vm.FullName);
             set.Apply();
         }
    }

And there you have it – build and run your Mac FirstDemo application

    Adding Logging to Client Applications using MetroLog not NLog

    Adding Logging to Client Applications using MetroLog not NLog

    I wanted to add some logging to my set of applications and was somewhat disappointed to discover the complete lack of PCL support in NLog. After a quick search to find out what others are using I came across MetroLog which seems to be very similar in a lot of regards to NLog (in fact they claim the API surface is very similar indeed). I went to install the NuGet package…

    image

    and noticed that my Core library (a PCL) wasn’t in the list. Clearly my PCL profile doesn’t match one of the supported profiles which is a bit painful. However, it does support all my client application types so I was happy at least to use MetroLog.

    image

    I did have a couple of issues installing the NuGet package, namely Visual Studio decided to crash mid way through installing the packages. This meant I had to manually install Microsoft.Bcl.Compression which is a dependency for the Windows Phone 8.0 project, and then uninstall and reinstall the support for the Windows and Desktop projects.

    After all this I was building successfully again so it was time to think about how to structure the logging support. Clearly with logging I want it to be a simple as possible and yet accessible virtually anywhere within the application. I want to define a service that is available within my Core library in a similar way to my IDataService and ISyncService implementation. I also wanted the log output to be written out to a sqlite database file for ease of access (there are plenty of third party tools capable of viewing sqlite db files) but rather than use the SqliteTarget that comes with MetroLog I felt I had to write my own (as you do). Luckily this whole process is relatively simple.

    I start by creating an ILogWriterService interface which will provide the low level API for writing a LogEntry to a local Mobile Service sqlite table (I’m going to use the same process that is used to cache my synchronized data, except for the time being at least, the data won’t be synchronized anywhere).

    public interface ILogWriterService
    {

        IMobileServiceSyncTable<LogEntry> LogTable { get; }
        Task Initialize();
    }

    public class LogEntry : BaseEntityData
    {
        public DateTime LogDateTime { get; set; }
        public string Entry { get; set; }
    }

    public class LogWriterService : ILogWriterService
    {
        private readonly MobileServiceClient mobileService = new MobileServiceClient(Constants.MobileServiceRootUri);

        private IMobileServiceClient MobileService
        {
            get { return mobileService; }
        }

        public IMobileServiceSyncTable<LogEntry> LogTable
        {
            get { return MobileService.GetSyncTable<LogEntry>(); }
        }

        public async Task Initialize()
        {
            var data = new MobileServiceSQLiteStore(“log.db”);
            data.DefineTable<LogEntry>();

            await MobileService.SyncContext.InitializeAsync(data, new MobileServiceSyncHandler());
        }
    }

    Next I define the high level service interface, ILogService:

    public interface ILogService
    {
        void Debug(string message);

        void Exception(string message, Exception ex);
    }

    So far, all of these classes have been in the Core library. However, the implementation of the ILogService has to be in the Shared.Client project as it needs to be used by all the client projects.

    public class LogService : ILogService
    {
        public ILogWriterService Writer { get; set; }

        public ILogger Logger { get; set; }

        public LogService(ILogWriterService writer)
        {
            Writer = writer;
            var target = new MobileServiceTarget(Writer);

            LogManagerFactory.DefaultConfiguration.AddTarget(LogLevel.Debug, target);

            Logger = LogManagerFactory.DefaultLogManager.GetLogger(“Default”);
        }

        public void Debug(string message)
        {
            Logger.Debug(message);
        }

        public void Exception(string message, Exception ex)
        {
            Logger.Error(message, ex);
        }
    }

    As you can see the implementation sets up the MetroLog logger but uses a custom MobileServiceTarget as the destination. This is implemented as follows:

    public class MobileServiceTarget : Target
    {
        public ILogWriterService Writer { get; set; }
        public MobileServiceTarget(ILogWriterService writer)
            : base(new SingleLineLayout())
        {
            Writer = writer;
        }

        private bool InitCompleted { get; set; }
        protected async override Task<LogWriteOperation> WriteAsyncCore(LogWriteContext context, LogEventInfo entry)
        {
            try
            {
                if (!InitCompleted)
                {
                    await Writer.Initialize();
                    InitCompleted = true;
                }
                var log = new LogEntry { LogDateTime = DateTime.Now, Entry = entry.ToJson() };
                await Writer.LogTable.InsertAsync(log);
                return new LogWriteOperation(this, entry, true);
            }
            catch (Exception ex)
            {
                return new LogWriteOperation(this, entry, false);
            }
        }
    }

    I of course need to register the implementations with Autofac:

    builder.RegisterType<LogWriterService>().As<ILogWriterService>();
    builder.RegisterType<LogService>().As<ILogService>();

    And the last thing is a static helper class that makes logging for two core scenarios really easy:

    public static class LogHelper
    {
        public static void Log<TEntity>(TEntity entity, [CallerMemberName] string caller = null)
        {
            var json = JsonConvert.SerializeObject(entity);
            Log(typeof(TEntity).Name + “: ” + json, caller);
        }

        public static void Log(string message = null, [CallerMemberName] string caller = null)
        {
            try
            {
                InternalWriteLog(“[” + caller + “] ” + message);
            }
            catch (Exception ex)
            {
                Debug.WriteLine(ex.Message);
            }
        }

        public static void Log(this Exception ex, string message = null, [CallerMemberName] string caller = null)
        {
            try
            {
                Debug.WriteLine(“Exception ({0}): {1}”, caller, ex.Message);
                InternalWriteException(caller + “: ” + message, ex);
            }
            catch (Exception ext)
            {
                Debug.WriteLine(ext.Message);
            }
        }

        private static ILogService logService;

        private static ILogService LogService
        {
            get
            {
                if (logService == null)
                {
                    logService = ServiceLocator.Current.GetInstance<ILogService>();

                }
                return logService;
            }
        }

        private static void InternalWriteLog(string message)
        {
            try
            {

                LogService.Debug(message);
            }
            catch (Exception ext)
            {
                Debug.WriteLine(ext.Message);
            }
        }

        private static void InternalWriteException(string message, Exception ex)
        {
            try
            {
                LogService.Exception(message, ex);
            }
            catch (Exception ext)
            {
                Debug.WriteLine(ext.Message);
            }
        }
    }

    The first scenario is a simple string output eg:

    LogHelper.Log(“Startup complete”);

    The second is logging the output of an Exception:

    try
    {
       …
    }
    catch (Exception ex)
    {
        ex.Log();
    }

    Note that the Exception logging also does a Debug.WriteLine which is convenient during development to pick up any issues in the Output window.

    Navigation in the WPF Application Between View Models

    Navigation in the WPF Application Between View Models

    In my previous post I showed adding a INavigateService to facilitate navigation between view models. This included an implementation of the service for Universal applications. For WPF the implementation looks very similar:

    public class WPFNavigationService : CoreNavigateService<Page>
    {
        protected override void NavigateToView(Type viewType)
        {
            (App.Current.MainWindow.Content as Frame).Navigate(new Uri(“/Pages/” + viewType.Name + “.xaml”, UriKind.RelativeOrAbsolute));
        }
    }

    Note that this assumes that pages are in the Pages folder of the project.

    The other change that is required is that the WPF application needs to have a Frame which can be used to navigate between pages. So, the MainWindow now looks like

    <Window x_Class=”RealEstateInspector.Desktop.MainWindow”
            http://schemas.microsoft.com/winfx/2006/xaml/presentation"”>http://schemas.microsoft.com/winfx/2006/xaml/presentation”
            http://schemas.microsoft.com/winfx/2006/xaml"”>http://schemas.microsoft.com/winfx/2006/xaml”
            Title=”MainWindow” Height=”350″ Width=”525″
            >
        <Frame Source=”/Pages/MainPage.xaml” />
    </Window>

    All the content that was in the MainWindow is now in MainPage. And the type registration at application startup is getting more complex:

    public void ApplicationStartup()
    {
        CoreApplication.Startup(builder =>
        {

            builder.RegisterType<SignalRFactory>().As<ISignalR>();
    #if NETFX_CORE
            builder.RegisterType<UniversalUIContext>().As<IUIContext>();
            builder.RegisterType<WindowsPlatformNavigationService>().SingleInstance().As<INavigateService>();

    #elif DESKTOP
            builder.RegisterType<WPFNavigationService>().SingleInstance().As<INavigateService>();
    #endif
        });

    #if NETFX_CORE
        var navService = ServiceLocator.Current.GetInstance<INavigateService>() as WindowsPlatformNavigationService;
    #elif DESKTOP
        var navService = ServiceLocator.Current.GetInstance<INavigateService>() as WPFNavigationService;
    #endif
    #if NETFX_CORE || DESKTOP
        navService.Register<MainViewModel, MainPage>();
        navService.Register<SecondViewModel, SecondPage>();
    #endif
    }

    This creates a navigation bar which allows the user to navigate back between pages:

    image

    ViewModel Refactoring, INotifyPropertyChanged and Running on UI Context with Dispatcher

    ViewModel Refactoring, INotifyPropertyChanged and Running on UI Context with Dispatcher

    In a previous post I showed how to use SignalR as one option for providing feedback to the client application during a long running service operation. However, I didn’t display this on the UI because that would have made the blog post long and complicated as I tried to explain propagating a change from a non-UI thread, back onto the UI thread so it could be displayed within the app. In this post I’m going to do just that – what’s interesting is that each platform handles this scenario slightly different with some caring about thread affinity, whilst others do not.

    Firstly, I’ll update the layout to include a TextBlock that’s going to display the progress:

    <TextBlock Text=”{Binding Progress}” />

    In this case databinding to the Progress property on the MainViewModel:

    private string progress;
    public string Progress
    {
        get { return progress; }
        set
        {
            if (Progress == value) return;
            progress = value;
            OnPropertyChanged();
        }
    }

    Note that as this property changes it calls the OnPropertyChanged method which will be used to raise the PropertyChanged event specified in the INotifyPropertyChanged interface – this is what the XAML data binding framework uses to detect when bound properties are changed. In this case I’m going to implement this interface in BaseViewModel, and have MainViewModel inherit from BaseViewModel, rather than implement it in every view model.

    public class MainViewModel:BaseViewModel  { … }

    public class BaseViewModel:INotifyPropertyChanged
    {
       
    public event PropertyChangedEventHandler PropertyChanged;

        protected virtual void OnPropertyChanged([CallerMemberName] string propertyName = null)
        {
            PropertyChangedEventHandler handler = PropertyChanged;
            if (handler != null) handler(this, new PropertyChangedEventArgs(propertyName));

        }
    }

    Now, let’s modify the delegate that gets invoked when we receive an update from the service. Previously we just had Debug.WriteLine(msg), let’s change that to  Progress=msg. When you run this in your Universal Windows application – BANG – Exception due to an attempt to update the UI (ie the Text attribute on the TextBlock) from a non-UI thread. Interestingly doing the same thing in the WPF application doesn’t throw the same exception. In order to update the Progress property, we first need to jump back onto the UI thread, which is fine, if we were working directly with the Page/View. However, we don’t have any notion of a Dispatcher, UI threads etc from within the MainViewModel. This sounds like another scenario for a dependency injected implementation, so here goes:

    My BaseViewModel is extended to include a UIContext object:

    private readonly UIContext context=new UIContext();

    public UIContext UIContext

    {
        get { return context; }
    }

    The UIContext object wraps and abstracts away the loading of an implementation of IUIContext:

    public interface IUIContext
    {
        Task RunOnUIThreadAsync(Func<Task> action);
    }

    public class UIContext
    {
        private IUIContext runContext;
        private IUIContext RunContext
        {
            get
            {
                if (runContext == null)
                {
                    runContext = ServiceLocator.Current.GetInstance<IUIContext>();

                }
                return runContext;
            }
        }

        public async Task RunAsync(Action action)
        {
            await RunAsync(async () => action());
        }

        public async Task RunAsync(Func<Task> action)
        {
            var context = RunContext;
            await context.RunOnUIThreadAsync(action);
        }
    }

    Of course, we now need an implementation of IUIContext for our Universal Windows application:

    public class UniversalUIContext : IUIContext
    {
        public async Task RunOnUIThreadAsync(Func<Task> action)
        {
            await CoreApplication.MainView.CoreWindow.Dispatcher.RunAsync(CoreDispatcherPriority.Normal,async  () => await action());
        }
    }

    And this needs to be registered with Autofac in the ClientApplicationCore – note the use of the NETFX_CORE compilation attribute.

    CoreApplication.Startup(builder =>
    {
        builder.RegisterType<SignalRFactory>().As<ISignalR>();
    #if NETFX_CORE
        builder.RegisterType<UniversalUIContext>().As<IUIContext>();
    #endif
    });

    And finally I need to go back to my initial progress statement and update it from msg => Progress = msg, to the following:

    async msg =>
        await UIContext.RunAsync(() =>
        {
            Progress = msg;
        })

    This issue isn’t specific to Universal applications, and you should always make sure you have access to the UI thread when making UI changes (such as updating data bound properties).

    Debugging Azure Active Directory Authentication with Azure Mobile Service .NET Backend When Running Locally

    Debugging Azure Active Directory Authentication with Azure Mobile Service .NET Backend When Running Locally

    In a recent project one of the more challenging things was to debug the Azure Mobile Services (AMS) when running locally. For the most part it was pretty straight forward as a lot of the requests, whilst they required a user to be authenticated, the returned data wasn’t contingent on who the user was. When you run Azure Mobile Services locally, which you can with the .NET backend but not with the Node.js backend, by default it doesn’t enforce any of the security requirements. This makes it easy to debug scenarios where it doesn’t matter who the user is but very hard for those scenarios where the data needs to be altered based on who the user is, particularly if the user is being authenticated using Azure Active Directory (AAD). In this post I’ll walk through getting debugging to run locally.

    The first thing I need to do is to configure the Mobile Service to enforce the same security when running locally, as if it were running in Azure. I do this by adding the following immediately following the ServiceConfig.Initialize line:

    // This tells the local mobile service project to run as if it is being hosted in Azure,
    // including honoring the AuthorizeLevel settings. Without this setting, all HTTP requests to
    // localhost are permitted without authentication despite the AuthorizeLevel setting.
    config.SetIsHosted(true);

    Side Note (feel free to skip over this section if you’re not interested on how I attempted to get this to work)

    My initial approach was to use what I new about the way AAD connects with AMS which involves an application within AAD that defines the relationship between the native client (which is authenticating) and the AMS (which is the resource it is requesting access to). As my AMS is running locally it is hosted at http://localhost:51539/ I thought that I needed to create another AAD Web application pointing at http://localhost:51539/login/aad eg

    image

    And then in the Native Client AAD application I had to delegate permissions to the new AAD Web application eg

    image

    In the native application, in this case my WPF application, I changed both the resource url for the AAD authentication and the mobile services url to use http://localhost:51539/ ie http://localhost:51539/login/aad for the resource url and just http://localhost:51539/ for the mobile services url. This seemed to work correctly initially as it displayed the sign in prompt, I could sign in and get back an AAD access token. Unfortunately when this was passed to the AMS it failed miserably with an unauthorised exception.

    Note: I actually feel what I did here was correct that that the Mobile Services team are incorrectly validating the claims based on the illusion that the local services is being hosted in the cloud. This means you actually need to authenticate with AAD as if you were requesting access to the resource https://realestateinspector.azure-mobile.net/login/aad and then actually connect to the locally running mobile service.

    End of Side Note – Here’s how you really do it

    Ok, so you DON’T need to change the url that is being specified as the resource when signing into AAD. However, you DO need to change the url that is used when creating the instance of the mobile service client. My constants file now looks like this:

    #if DEBUG
    #define DEBUGLOCAL
    #endif

    public static class Constants
    {
        public const string ADTenant = “realestateinspector.onmicrosoft.com”;
        public const string ADAuthority=”
    https://login.windows.net/” + ADTenant;

        public const string ADNativeClientApplicationClientId = “a5a10ee9-f871-4bde-997f-3f1c323fefa5”;

        public const string ADRedirectUri = “http://builttoroam.com”;

    #if DEBUGLOCAL
        public const string ActualMobileServiceRootUri = “
    https://realestateinspector.azure-mobile.net/”;
        public const string MobileServiceRootUri = “http://localhost:51539/”;
        public const string MobileServiceAppIdUri = ActualMobileServiceRootUri + “login/aad”;
    #else
        public const string MobileServiceRootUri = “
    https://realestateinspector.azure-mobile.net/”;
        public const string MobileServiceAppIdUri = MobileServiceRootUri + “login/aad”;
    #endif
    }

    Note that I’ve used an inline compilation constant to allow me to switch from debugging against the local services versus those hosted in the cloud.

    If you attempt to run this, the user will be directed to authenticate using the AAD signin with a resource https://realestateinspector.azure-mobile.net/login/aad and then the application will attempt to login to the Mobile Service running locally at http://localhost:51539/ (Note – I typically set both the native client project (in this case the WPF application) and the Mobile Service project as start projects). However, you’ll still get an unauthorized exception because the Mobile Service actual does verify that the claims in the access token returned from AAD match the settings of the Mobile Services (excluding the base url that the service is being run from – see my early argument why this imho is the wrong approach). Let’s first take a look at the access token using the site http://jwt.io.

    image 

    If you look in the Web.config file for the Mobile service you’ll see that there is a list of Mobile Service settings in the appSettings section. The first of which is typically the MS_MobileServiceName and I’m guessing it’s this setting that is being used to validate that the claim in the token is for the right mobile serivce – in the token you can see that the resource is https://realestateinspector.azure-mobile.net/login/aad where the only piece that varies between Mobile Services is the service name.

    <add key=”MS_MobileServiceName” value=”realestateinspector” />
    The next thing to look at is in the actual login request that the mobile service client library makes:

    POST: https://realestateinspector.azure-mobile.net/login/aad
    X-ZUMO-INSTALLATION-ID: c2ac49d1-af97-472b-af61-bfb06663f137
    X-ZUMO-APPLICATION: wpxaIplpeXtknXQhqXiVlZAPYQEBcg12
    X-ZUMO-AUTH: eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJ1cm46bWljcm9zb2Z0OndpbmRvd3MtYXp1cmU6enVtbyIsImF1ZCI6InVybjptaWNyb3NvZnQ6d2luZG93cy1henVyZTp6dW1vIiwibmJmIjoxNDIyMDkxOTY3LCJleHAiOjE0MjIwOTU0OTYsInVybjptaWNyb3NvZnQ6Y3JlZGVudGlhbHMiOiJ7XCJ0ZW5hbnRJZFwiOlwiZTY4OGQ1OTQtODY0My00YmRmLTllNGMtMGJlOGJjYmM2NDVmXCIsXCJvYmplY3RJZFwiOlwiYWJkNzc5MjgtNDFkMS00YzNjLThmNmYtMmE1NmQ4NDRkMDVlXCIsXCJhY2Nlc3NUb2tlblwiOlwiZXlKMGVYQWlPaUpLVjFRaUxDSmhiR2NpT2lKU1V6STFOaUlzSW5nMWRDSTZJbXR5YVUxUVpHMUNkbmcyT0hOclZEZ3RiVkJCUWpOQ2MyVmxRU0o5LmV5SmhkV1FpT2lKb2RIUndjem92TDNKbFlXeGxjM1JoZEdWcGJuTndaV04wYjNJdVlYcDFjbVV0Ylc5aWFXeGxMbTVsZEM5c2IyZHBiaTloWVdRaUxDSnBjM01pT2lKb2RIUndjem92TDNOMGN5NTNhVzVrYjNkekxtNWxkQzlsTmpnNFpEVTVOQzA0TmpRekxUUmlaR1l0T1dVMFl5MHdZbVU0WW1OaVl6WTBOV1l2SWl3aWFXRjBJam94TkRJeU1Ea3hOalUyTENKdVltWWlPakUwTWpJd09URTJOVFlzSW1WNGNDSTZNVFF5TWpBNU5UVTFOaXdpZG1WeUlqb2lNUzR3SWl3aWRHbGtJam9pWlRZNE9HUTFPVFF0T0RZME15MDBZbVJtTFRsbE5HTXRNR0psT0dKalltTTJORFZtSWl3aVlXMXlJanBiSW5CM1pDSmRMQ0p2YVdRaU9pSmhZbVEzTnpreU9DMDBNV1F4TFRSak0yTXRPR1kyWmkweVlUVTJaRGcwTkdRd05XVWlMQ0oxY0c0aU9pSnBibk53WldOMGIzSkFjbVZoYkdWemRHRjBaV2x1YzNCbFkzUnZjaTV2Ym0xcFkzSnZjMjltZEM1amIyMGlMQ0p6ZFdJaU9pSm5WMlJUY0VwbllqSnBUbkpyWm5wbVlUQlViWGhPTFZGeU0yMXFhamhoY0ZoZlYxbG5lVGRrVDNOUklpd2libUZ0WlNJNklrbHVjM0JsWTNSdmNpSXNJblZ1YVhGMVpWOXVZVzFsSWpvaWFXNXpjR1ZqZEc5eVFISmxZV3hsYzNSaGRHVnBibk53WldOMGIzSXViMjV0YVdOeWIzTnZablF1WTI5dElpd2lZWEJ3YVdRaU9pSmhOV0V4TUdWbE9TMW1PRGN4TFRSaVpHVXRPVGszWmkwelpqRmpNekl6Wm1WbVlUVWlMQ0poY0hCcFpHRmpjaUk2SWpBaUxDSnpZM0FpT2lKMWMyVnlYMmx0Y0dWeWMyOXVZWFJwYjI0aUxDSmhZM0lpT2lJeEluMC5IVEhlUEFEcW5XYjE2ZTdwYTQ1VkppdFlTV2pvanZzaEwyZ3I4cTR3S1k2QkpWNF9INXBoQklmQ1p3RUtGeU05MlpQWkpza1NDVkl5QlNvNnU0eTgyUlJKcWxmVW9NN3hjRG1zZ0dOVlNYZzhoOGhJWm56X1ZIcGg4ZUp4TXRvZ0VrR2tZWXFld0R5Wi1zWlVTaVZ5ckhpZWlCd2Qzd2M4T0hQaDRXeGUwbUh6OHItekZoOGtmY2lQWW9KRkJ3aGczVGFaZ3hMQWJnaWVMUG83V1ZBUFpIUjV5SG1UaW02RXhQOGdUejQ0WmFiYTI3QnpISUI1dV9oa1F2QWlmU2M2blBXcVZwcC1CamZQM25mbXQwai0xemkwb1RHMVlvMjZNQzNXSHhCTUdKbGpKcVg3UmhBenV4anZESDFyRG5PeE9YaldSVk1qV2gyNzRXUjdXa0YwM0FcIn0iLCJ1aWQiOiJBYWQ6Z1dkU3BKZ2IyaU5ya2Z6ZmEwVG14Ti1RcjNtamo4YXBYX1dZZ3k3ZE9zUSIsInZlciI6IjIifQ.s6fjFOzFhdvvYgL3yD3lUEiUcxALg-avOvwJb1gILDU
    Accept: application/json
    User-Agent: ZUMO/1.3 (lang=Managed; os=Windows; os_version=6.2.0.9200; arch=Win32NT; version=1.3.21121.0)
    X-ZUMO-VERSION: ZUMO/1.3 (lang=Managed; os=Windows; os_version=6.2.0.9200; arch=Win32NT; version=1.3.21121.0)
    Content-Type: application/json; charset=utf-8
    Host: localhost:51539
    Cookie: ARRAffinity=0289d9a2e779a2431db31b4a154e84828a77f89dbbe1fe391d5fe9794f54f970
    Content-Length: 1237
    Expect: 100-continue
    Accept-Encoding: gzip
    Connection: Keep-Alive

    {
      “access_token”: “eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6ImtyaU1QZG1Cdng2OHNrVDgtbVBBQjNCc2VlQSJ9.eyJhdWQiOiJodHRwczovL3JlYWxlc3RhdGVpbnNwZWN0b3IuYXp1cmUtbW9iaWxlLm5ldC9sb2dpbi9hYWQiLCJpc3MiOiJodHRwczovL3N0cy53aW5kb3dzLm5ldC9lNjg4ZDU5NC04NjQzLTRiZGYtOWU0Yy0wYmU4YmNiYzY0NWYvIiwiaWF0IjoxNDIyMDkxNjU2LCJuYmYiOjE0MjIwOTE2NTYsImV4cCI6MTQyMjA5NTU1NiwidmVyIjoiMS4wIiwidGlkIjoiZTY4OGQ1OTQtODY0My00YmRmLTllNGMtMGJlOGJjYmM2NDVmIiwiYW1yIjpbInB3ZCJdLCJvaWQiOiJhYmQ3NzkyOC00MWQxLTRjM2MtOGY2Zi0yYTU2ZDg0NGQwNWUiLCJ1cG4iOiJpbnNwZWN0b3JAcmVhbGVzdGF0ZWluc3BlY3Rvci5vbm1pY3Jvc29mdC5jb20iLCJzdWIiOiJnV2RTcEpnYjJpTnJrZnpmYTBUbXhOLVFyM21qajhhcFhfV1lneTdkT3NRIiwibmFtZSI6Ikluc3BlY3RvciIsInVuaXF1ZV9uYW1lIjoiaW5zcGVjdG9yQHJlYWxlc3RhdGVpbnNwZWN0b3Iub25taWNyb3NvZnQuY29tIiwiYXBwaWQiOiJhNWExMGVlOS1mODcxLTRiZGUtOTk3Zi0zZjFjMzIzZmVmYTUiLCJhcHBpZGFjciI6IjAiLCJzY3AiOiJ1c2VyX2ltcGVyc29uYXRpb24iLCJhY3IiOiIxIn0.HTHePADqnWb16e7pa45VJitYSWjojvshL2gr8q4wKY6BJV4_H5phBIfCZwEKFyM92ZPZJskSCVIyBSo6u4y82RRJqlfUoM7xcDmsgGNVSXg8h8hIZnz_VHph8eJxMtogEkGkYYqewDyZ-sZUSiVyrHieiBwd3wc8OHPh4Wxe0mHz8r-zFh8kfciPYoJFBwhg3TaZgxLAbgieLPo7WVAPZHR5yHmTim6ExP8gTz44Zaba27BzHIB5u_hkQvAifSc6nPWqVpp-BjfP3nfmt0j-1zi0oTG1Yo26MC3WHxBMGJljJqX7RhAzuxjvDH1rDnOxOXjWRVMjWh274WR7WkF03A”
    }

    The X-ZUMO-APPLICATION header specified in the request needs to match the MS_ApplicationKey setting specified in the Web.config file. Most of these settings have a default value of “Overridden by portal settings” which, as it implies, is because they are overridden when the Mobile Service is hosted in the cloud. However, when running locally some of these settings need to be specified in order to get authentication to work. In this case it’s both the MS_ApplicationKey and MS_AadTenants:

    <add key=”MS_ApplicationKey” value=”wpxaIplpeXtknXQhqXiVlZAPYQEBcg12″ />
    <add key=”MS_AadTenants” value=”realestateinspector.onmicrosoft.com” />

    With this in place, running the native application again and you can login, retrieve the AAD access token, and then when the mobile service client attempts to login it will do successfully. When you then make a call to one of the controllers, you can set a break point and access the User property to retrieve information about the current user and their claims. This image shows the AAD claim for this user.

     

    image

    Adding WPF Client with Azure Active Directory Authentication and Azure Mobile Service

    Adding WPF Client with Azure Active Directory Authentication and Azure Mobile Service

    In today’s post I was going to cover adding Azure AD authentication to my iOS project but I don’t have my Mac build machine handy so there’s a bit of a change of plans. Today I’m going to add a WPF desktop application to my solution and catch it up to where the other client applications are up to. I’ll start by creating the WPF Application.

    image

    At this point I realised that I missed setting the framework in the Add New Project dialog, so I opened the Properties pane of the application and on the Application tab I set the Target framework to .Net Framework 4.5.

    image

    Next we need to add references to the following solution projects:

    – RealEstateInspector.Core

    – RealEstateInspector.Shared.Client

    And then add reference to both the ADAL and Mobile Service SqliteStore packages. From the downloads page on sqlite.org you’ll also need to download the “32-bit DLL (x86) for SQLite” which is under the Precompiled Binaries for Windows heading. Unblock and Extract the zip file and add the sqlite3.dll file to the new WPF project, setting the Build Action to Content and setting the Copy to Output Directory to Copy always.

    I also need to check the Prefer 32-bit checkbox and define the DESKTOP compilation symbol for All Configurations.

    image

    I’ll add the following XAML markup to the MainWindow.xaml

    <Window x_Class=”RealEstateInspector.Desktop.MainWindow”
            http://schemas.microsoft.com/winfx/2006/xaml/presentation"”>http://schemas.microsoft.com/winfx/2006/xaml/presentation”
            http://schemas.microsoft.com/winfx/2006/xaml"”>http://schemas.microsoft.com/winfx/2006/xaml”
            Title=”MainWindow” Height=”350″ Width=”525″>
        <Grid>
            <Grid.Resources>
                <DataTemplate
                    x_Key=”PropertyItemTemplate”>
                    <TextBlock
                        Text=”{Binding Address}”
                        FontSize=”30″
                        Foreground=”WhiteSmoke” />
                </DataTemplate>
            </Grid.Resources>
            <Grid.RowDefinitions>
                <RowDefinition
                    Height=”Auto” />
                <RowDefinition />
            </Grid.RowDefinitions>
            <Button
                Content=”Authenticate”
                Click=”AuthenticateClick” />
            <ListView
                ItemTemplate=”{StaticResource PropertyItemTemplate}”
                Grid.Row=”1″
                ItemsSource=”{Binding Properties}” />
        </Grid>
    </Window>

    And the following code to the MainWindow.xaml.cs

    public partial class MainWindow : IWin32Window
    {
        public IntPtr Handle
        {
            get
            {
                var interopHelper = new WindowInteropHelper(this);
                return interopHelper.Handle;
            }
        }
        public MainWindow()
        {
            InitializeComponent();

            Loaded += MainWindow_Loaded;
        }
        public MainViewModel CurrentViewModel
        {
            get { return DataContext as MainViewModel; }
        }
        void MainWindow_Loaded(object sender, RoutedEventArgs e)
        {
            var vm = new MainViewModel();
            DataContext = vm;
        }

        private async void AuthenticateClick(object sender, RoutedEventArgs e)
        {
            var token = await AuthenticationHelper.Authenticate(Handle);
            await CurrentViewModel.LoadPropertyData(token);
        }
    }

    I also had to make some minor changes to the AuthenticationHelper

    public static class AuthenticationHelper
    {

        public static async Task<string> Authenticate(
    #if DROID
        Android.App.Activity callerActivity
    #elif DESKTOP
    IntPtr callerHandle
    #endif
            )
        {
            try
            {
                var authContext = new AuthenticationContext(Constants.ADAuthority);
    #if !SILVERLIGHT
                if (authContext.TokenCache.ReadItems().Count() > 0)
                    authContext = new AuthenticationContext(authContext.TokenCache.ReadItems().First().Authority);
    #endif
                var authResult =
                    await
                        authContext.AcquireTokenAsync(Constants.MobileServiceAppIdUri,
                        Constants.ADNativeClientApplicationClientId,
                        new Uri(Constants.ADRedirectUri),
    #if WINDOWS_PHONE_APP || SILVERLIGHT
                        new AuthorizationParameters()
    #elif DROID
                        new AuthorizationParameters(callerActivity)
    #elif DESKTOP
                            new AuthorizationParameters(PromptBehavior.Auto, callerHandle)
    #else
                            new AuthorizationParameters(PromptBehavior.Auto, false)
    #endif
                        );
                Debug.WriteLine(authResult != null);

                return authResult.AccessToken;

            }
            catch (Exception ex)
            {
                Debug.WriteLine(ex.Message);
                return null;
            }
        }
    }

    And that’s it, the WPF desktop application can be run up, the user can sign in and properties are synchronized before being displayed.