It’s actually kind of difficult to imagine writing anything in WPF without using at least one ObservableCollection or several instances of INotifyPropertyChanged (INPC). And it’s important to note that neither of these are perfect out of the box. I have spent a bit of time talking about ways to streamline your INPC implementations in the 3-part series “Creating a Model Base“, and plan to have another update to that soon. This topic will focus on the ObservableCollection.
Here are a few reasons why we use it:
- When controls bind to them, Add, Move, and Remove actions automatically update in the UI without any need to directly update those controls.
- It has a CollectionChanged event allowing us to leverage when items are added, moved, or removed.
Essentially, it let’s us know when our collection gets updated and allows us to leverage the UI without much effort.
Q: So, why extend it?
A: Because there are some extras all good collections should have to make our lives easier.
For this article, we’ll start simple with a few extensions, then move on to multi-threading, then sorting.
Apply
One extension I have always wanted to see in any collection is the ability to commit changes to a list in one line. That is what Apply is good for.
So, normally if you wanted to set all the items in a collection to true (assuming the model has a property called “IsSelected”), you would do the following:
foreach (var item in collection)
{
item.IsSelected = true;
}
With Apply I could write the same code like this:
collection.Apply(x => x.IsSelected = true);
The code is relatively simple:
/// <summary>
/// Applies the specified changes to the collection.
/// </summary>
/// <typeparam name="T"></typeparam>
/// <param name="items">The items.</param>
/// <param name="predicate">The predicate.</param>
public static void Apply<T>(this IEnumerable<T> items, Action<T> predicate)
{
foreach (var item in items)
{
predicate(item);
}
}
It’s our familiar for loop that processes each item with the same predicate in a lambda expression.
AddRange and RemoveRange
I am of the belief every collection should allow you to add or remove multiple items at a time. We already have this functionality in List, so why not here? It’s actually not hard at all with our friend >Apply:
/// <summary>
/// Adds the range.
/// </summary>
/// <typeparam name="T"></typeparam>
/// <param name="items">The items.</param>
/// <param name="collection">The collection.</param>
public static void AddRange<T>(this IList<T> items, IEnumerable<T> collection)
{
// Add range to local items
collection.Apply(items.Add);
}
/// <summary>
/// Removes the range.
/// </summary>
/// <typeparam name="T"></typeparam>
/// <param name="items">The items.</param>
/// <param name="collection">The collection.</param>
public static void RemoveRange<T>(this IList<T> items, IEnumerable<T> collection)
{
// Remove range from local items
collection.Apply(p => items.Remove(p));
}
If we want to add multiple items to our collection, for example, all items that are selected in a new collection, all we would have to do is this:
collection.AddRange(newCollection.Where(p => p.IsSelected));
If we want to remove the unselected items listed in the new collection, we would do this:
collection.RemoveRange(newCollection.Where(p => p.IsSelected == false));
SynchCollection
Another common need is to be able to synch the items of 2 collections. This is often used as a way to maintain the instance of the target collection having it update itself based on the contents of another collection.
Our first method matches the item content in our target collection based on the provided source:
/// <summary>
/// Synches the collection items to the target collection items.
/// This does not observe sort order.
/// </summary>
/// <typeparam name="T"></typeparam>
/// <param name="items">The items.</param>
/// <param name="collection">The collection.</param>
public static void SynchCollection<T>(this IList<T> items, IEnumerable<T> collection)
{
// Evaluate
if (collection == null) return;
// Make a list
var list = collection.ToList();
// Add items not in FilteredViewItems that are in list
items.AddRange(list.Where(p => items.IndexOf(p) == -1).ToList());
// Remove items from FilteredViewItems not in list
items.RemoveRange(items.Where(p => list.IndexOf(p) == -1).ToList());
}
AddRange and RemoveRange are a big help here; allowing us to tidy up our code quite a bit.
Q: What about sorting?
A: We need to do a little more work for this, but with an ObservableCollection instead of a List as our target this is possible.
/// <summary>
/// Synches the collection items to the target collection items.
/// </summary>
/// <typeparam name="T"></typeparam>
/// <param name="items">The items.</param>
/// <param name="collection">The collection.</param>
/// <param name="canSort">if set to <c>true</c> [can sort].</param>
public static void SynchCollection<T>(this ObservableCollection<T> items,
IList<T> collection, bool canSort = false)
{
// Synch collection
SynchCollection(items, collection.AsEnumerable());
// Sort collection
if (!canSort) return;
// Update indexes as needed
for (var i = 0; i < collection.Count; i++)
{
// Index of new location
int index = items.IndexOf(collection[i]);
if (index == i) continue;
// Move item to new index if it has changed.
items.Move(index, i);
}
}
Since we are talking sorting, we should be talking about ObservableCollections. We go ahead and use our previous SynchCollection method to handle the synch. After that, all we need to do is compare indexes between collections and move items as needed.
Note: This collection does not take a sort comparer because it assumes the source collection is already sorted. You should handle this type of operation independently.
And that’s all there is to it. Next time we will talk about Multithreading an ObservableCollection to offload the work from the UI thread.
If you have ideas for other extensions you would like to see, comment below.
Until next time.
Excelent !