Collection Synchronization in WPF

I like the MVVM pattern in WPF. No doubt, it’s a perfect way to separate UI from logic. But you also get some other features out of the box when you apply this pattern. One of my favorites is binding collections to the UI and manipulating them with the use of a background thread. If you’re doing it right, you get a responsive UI while performing heavy background work without any additional effort required synchronizing the data to the view. WPF is just doing it for you.

 

Ok. That’s not 100% of the truth and of course it’s not that easy as it sounds. But there is not much to do. The data is coming from a background thread and it should be displayed in the UI thread. You know what that means? Correct. Someone has to dispatch the data to the UI thread. Luckily there’s a class called Dispatcher in WPF. Even better, you can use the Dispatcher anywhere in your WPF application because it provides a static property (Current) that gives you access to the current Dispatcher instance of the application. On the instance object you have the possibility to invoke any method on the UI thread you like, either synchronous or asynchronous. That was the preferred way until WPF 4.5. The problem was that it was not working in every case. Have you ever tried to modify an ObersableCollection from a background thread while it is bound to a ListView? The invoke methods on the Dispatcher won’t help you. With WPF 4.5 there’s a better and more comfortable approach to that problem: The EnableCollectionSynchronization method.

The EnableCollectionSynchronization method is a static method on the BindingOperations class in the System.Windows.Data namespace. The method has two overloads for controlling the access to the underlying collection from several threads (just have a look at http://msdn.microsoft.com/en-us/library/system.windows.data.bindingoperations.enablecollectionsynchronization(v=vs.110).aspx). So, with this method you may just write something like the following in your view model

BindingOperations.EnableCollectionSynchronization(ListItems, lockObject);

where ListItems is your observable collection and lockObject is some object that will be used by the infrastructure to synchronize the access to the collection from different threads. The magic happens behind the scenes. The method is just a wrapper to some internal functionality enabling the underlying CollectionView to allow cross thread changes. If you want to know some more about WPF internals on handling views and collections you’re invited to read the next parts of the article, otherwise, if you just want to perform cross thread changes to collections bound to UI elements not worrying about how it works, then all relevant information has just been said.

WPF View Management

While using the new EnableCollectionSynchronization method I was wondering what happened behind the scenes when I use that method. In order to cure my curiosity I had a look into the framework and its internal classes. The key requirement of the WPF team was to allow the binding of one collection to many views without having strong references. Additionally the views should be able to sort, filter and navigate the collection without affecting other views or even the source collection itself. Because of those requirements the collection cannot manage its associated views and view management has to happen outside of the collection view relationship. That’s why there is a global ViewManager class that exists per application. This is an internal class with a static Current property. The view manager is just a dictionary that maps all bound collections to corresponding CollectionRecord objects.  The collection record is an internal utility class that keeps a weak reference to a view table and also has its own SynchronizationInfo. The ViewTable class is again a dictionary that manages CollectionViewSources and ViewRecords. Again, the view record acts as a utility class and encapsulates the access to the underlying CollectionView that is used by WPF for realizing sorting, filtering, grouping and navigation functionalities of collections on the UI. The collection view source is the XAML proxy of the collection view. The following picture shows the relationships between the mentioned classes.

 

When you call the EnableCollectionSynchronization method, the call is handled by the RegisterCollectionSynchronizationCallback method of the view manager, which in turn passes it to every collection view that belongs to the given collection. The CollectionView class contains an internal method SetAllowsCrossThreadChanges (see the following listing) which just sets a flag in the collection view whether to allow or deny cross thread operations on the underlying collection.

internal void SetAllowsCrossThreadChanges(bool value)
{
    bool flag = this.CheckFlag(
                     CollectionView.CollectionViewFlags.AllowsCrossThreadChanges);
    if (flag == value)
    {
        return;
    }
    this.SetFlag(
         CollectionView.CollectionViewFlags.AllowsCrossThreadChanges, value);
    this.OnAllowsCrossThreadChangesChanged();
}

This flag is evaluated on binding operations (in our case changing the observable collection). The synchronization info on the collection record is used to synchronize the access the collection. This is where the two overloads of the EnableCollectionSynchronization come into play. The first one takes a lock object that is now used for synchronization. The second overload takes a callback that will be called during synchronization to handle the access among several threads. This provides the possibility for the client to manage the synchronization itself.