Data binding is a simple thing …. or not? If you are remembering the Win32 API and MFC, the associated adventures and often convoluted and complex supporting logic you are not alone.

Conceptually data binding is easy. You have an instance of a data object, an instance of a business object, a user interface and logic binding data to user interface controls and ensuring that changes in the user interface and data source are synchronised.

Data binding in XAML eliminates the UI control code and offers automatic update of your user interface when the source data changes. To introduce this magic, we will once again lift the bonnet (hood) of the ALM Readiness Treasure Map solution and explore the gems.

Treasure Map Data Model Overview

  image

image

The TreasureMapDataModel.xml is the heart of the treasure map data model, defining the state of jewels of our ALM journey.

image

We have one or more categories, which map to the planning, guidance, tooling and workshop islands we introduced in previous posts.

image

Each category contains one or more projects, which map to aka.ms/vsarsolutions and other solutions in the ALM readiness treasure chest. This maps back to the project view, which displays the category item and associated project items. See Treasure Map under the bonnet (hood) #1 … Windows 8 Layout Controls and Treasure Map under the bonnet (hood) #3 … Windows 8 Layout Controls (Update) for details.

image

Each category contains zero or more guidance items, which currently embrace guidance, tooling, videos and Demomate recordings.

Treasure Map Object Binding

  image

image

We peek into the Projects.xaml view, collapse the regions which are not relevant and zoom into four areas in this XAML file.

image

Source={Binding Image} is the first magic dust, which defines that the Source property of the Image  is set to the Image property of X. The mysterious X will be revealed shortly.
Similarly the
Text={Binding Description} defines that the Text property of the TextBlock is set to bind to the Description property of X. By default the binding is one way, in other words from the property to the user interface text block control. To support two-way binding, which is out of scope for this post and the underlying code, we would simply modify the magic to Text={Binding Description, Mode=TwoWay} … simple … powerful!

image

ItemSource={Binding Guidance} defines that the ItemSource property of the ListBox is set to the Guidance property of X. This assigns a collection of data for binding against.

image

Text={Binding GuidanceType} defines that the Text property of the TextBlock of the grid item is set to the GuidanceType property of X.

image

Text={Binding Url} defines that the Text property of the Run item is set to the Url property of X.

image

Text={Binding Originator} defines that the Text property of the TextBlock is set to the Originator property of X.

For the visual readers, like I, let’s map the above blurb to a more visual example:

image

Treasure Map Data Model Initialisation

But … we talk about binding to property of X. Huh? Properties of what object? Figuring out this association (binding) will be our final exploration for today.

To get started I created a dependency diagram, which I will include for interest sake … do not try to zoom in or decipher the image. Rather re-create your own diagram and enjoy the exploration.
image 

Let’s set a few breakpoints and sail through the code islands.

image

image

App.xaml.cs – Constructor

Instantiates the singleton Application object which can be thought of being the logical equivalent of main() or WinMain().

This object instantiates the DB  class and calls the LoadDBAsync method to populate the collection of categories, projects and guidance items. Now we know who creates and where it is hiding … but how does it relate to the properties we bind to covered above?

image When we click on the PREPARE map, we find ourselves in the Categories class constructor as shown by this call stack:
image
image

image

When we select the ALM RANGERS project, the call stack changes as follows:
image

When the Projects class is instantiated by the Navigate method, we note the highlighted code which updates the ProjectCollection property.

image 

image The result, as expected is shown on the left, which is in the same logical location as the PLANNING visual example we showed previously.

But … we have still not answered the mysterious reference to property X. 

  image

image

In the XAML definition we notice the ItemSource={Binding ProjectCollection} which defines that the ItemSource property of the View is set to the ProjectCollection property of X, or rather the instance of the View.Projects class.

image

The ItemSource={Binding Guidance} which defines that the ItemSource property of the ListBox  is set to the Guidance property of X, or rather the instance of the collection item of type Models.Project.

        

For more information on the the magic behind the Windows Store App scenes watch RangerTalk - What's new and exciting in .NET 4.5 and Visual Studio 2012, by Robert MacLean.

Final Trivia questions

Dev Lead question time …

image_thumb211_thumb

Q: Looking at the XAML we explored (from Projects.xaml) we are binding the Views.Projects object’s ProjectCollection property to the FlipView and the Model.Projects object’s Guidance property to the ListBox. How does the plumbing resolve the Guidance property and what would happen if both the Views.Projects and Model.Projects classes had the same property?

 
 

Robert MacLean, our dev lead, replies …

If I understand the question is because we are using a DataTemplate - so everything in their is relative to an item in the collection. So even if both Views.Projects & Model.Projects had the same property it wouldn't conflict because one would be collection relative and one would be item relative.

Question:  In essence my brain is trying to figure out how the plumbing behind XAML is working out the relationships, for example, how does it know Guidance property belongs to item in collection … will assume it is magic behind the scenes.

I would go with magic. It is all behind the scenes, & isn't too complex but it is hard to explain simply ;)

Robert-MacLean-v3_thumb21_thumb

Last one …

image_thumb211_thumb

We noticed strange @’s. Can you explain the use of @’s in the treasure map?

image 

 
 

Robert MacLean, our dev lead, replies …

Used with reserved/keys word in C#. I really wanted my variable to be called input because that is what it is, so the @ prefix allows me to create a variable with a reserved name ;) Input isn't a keyword in this context, so the @ could be dropped.

That is why I use the @ but no idea why in this case.

Robert-MacLean-v3_thumb21_thumb

What I have noticed with a Smile is that we have not had to develop much code, other than XAML, to implement a wealth of exciting and productive features.

Next?

In the next post we will peek into the application bar and live tile changes.

References