Introduction to series
Welcome to part one of a four-part series on managing large lists in WPF and WCF. In this series, I will walk you through some of the design considerations for building snappy WPF/WCF solutions. Although this series specifically addresses WPF and WCF, it’s concepts are applicable to Silverlight and other client and service frameworks.
Part one of the series illustrates the basics of WPF data binding; specifically binding to lists of objects.
List-based WPF Controls
ListView, ListBox, ItemsControl, ComboBox, DataGrid, and others. List-based controls are bound to an object that implements IEnumerable via the list control’s ItemSource property.
<ListView x:Name="FoodList"
Grid.Row="1" >
</ListView>
// Binding the ListView to List<Food>
_foodItems = GetLocalFoodItems();
FoodList.ItemsSource = _foodItems;
ItemTemplate
By default, list controls will display the result of Object.ToString(). To customize the display of your objects you use the ItemTemplate.
<ListView x:Name="FoodList"
Grid.Row="1" >
<ListView.ItemTemplate>
<DataTemplate>
<WrapPanel>
<Label Content="{Binding Id}" />
<Label Content="{Binding Description}" />
</WrapPanel>
</DataTemplate>
</ListView.ItemTemplate>
</ListView>
Adding items to the list with ObservableCollection<T>
Currently our ListView is data bound to a List<Food> object. When new Food objects are added directly to the List<Food>, we would like for them to automatically show up in the ListView. Unfortunately the ListView’s binding has no way to detect when items are added to the List<Food>, so the bound list is now out of sync with the list of items displayed in the UI.
We could manually synchronize this ourselves, but that seems like a lot of work. Fortunately, the DataBinding architecture in WPF has a built-in mechanism to do this for us. WPF watches for two interfaces that enable it to keep its bindings synchronized: INotifyPropertyChanged and INotifyCollectionChanged. Both of these interfaces expose events that WPF listens for to update UI components with state changes.
In the System.Collections.ObjectModel (WindowsBase.dll) namespace ObservableCollection<T> is a generic collection that implements both of these interfaces. If we replace our List<Food> with an ObservableCollection<Food>, adding items to the ObservableCollection will now automatically update the UI.
// Add a new Food object to the ObservableCollection<Food>.
// This will automatically update the ListView.
_foodItems.Add(
new Food() { Id = ++_id, Description = "Bacon" }
);
WhatsThat<T>
If you’re unfamiliar or only somewhat familiar with Generic types in the .NET framework, you may be wondering about the <T> syntax. Version 2.0 of the .NET framework introduced Generic Types. These are types that accept a type parameter so that they can provide strongly typed operations where a System.Object would have been required previously.
When reading the statement List<T>, you say “List of T”, where T is a type parameter for some other type. So List<Food> is read “List of Food”.
Summary
In this post, you saw an example of data binding a collection of objects to the WPF ListView control. I showed how to customize the UI of the control by overriding the ItemTemplate. Then I illustrated the different behavior between binding the ListView controls ItemsSource property to List<T> versus an ObservableCollection<T>. These techniques work for all of the WPF list controls.
In part one of the series, the data source was a hard-coded list of Food objects. In part two, I will build a simple WCF service that will serve up Food objects and show some patterns that can be used to maintain a responsive UI when loading large lists of objects.
The source for part one can be downloaded here.
Subscribe