How To: Make Your View Models Disposable

This is actually a part two post to one of my earlier posts about using reflection and custom attributes to wire up dependent property change notifications.  Using anonymous methods for such a task works quite well, but I was hitting some roadblocks when trying to use that architecture with models and view models that need to implement IDisposable.

In order for an object to be cleaned up by garbage collection (GC), it cannot be subscribed to an event on an object that is still being held in memory.  The problem I was running into was that I had a couple specific view models that needed to be disposed of and made available for GC, but were still wired up to property changed (and collection changed) events on our business models, which were not being disposed of [intentionally, as they were still being used by the rest of the application].  

So my task at hand was to implement IDisposable in such a way that all event handlers were removed, so the object was no longer referenced in code, and GC could proceed.

Here are the major changes I made to my demo project:

//tracks events subscribed to so Dispose() can unsubscribe

private readonly List<Tuple<object, EventInfo, Delegate>> 

  _subscribedEvents = new List<Tuple<object, EventInfo, Delegate>>();

/// <summary> 
/// Register an event handler, handlers added using this method will be removed in Dispose() method. 
/// </summary> 
/// <param name="publisher">Object publishing event</param> 
/// <param name="eventName">name of event</param> 
/// <param name="handler">event handler to add</param> 
protected void RegisterEventHandler(object publisher, string eventName, Delegate handler) 
{
//already registered - return immediately
if (_subscribedEvents.Any(item => item.Item1.Equals(publisher) && item.Item2.Name.Equals(eventName) && item.Item3.Equals(handler))) return;


//get event info object
var eInfo = publisher.GetType().GetEvent(eventName);  
//add handler
eInfo.AddEventHandler(publisher, handler);


//track the subscription, so we can un-wire it when Dispose() is called
_subscribedEvents.Add(new Tuple<object, EventInfo, Delegate>(publisher, eInfo, handler)); 
}

/// <summary> 
/// Disposes of the object 
/// </summary> 
/// <param name="disposing"></param> 
protected virtual void Dispose(bool disposing) 
{
if (disposing)
{
//remove event handlers for subscribed events
foreach (var item in _subscribedEvents)
item.Item2.RemoveEventHandler(item.Item1, item.Item3);


_subscribedEvents.Clear(); //clear the subscribed events collection, so we're not referencing other objects either
} 
}

Working project/demo download can be found here:

How To: Use interface types with data templates in WPF 4

The short story is, you cannot specify interface types as a value for DataType and this is an example I put together to demonstrate one way around this.

I was recently working on a user control in a resource library project that only had interfaces defined, and was crippled by this limitation in WPF.

Use of DataType is further described here.

Custom Template Selector Class:
public class CustomTemplateSelector : DataTemplateSelector
{
  public CustomTemplateSelector()
  {
    TemplateMappings = new Dictionary();
  }

  public Dictionary TemplateMappings { get; set; }

  public override DataTemplate SelectTemplate(object item, DependencyObject container)
  {
    var itemType = item.GetType();

    var matchingKey = TemplateMappings.Keys.FirstOrDefault(k => k.IsAssignableFrom(itemType));

    return matchingKey != null ? TemplateMappings[matchingKey] : null;
  }
}


Example Usage for ComboBox in XAML:

<ComboBox.ItemTemplateSelector>
<lib:CustomTemplateSelector>
<lib:CustomTemplateSelector.TemplateMappings>
<DataTemplate x:Key="{x:Type sys:String}">
<Grid>
<Grid.ColumnDefinitions>
<ColumnDefinition SharedSizeGroup="DemoItemColumn" />
</Grid.ColumnDefinitions>
<!--bind with no path, item is a string-->
<TextBlock Text="{Binding }" />
</Grid>
</DataTemplate>
<!--IDemoItem data template, note we could specify the actual object type here, but if we were in a
class/resource library that only defined the interfaces, we wouldn't know the type to specify-->
<DataTemplate x:Key="{x:Type lib:IDemoItem}">
<Grid>
<Grid.ColumnDefinitions>
<ColumnDefinition SharedSizeGroup="DemoItemColumn" />
</Grid.ColumnDefinitions>
<!--bind to description property of IDemoItem-->
<TextBlock Text="{Binding Description}" />
</Grid>
</DataTemplate>
</lib:CustomTemplateSelector.TemplateMappings>
</lib:CustomTemplateSelector>
</ComboBox.ItemTemplateSelector>

Full working demo can be downloaded here:
                          

How To: Use custom attributes and reflection to clean up your models and view models

Update: I've updated my demo project, see my updated post here:  http://travisjweber.blogspot.com/2011/02/how-to-make-your-view-models-disposable.html

I've put together a fairly simple example of some of the work I've done in an attempt to clean up endless property changed event handlers, switch statements, and string literals scattered throughout views and view models.

    Think of a calculation that is performed on your view model, in it's getter, you simply return the result of a calculation made using values of other properties on the view model.  This means though, that in order to notify the UI that the value of the calculation has changed, each property that affects the calculation must execute a property changed event for itself as well as the result property.  This is pretty common practice, one set action may fire multiple property changed events.
    But what if the property the calculation depends on is actually a property of another object (model) on the view model?  This means you need to not only notify the result changed when the object changes, but also when a specific property of the object changes, meaning you need to wire up an event handler to the object, create a switch statement in the event handler to determine what property changed, and execute notifications accordingly.

Step 1: Define a custom attribute, used to decorate a property [usually/often read-only] that relies on one or more other properties.

[AttributeUsage(AttributeTargets.Field | AttributeTargets.Property, AllowMultiple=true)]
public class NotifyPropertyAttribute : Attribute
{
public string PropertyName { get; set; }
public NotifyPropertyAttribute(string propertyName)
{
PropertyName = propertyName;
}
}

Step 2: Auto-wire event handlers for property changed events in view models and models.  I am using an abstract base class - NotifiableObject in my example for this.  In the constructor, I am using reflection to loop through all properties of the class, when the NotifyProperty attribute is present an anonymous handler is added to the property changed event so a notification is also generated for the decorated property.

Here is the main block of code I'm using to loop through the properties with the notify property attributes, AttachChildren is a recursive method I'm using to do the dirty work, see example solution for more details.


private void WireUpBubblingPropertyChangeNotifications()
{
//this gets all properties, public and private, so you can use the INotifyPropertyChanged interface even for private fields
var props = GetType().GetProperties(BindingFlags.Public | BindingFlags.NonPublic | BindingFlags.Instance);

foreach (var prop in props)
{
var attrs = prop.GetCustomAttributes(true);

foreach (var attr in attrs.OfType<NotifyPropertyAttribute>())
{
AttachChildren(prop.Name, this, attr.PropertyName);
}
}
}


Sample Solution: NotifyPropertyAttributeExample.zip

Edit: Above link is not working, try downloading from here instead:
http://cid-edc8bd4a11230d7b.office.live.com/browse.aspx/.Public/blog

Feel free to shoot me an email with questions/suggestions, I still have some work to do to refine this a bit and provide more functionality.  I am working on a project that has a very hierarchical data structure, and found myself constantly needing to wire up event handlers for child objects' property changed notifications, and bubble them up to parent models & view models.  This approach has already cleaned up much of our code.