Treasure Map under the bonnet (hood) #4 … Data Binding
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
 |
|
|
The TreasureMapDataModel.xml is the heart of the treasure map data model, defining the state of jewels of our ALM journey. |
|
We have one or more categories, which map to the planning, guidance, tooling and workshop islands we introduced in previous posts. |
|
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. |
|
Each category contains zero or more guidance items, which currently embrace guidance, tooling, videos and Demomate recordings. |
Treasure Map Object Binding
 |
|
|
We peek into the Projects.xaml view, collapse the regions which are not relevant and zoom into four areas in this XAML file. |
|
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! |
|
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. |
|
Text={Binding GuidanceType } defines that the Text property of the TextBlock of the grid item is set to the GuidanceType property of X. |
|
Text={Binding Url } defines that the Text property of the Run item is set to the Url property of X. |
|
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:
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.
Let’s set a few breakpoints and sail through the code islands.
 |
App.xaml.cs – ConstructorInstantiates 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? |
 |
When we click on the PREPARE map, we find ourselves in the Categories class constructor as shown by this call stack:  |
  |
When we select the ALM RANGERS project, the call stack changes as follows: When the Projects class is instantiated by the Navigate method, we note the highlighted code which updates the ProjectCollection property.
|
 |
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.
 |
|
|
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. |
|
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 …
 |
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 ;) |
 |
Last one …
 |
We noticed strange @’s. Can you explain the use of @’s in the treasure map?
|
|
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. |
 |
What I have noticed with a 
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.