Category: Silverlight

Navigating to view using prism navigation service is straight forward and there are lot of examples on web around this.With MVVM i always found ViewModel first approach as best because of lot of reasons, some of them are

• With MVVM, ViewModels is your application
• No threading issues as you will always create view models which can be created on any thread.
• More responsive , you are not dealing with dispatcher context to create views and let WPF system decide when to create views.
• No Memory leaks, The life cycle of views is controlled by WPF system in most efficient way
• More testable application, Since you app lives in view models and they don’t have UI beasts,
• And lot more..

This post cover a small trick to implement the ViewModel first navigation using Prism 5.0 for WPF.

1. What ever IoC you are using (the code is based on StructuralMap) expose the RegisterForNavigation<T> method and from module initialization, register interface of viewModels participating in navigation process. The RegisterForNavigation<T> will look like

public static void RegisterTypeForNavigation<T>(this ConfigurationExpression reg)
{
reg.For<object>().Use(() => ServiceLocator.Current.GetInstance(typeof(T)))
.Named(typeof(T).FullName);
}

And some where in module initialization you call this method

configurationExpression
.RegisterTypeForNavigation<ICustomerDetailViewModel>();

And to navigate to this view model just use

var parameters = new NavigationParameters { { "Activity", SelectedActivity }, { "ColumnName", columnName } };
var uri = new Uri(typeof(ICustomerDetailViewModel).FullName, UriKind.RelativeOrAbsolute);
regionManager.RequestNavigate(ShellRegions.Workspace, uri, parameters);

And obviously some where in you data template definition there should a (DataTemplate) mapping which WPF uses to swap the view model with corresponding view (and set data context too)..

“Behavior is the base class for providing attachable state and commands to an object. The types the Behavior can be attached to can be controlled by the generic parameter. Override OnAttached() and OnDetaching() methods to hook and unhook any necessary handlers from the AssociatedObject.”
If you using of the behaviors or trigger actions and these subscribe internally on events you’re in trouble. The memory used by them is never released. And could held lot of objects including views in memory causing memory leaks.

“When you subscribe to an event the event source ends up with a hard reference to the event handler. This creates a situation where the event handler cannot be cleaned up as long as the event source exists.”
So to unhook events you probably write code in OnDetaching methods however a behavior might not detach when you expect it to and vice versa, leaving added event handler on the control to survive GC. OnDetaching is only called when you explicitly remove behaviour.
The solution:
The OnAttached is called when XAML parser parses XAML and creates instance of behaviour and adds this to BehaviorCollection of target control which is exposed as DependencyAttached property. However when view is disposed, the collection (Behavior collection) was disposed of, it will never trigger OnDetaching method. If the behaviour is not properly cleanup it will not be collected by GC and will also hold BehaviorCollection and other behaviors in that collection. The behaviours are designed to extend AssociatedObject, as long as you are subscribing to AssociatedObject events its fine as the AssociatedObject (publisher) will die and your behaviour will be collected by garbage collector.

Use BehaviorBase (see code below) to avoid memory leak from behaviours. The same technique can also be used for triggers.
Drive all your behaviors from BehaviorBase class and override OnSetup and OnCleanup methods. OnSetup is triggered when behaviour explicitly is attached to already loaded object at runtime or when object is loaded.
BehaviorBase

 
public abstract class BehaviorBase<T> : Behavior<T> where T : FrameworkElement
{
private bool _isSetup = true;
private bool _isHookedUp;
private WeakReference _weakTarget;

protected virtual void OnSetup() {}
protected virtual void OnCleanup() {}
protected override void OnChanged()
{
       var target = AssociatedObject;
       if (target != null)
       {
              HookupBehavior(target);
       }
       else
       {
              UnHookupBehavior();
       }
}

private void OnTarget_Loaded(object sender, RoutedEventArgs e) { SetupBehavior(); }

private void OnTarget_Unloaded(object sender, RoutedEventArgs e) { CleanupBehavior(); }

private void HookupBehavior(T target)
{
       if (_isHookedUp) return;
       _weakTarget = new WeakReference(target);
       _isHookedUp = true;
       target.Unloaded += OnTarget_Unloaded;
       target.Loaded += OnTarget_Loaded;
       SetupBehavior();
}

private void UnHookupBehavior()
{
       if (!_isHookedUp) return;
       _isHookedUp = false;
       var target = AssociatedObject ?? (T)_weakTarget.Target;
       if (target != null)
       {
              target.Unloaded -= OnTarget_Unloaded;
              target.Loaded -= OnTarget_Loaded;
       }
       CleanupBehavior();
}

private void SetupBehavior()
{
       if (_isSetup) return;
       _isSetup = true;
       OnSetup();
 }

private void CleanupBehavior()
{
       if (!_isSetup) return;
       _isSetup = false;
       OnCleanup();
}
}