Introduction To Data Binding for Windows and Windows Phone (part 2) >>
Given how long Microsoft has been using XAML in one shape or another across a range of technologies (WPF, Silverlight, Windows Phone, XBox, Windows 8) it still surprises me how often I get asked about data binding. In this series we’re going to go back to basics and take a look at how to use data binding within you Window 8 and Windows Phone application. For the most part I’ll focus on Windows Phone but data binding across these platforms is relatively similar, so a lot of the concepts will carry across without me having to give multiple examples. Additionally, most of these concepts will apply equally well to data binding in Silverlight or WPF.
There are a couple of questions that we need to address:
– What is data binding?
– Why do we need data binding?
Let’s address the first question in this post by walking through an example. On our page we have two TextBlock elements that display the application title and the page name. These are illustrated with static placeholder text values (we’ll discuss design time data in a later post), which will be replaced with the actual values when the application is run.
<StackPanel x_Name="TitlePanel">
<TextBlock x_Name="ApplicationTitle" Text="MY APPLICATION" />
<TextBlock x_Name="PageTitle" Text="page name" />
</StackPanel>
Without data binding in order to update the Text property on the TextBlock elements you would have see code like this:
ApplicationTitle.Text = "DATA BINDING ROCKS!";
PageTitle.Text = "simple data binding";
Now, let’s do the same thing with data binding. Firstly, the XAML:
<StackPanel x_Name="TitlePanel" >
<TextBlock x_Name="ApplicationTitle" Text="{Binding}" />
<TextBlock x_Name="PageTitle" Text="{Binding}" />
</StackPanel>
Next, the code:
ApplicationTitle.DataContext = "DATA BINDING ROCKS!";
PageTitle.DataContext = "simple data binding";
If you look at the XAML instead of setting the Text property on the TextBlock elements to an explicit value, the attribute value is wrapped in { } – this essentially means that the value needs to be calculated some how (another typical usage of the { } value is for referencing a static resource). In this case the calculation is to create the data binding relationship between the Text property on the TextBlock and whatever is set as the current DataContext on the TextBlock. When we then set the DataContext on the TextBlock element it flows down into the Text property.
Where data binding starts to get more interesting is when you set the DataContext to be a more complex object. For example we might have a PageInfo class which contains the application title and page name:
var pi = new PageInfo
{
ApplicationTitle = "DATA BINDING ROCKS!",
PageTitle = "simple data binding"
};
ApplicationTitle.DataContext = pi;
PageTitle.DataContext = pi;
In this case we’re setting the DataContext on both TextBlock elements to be the PageInfo instance. When we run this what we see is that the data binding framework has literally just called “ToString()” on the object, which by default returns the type name as we can see in this image.
This isn’t what we want! What we want is that the first TextBlock should show the ApplicationTitle property and the second should show the PageTitle property. To do this we use the Path attribute on the data binding expression:
<StackPanel x_Name="TitlePanel" >
<TextBlock x_Name="ApplicationTitle"
Text="{Binding Path=ApplicationTitle}" />
<TextBlock x_Name="PageTitle"
Text="{Binding PageTitle}" />
</StackPanel>
In the second TextBlock the “Path=” has been omitted to illustrate the shorthand way to specify the Path attribute. In both cases the binding expression is setting up a data binding relationship between the Text property on the TextBlock with the ApplicationTitle (or PageTitle) property on the current DataContext, which in this case is an instance of the PageInfo class.
An interesting aspect of the DataContext property on a UIElement is that by default it is inherited from its parent element. So for example in our scenario both TextBlock elements are situated within a StackPanel (ie the TitlePanel). By default (ie if the DataContext isn’t explicitly set on the TextBlock) they will both inherit the DataContext of the StackPanel. This means we could reduce our code to:
var pi = new PageInfo
{
ApplicationTitle = "DATA BINDING ROCKS!",
PageTitle = "simple data binding"
};
TitlePanel.DataContext = pi;
(At this point we can also remove the x:Name attribute on both TextBlock elements as they are no longer required)
Let’s just confirm our understanding of this:
– The “{Binding ApplicationTitle}” expression is shorthand for “{Binding Path=ApplicationTitle}”
– Text=“{Binding ApplicationTitle” sets up a binding relationship between the Text property on the TextBlock with the ApplicationTitle on the current DataContext
– The DataContext of the TextBlock is inherited from its parent element, the TitlePanel StackPanel.
– We’re explicitly setting the DataContext on the TitlePanel, allowing it to be inherited by the TextBlock elements.
An alternative would be to set the DataContext on the entire page:
var pi = new PageInfo
{
ApplicationTitle = "DATA BINDING ROCKS!",
PageTitle = "simple data binding"
};
this.DataContext = pi;
In this case our code is being executed in the context of the page, so the “this” is the page and so we’re setting the DataContext on the page and allowing it to flow down to every element on the page.
The answer to the first question, “what is data binding?”, is that it’s about establishing an association between an attribute on a visual element with a data entity, or a property on a data entity. As we’ll see over the coming posts, data binding allows to separate the logic of our application from the way it is presented on the screen. This not only allows for cleaner and more manageable code, it also allows developers and designers to work independently on the same application.
In the next post we’ll look at why you should be using data binding and the saving it offers to application developers.