Wow, its been quite the journey but here we are finally at the end.

To restate the previous articles – We took a Windows store app that was coded without a ViewModel.  We refactored the code to have a ViewModel which is placed in a shared location, along with the Model.  The final View has almost no code and is decoupled from the XAML.  The interaction between the ViewModel and View is all facilitated by bindings, keeping the ViewModel logic abstract from the details of the View.

The last thing we are going to do is to develop a new View for Windows Phone and reuse both the Model and ViewModel.

The Phone View

Coding the phone view was really simple.  I “cheated” a little and made the phone view very similar to the desktop view.  It consists of a ListBox, a TextBox and a bunch of buttons.  The MainPage class does the same thing as the Windows version – constructs an instance of the ViewModel and sets the DataContext to point to it.  The XAML code looks very similar – just things are in different positions and the styles are different.

The whole thing took me maybe 10 mins to code up and tweak the layout to get the sizes and spacing right.   Which shows how empowering a reusable ViewModel is.

I wanted to make the phone view at least a little different, so instead of 2 radio buttons to switch between Hex and Decimal I used a button on the command bar. 

Due to that difference we can’t deal with the button the same way the we did in Windows.  So I enhanced the ViewModel to support a SwitchModeCommand which toggles between the 2 modes. 

I wanted to call that out because, in my opinion, it is OK for a ViewModel to have pieces which are targeted at one platform vs the other.  When used infrequently it seems like a very practical way to develop your application.  However it would be concerning if the shared part of your ViewModel starts becoming a smaller and smaller percentage of the total ViewModel code.  If that was the case then I’d start questioning what is going on.  On one extreme it could indicate a bad ViewModel design.  On the other extreme it could indicate that the Views are so different that sharing code isn’t practical.  It would really be case-by-case, although most times it is bad ViewModel design.

Wait There’s More

Just like in your favourite infomercial, don’t order yet – more cool stuff to come.

Because Views are now so easy to code we can add more than 1 for phone.  For example we could easily support a Landscape view in addition to the Portrait one we just created.

To do this we first want to make the markup easy to replace at runtime.  Enter the ContentControl.  This is a control which takes some data (Content) and markup (ContentTemplate).  It then combines the 2 – making the Content the DataContext of the template.  In this case our data is fixed (the ViewModel) but we can switch the template at runtime for different renderings. 

This may sound like magic, but it is actually a key piece of XAML’s composability.  For example Button is a subclass of ContentControl.  That is what allows you to put stuff like text, images, etc inside a button. 

To make the change we take our View markup and wrap it inside a DataTemplate element and then put it in the Resources section with a key name. 

    <Page.Resources>

        <DataTemplate x:Key="PortraitViewTemplate">

            <Grid>

                <Grid.RowDefinitions>

                    <RowDefinition Height="*" />

                    <RowDefinition Height="Auto" />

                    <RowDefinition Height="Auto" />

                </Grid.RowDefinitions>

                <Grid.ColumnDefinitions>

                    <ColumnDefinition Width="*" />

                </Grid.ColumnDefinitions>

                <Grid

                    x:Name="StackGrid"

                    Grid.Row="0"

                    Grid.Column="0"

                    >

…snip…

We then put the ContentControl in our page and set its properties.

        <ContentControl

            Content="{Binding}"

            ContentTemplate="{StaticResource PortraitViewTemplate}"

            />

Now we are prepped to add a Landscape View.  To do that I define a new DataTemplate in the resources and call it LandscapeViewTemplate.  Inside that template we define the markup we want for the landscape view.  Then we need to add the code to switch between the 2 templates appropriately.  For that we need to:

·        Update the manifest to indicate we support both portrait and landscape modes

·        Give our ContentControl a name so we can reference it in our View code (appropriate since this is a View layer thing)

·        Set the right template for both the initial state and when orientation changes

And so here is the XAML:

        <ContentControl

            x:Name="PageContentControl"

            Content="{Binding}"

            />

And here is the page code:

        public MainPage()

        {

            _displayInfo = DisplayInformation.GetForCurrentView();

            _displayInfo.OrientationChanged += OnOrientationChanged;

            _viewModel = newStackCalculatorViewModel();

            this.DataContext = _viewModel;

            this.InitializeComponent();

            this.NavigationCacheMode = NavigationCacheMode.Required;

            UpdateViewTemplate();

        }

        void UpdateViewTemplate()

        {

            string resourceName;

            if(_displayInfo.CurrentOrientation == DisplayOrientations.Landscape)

            {

                resourceName = "LandscapeViewTemplate";

            }

            else

            {

                resourceName = "PortraitViewTemplate";

            }

            var template = (DataTemplate) this.Resources[resourceName];

            this.PageContentControl.ContentTemplate = template;

        }

        void OnOrientationChanged(DisplayInformation sender, object args)

        {

            UpdateViewTemplate();

        }

 And here is the end result:

Whats Next

Obviously MyCalc is not a finished and polished app ready to be published to the app store.  So there is a decent amount of work left to get to that point beyond the ViewModel focus of this series.

I’m just going to enumerate a few things that would be at the top of my list to fix, if I were to seriously try and take this to the app store.

Too many commands – right now add, subtract, multiply and divide each have their own command.  When I think about new features like square root and trig functions this would cause an explosion of commands.  Likely this should be handled in a way similar to the command to add to the text box, using the parameter to differentiate the buttons.  I’m not really thrilled with a huge switch statement in the code, but it seems the lesser of 2 evils compared with tens of command properties and backing methods.  Seems like having a command for all the buttons which share the same number or arguments is a decent compromise between the 2 extremes.

ListBox doesn’t scroll – if one adds enough numbers to fill the viewable area of the list box, and then adds another the ListBox doesn’t scroll the new number into view.  This could be solved in multiple ways.  One way is an attached service that you attach to the ListBox control.  It can monitor when the Items collection gets a new item added to the end, and call ListBox.ScrollIntoView with that new item.

AppBarButton – I don’t like how the AppBar takes up so much space for just the one button.  I’d like to get rid of it.  Perhaps some “tabs” in the UI to allow the user to expose additional settings/commands since there isn’t enough room to put everything on a single page.

Enter Button – it would be cool if the user didn’t have to hit Enter all the time.  Wouldn’t it be cool to type in that second number and be able to hit Add immediately, without hitting Enter first.  This functionality could either be pushed into the Model, or we could have the ViewModel push and pop the number appropriately as the user types.  Either approach has its own pros & cons.

Better UI – My dev design UI works, but isn’t anywhere close to pretty or polished.  So having UI designed by someone with skills would be a big plus.

Bring Orientation Support To Desktop – Why can’t the desktop app work in Portrait as well as Landscape?  No good reason.  Seems like there is also an opportunity for more code sharing…

Wrapping it Up

Having reusable ViewModel enabled me to get my Windows app running on phone supporting both Landscape and Portrait views really easily.  I probably spent about 30 mins coding. 

If we were to have estimated the cost to add a phone version of the app based on the code in part 1, the estimate would have been much higher than 30 mins.  To add both Landscape and Portrait views would have caused the cost to climb even more.  As well as the end result would have left us with a lot more code, raising future costs for maintenance and additional features.

It is easy to image going beyond the simple landscape & portrait views and develop skins – user switchable views to make it look like a physical calculator, or like all the buttons are made of wood, etc…

I hope this series of articles have shown you the power of having a reusable view model, and also a bit of education on how to design and develop a ViewModel.

As always complete code is attached.

MyCalc - part 5.zip

To restate where part 3 ended – We have migrated all the buttons and TextBox to use the ViewModel.  What is left is the display of the items on the stack and the mode radio buttons.

Handling Radio Buttons

There are a few different ViewModel patterns which work with RadioButtons.

Option #1 – Since RadioButton supports Command we could make a ChangeModeCommand which takes a parameter of the new mode. 

The pros of this solution are:

·        It works well if other supported views uses controls which support commands for changing modes (i.e. some kind of button style)

The cons are:

·        Can’t set initial button state

·        Doesn’t update state of other buttons 

·        CanExecute should always return true, otherwise radio buttons will get disabled

Those issues can be solved, but will require more work.  Which implies we should only go this route if we need commands for the other view implementations.  At this point we haven’t designed the phone UI, so going with a low cost solution is probably best.  Plus I’d like to demonstrate some other techniques.

The next 2 options are variations on 2 way bindings.

Options #2 – Add an IsHexMode and IsDecimalMode bool properties to the ViewModel and 2 way bind the RadioButton.IsChecked to them. 

The pros of this solution are:

·        Very simple and easy to understand

·        Allows configuring initial control state

·        Updates control state of all RadioButtons

The cons are:

·        Only works well for RadioButton UI

·        Doesn’t scale if the number of modes increases

Option #3 – 2 way bind to the Mode property and use a converter to convert back and forth between CalculatorMode and bool.

The pros of this solution are:

·        Just 1 property regardless of number of modes

·        Allows configuring initial control state

·        Updates control state of all RadioButtons

·        Different (or none) converters can be used for other UIs (i.e. enums work well with ComboBoxes)

The cons are:

·        Have to be careful that we have 1 “winner” when buttons change (i.e. 1 RadioButton should change the mode, the others shouldn’t even though their IsChecked property changes)

In this example we are going with Option #3 because not only is it a good choice, but it allows me to demonstrate a new ViewModel technique.  To implement a converter we define a class and have it implement IValueConverter.  Since we will be using it in 2 way bindings we implement both Convert and ConvertBack.

If this was WPF we’d be able to pass the enum value in as the ConverterParameter, but Windows store apps don’t support x:Static like WPF does, so we need to pass the value in as a string.  Then inside the converter parse the string into the right mode enum value.

Here is the implementation:

    publicclassBoolToCalculatorModeConverter : IValueConverter

    {

        public BoolToCalculatorModeConverter()

        {

            // nothing

        }

        publicobject Convert(object value, Type targetType, object parameter, string language)

        {

            var desiredMode = StringToMode((string)parameter);

            var acutalMode = (CalculatorViewMode)value;

            return (desiredMode == acutalMode);

        }

        publicobject ConvertBack(object value, Type targetType, object parameter, string language)

        {

            var state = (bool)value;

            var desiredMode = StringToMode((string)parameter);

            if(state)

            {

                return desiredMode;

            }

            else

            {

                // since we don't know the right value, just return null

                returnnull;

            }

        }

        CalculatorViewMode StringToMode(string value)

        {

            switch(value)

            {

                case"Decimal":

                    returnCalculatorViewMode.Decimal;

                case"Hex":

                    returnCalculatorViewMode.Hex;

                default:

                    thrownewNotSupportedException();

            }

        }

    }

You’ll notice in ConvertBack we solve the issue of the unchecked RadioButtons from changing the mode by returning null, which isn’t a valid enum value.  That causes the binding to fail and not update the property.

Then in the XAML we first declare an instance of the converter in the Resources section, and then update the RadioButton to bind to the value using the Converter.  Here is the code for one of the RadioButtons:

            <RadioButton

                x:Name="_HexSelection"

                Grid.Column="0"

                Grid.Row="1"

                Style="{StaticResource RadioButtonStyle}"

                Content="Hex"

                GroupName="NumbericType"

                IsChecked="{Binding Mode, Converter={StaticResource BoolToCalculatorModeConverter}, ConverterParameter=Hex, Mode=TwoWay}"

                />

And of course we need to go into our View and rip out all the code which interacted with the RadioButtons.

Picking a Solution for Stack Content Display

Now we are down to the last bit of View code – that dealing with populating the ListBox with the stack contents, formatting appropriately for the mode.

If this was WPF we could use a MultiBinding and IMultiValueConverter.  That would allow us to bind to the number and mode, and in the converter format the value appropriately and return it.  It would be re-evaluated when the values of the bindings change.  However this isn’t available for Windows Store apps currently.

We could also solve this with a custom control for the content for the ListBoxItems.  But that seems like a heavy handed solution.  It also limits reusability as other Views may not be able to re-use that control for whatever reason.

Another way is to expose a collection of strings from the ViewModel and then update this collection when the mode changes and when the stack changes.  This can be a reasonable solution and is pretty straightforward to implement.  Something like a ConvertingReadOnlyObservableCollection can help make that happen.  When the mode changes you could either re-build the shadow collection with newly formatted strings.  Or the collection could be a ViewModel class with a string property for the formatted string.  Then when the mode changes one can enumerate the collection and tell each object to re-format, which as it does will raise a PropertyChanged event to cause the bindings to update.

I’m going to go with a different solution, which uses an Attached Service (some people call it an Attached Behavior).  If you haven’t had experiences with these then it may feel weird and require some getting used to.  It will allow the ItemsControl and bindings do the work, rather than us having to explicitly code it.

Attached Services

You may be aware that XAML controls use a thing called DependencyProperty.  This allows controls to do stuff like inherit property values from their parent controls in a seamless way for us using the controls.  A closely related thing is an AttachedDependencyProperty.  This is a property defined on one class, but you actually set/retrieve the values on instances of other classes – weird, right?

I’ll not go into how this is implemented internally, just believe that it does work and allows us to do some things which are usually unconventional.

I bet you’ve used these before and never realized you were using attached properties.  For example if you add Grid.Column=”3” onto a TextBox then you are setting the value for an attached property.  The Grid implementation then reads these values when performing layout.

One of the tricky things you can do with an attached property is register a callback for when the property is changed.  This callback gets as the sender the object that the property has been applied to.  At that point you can interact with that object – get/set properties, call methods, etc...  It is typically the implementation of the changed callback that turns this into a “service” instead of just a stored value.

What is great about attached services is that if written right they can apply to just about any control, even custom ones.  And you can apply different attached services to the same control instance, allowing you to combine behaviors.  This is very superior to traditional methods like sub-classing or custom controls.

CalculatorNumberFormatter

The attached service we are going to implement is CalculatorNumberFormatter.  It will define 3 attached properties.  2 are input properties – Number and Mode.  Number is designed to be bound an integer value.  Mode is designed to be bound to the current Mode.  When either of those properties change it will run code which will correctly format the integer into a string based on the mode.  The resulting value will be placed in an output parameter called Text.

Then the control that these properties are attached to can bind it’s Content/Text property to CalculatorNumberFormatter.Text. 

Not only will this correctly format the number correctly initially, but it will respond if the mode changes.  And this will happen in a better way than the initial View oriented implementation we had, because it will not clear and rebuild the listbox.  It also works if the ListBox (or any ItemsControl) is virtualizing (but we will not dive into that in this series).

Before we look at the code I’d like to point out that we could have avoided the Text property and instead casted the DependencyObject we are attached to into what control it actually is, like TextBlock.  However this limits reuse as it wouldn’t work with other controls.

Here is the code for one of the attached properties.  You’ll notice we both define the static property, and add Get/Set methods.  Those methods are helpful, but also required for the XAML to compile.

        publicstaticreadonlyDependencyProperty ModeProperty = DependencyProperty.RegisterAttached(

                                                                        "Mode",

                                                                        typeof(CalculatorViewMode),

                                                                        typeof(CalculatorNumberFormatter),

                                                                        newPropertyMetadata(null, ModeProperty_PropertyChanged));

        publicstaticCalculatorViewMode GetMode(DependencyObject obj) { return (CalculatorViewMode)obj.GetValue(ModeProperty); }

        publicstaticvoid SetMode(DependencyObject obj, CalculatorViewMode value) { obj.SetValue(ModeProperty, value); }

        staticprivatevoid ModeProperty_PropertyChanged(DependencyObject o, DependencyPropertyChangedEventArgs e)

        {

            FormatNumber(o);

        }

The Number and Text properties are similar – just different names and types.

FormatNumber gets the Number and Mode values (handling if they aren’t set) and sets the Text property.

        staticvoid FormatNumber(DependencyObject o)

        {

            var mode = (CalculatorViewMode?) o.GetValue(ModeProperty);

            var value = (Int64?)o.GetValue(NumberProperty);

            if (mode.HasValue && value.HasValue)

            {

                string text;

                if (mode == CalculatorViewMode.Hex)

                {

                    text = String.Format(CultureInfo.CurrentCulture, "0x{0:X}", value.Value);

                }

                else

                {

                    text = String.Format(CultureInfo.CurrentCulture, "{0:G}", value.Value);

                }

                SetText(o, text);

            }

        }

Applying CalculatorNumberFormatter to the ListBox

In order to apply this attached service to the ListBox we start off by binding the ItemsSource property to the Stack collection.  Logic inside the control will create a child control for each item.  We also set the ItemTemplate property so we can control the details of what those child controls expose.

One thing to be aware of is that the DataContext for the ListBoxItem children is not the ViewModel, but a specific item from the ItemsSource collection – in this case an int from our Stack collection.  So binding without a Path value will give use that object.  To get a reference to our view model, which has the Mode property we need, we need to use some additional features of binding.  Our choices in a Windows Store app are more limited than in WPF, but we only need 1 way that works.  In this case using ElementName and specifying an element outside the ListBox will work nicely.

That handles binding the Number and Mode properties.  All that is left is to connect TextBlock.Text to CalculatorNumberFormatter.Text.  I tried doing this the typical way and was having issues getting it to work.  So I wound up reversing it and making the binding 2 way to feed the value to the right place.

The result is this:

            <ListBox

                x:Name="_StackBox"

                Grid.Column="0"

                Grid.ColumnSpan="2"

                Grid.Row="0"

                Margin="4"

                FontSize="32"

                ItemContainerStyle="{StaticResource ListBoxItemStyle}"

                ItemsSource="{Binding Calculator.Stack}"

                >

                <ListBox.ItemTemplate>

                    <DataTemplate>

                        <TextBlock

                            local:CalculatorNumberFormatter.Number="{Binding}"

                            local:CalculatorNumberFormatter.Mode="{Binding DataContext.Mode, ElementName=StackGrid}"

                            local:CalculatorNumberFormatter.Text="{Binding Text, RelativeSource={RelativeSource Mode=Self}, Mode=TwoWay}"

                            />

                    </DataTemplate>

                </ListBox.ItemTemplate>

            </ListBox>

We can then clean out the ListBox related code out of the view.

Wrapping it Up

We are now done with the first phase.  Our MainPage class no longer has any logic in it.  The only thing we have in there that isn’t part of the VS broiler plate is the code to create the ViewModel and assign the DataContext.

We learned a few new techniques to decoupling logic so we can have a View independent ViewModel and maximize code reusability.

·        ValueConverters can be used to bridge the gap between how our ViewModel works and the needs of a specific control

·        Attached services are a powerful technique to connect custom logic to any control, helping us customize behaviors and overcome system limitations

In the next edition we’ll take this completed ViewModel and build a phone view on top of it – proving that we can re-use it for different Views.

MyCalc - part 3.zip

To restate where part 2 ended – We took the MyCalc app and created an empty ViewModel class.  We then implemented DelegateCommand so we could expose ICommand objects from the ViewModel.  We used that to create commands for the majority of the buttons and modified the XAML to use them.  This allowed us to remove some code from the View.

Binding to EnterText

This next step we want to get rid of the coupling to EnterBox.  Fortunately this is pretty trivial.  The solution is a simple data binding.  There are just 2 details we need to see to while settings up the binding.  The first is to make the binding 2 way, so as the control changes the new value is pushed into the View Model.  The second is to set the update mode so that the binding update occurs on each keystroke.

What we wind up with is this:

            <TextBox

                x:Name="_EnterBox"

                Grid.Column="0"

                Grid.Row="1"

                Margin="4"

                Width="400"

                FontSize="32"

                Text="{Binding EnterText, Mode=TwoWay, UpdateSourceTrigger=PropertyChanged}"

                />

Now the View can just interact w/ EnterText rather than the control.  It also doesn’t need that code we added to copy the string back and forth between the control and view model.

Number Mode

To unblock the next set of changes we need to make the view model aware of the number nodes – decimal vs hex.  There are multiple ways we can do this – for example we could have a bool IsHex property.  However I personally prefer an enum.

Not only does the enum make the code more readable, but it also sets us up to support other number modes in the future.

    enumCalculatorViewMode

    {

        Decimal,

        Hex

    }

        publicCalculatorViewMode Mode

        {

            get

            {

                return _mode;

            }

            set

            {

                if(_mode != value)

                {

                    _mode = value;

                    _addDigitCommand.RaiseCanExecuteChanged();

                    RaisePropertyChanged("Mode");

                }

            }

        }

We also update the View code so that when the radio buttons are changed we update this ViewModel property appropriately.

Supporting Hex Entry

With that property in the view model we now have the information we need to correctly enable/disable the A-F buttons. 

We update the can execute to correctly compute if the hex buttons are enabled.  In addition in the Mode setter we raise the CanExecuteChanged event for the AddDigitCommand.

        privatebool OnAddDigitCanExecute(object parameter)

        {

            var stringParameter = (string)parameter;

            switch(stringParameter)

            {

                case"0":

                case"1":

                case"2":

                case"3":

                case"4":

                case"5":

                case"6":

                case"7":

                case"8":

                case"9":

                    returntrue;

                case"A":

                case"B":

                case"C":

                case"D":

                case"E":

                case"F":

                    return (Mode == CalculatorViewMode.Hex);

                default:

                    returnfalse;

            }

        }

We can then update the XAML and View code just like we did for the 0-9 buttons.

Enter Button

The last thing we are going to do in this part is convert the Enter button to use the View Model.  Just like the other buttons we add a new command, wire it up in the XAML and remove the obsolete code from the View.

I called it PushCommand, since that is the logical operation of the Enter button and here is its implementation:

        privatevoid OnPushExecuted(object parameter)

        {

            NumberStyles styles;

            if (Mode == CalculatorViewMode.Hex)

            {

                styles = NumberStyles.HexNumber;

            }

            else

            {

                styles = NumberStyles.Integer;

            }

            Int64 value;

            if (Int64.TryParse(EnterText, styles, CultureInfo.CurrentCulture, out value))

            {

                _calc.Push(value);

                EnterText = String.Empty;

            }

        }

        privatebool OnPushCanExecute(object parameter)

        {

            return (EnterText.Length > 0);

        }

Wrapping it up

This part introduced 2 way bindings as a way to link a TextBox control with a ViewModel property.  By adding the Mode property to the ViewModel we were able to move the remaining Button’s to use ICommand.

This also shows how easy enhancing the view model is once you have some ViewModel infrastructure coded, like DelegateCommand.

Now all that remains in the View is code to handle displaying the stack and responding to the RadioButtons.  Getting rid of that code will be the subject of the next instalment.

MyCalc - part 3.zip

To restate where part 1 ended - We have our Windows App, MyCalc, which currently has no ViewModel and instead has all the logic in the View layer.  Which means it can’t be reused for different views, such as one for phone.  Our goal is to move that logic into a shared ViewModel and add a Phone view.

Adding a ViewModel

The first step is to add an empty ViewModel class.  So in the shared code project we create a new class called StackCalculatorViewModel. 

One thing just about every ViewModel needs is a way to communicate data changes to the View layer.  In XAML there is already a standard way to do this that works with data binding (more about that later).  That way is the INotifyPropertyChanged interface.  It allows us to raise an event with the name of the property that has changed.  So lets implement that interface, and a helper method to raise the event.

        privatevoid RaisePropertyChanged(string propertyName)

        {

            var eh = this.PropertyChanged;

            if(eh != null)

            {

                eh(this, newPropertyChangedEventArgs(propertyName));

            }

        }

        publiceventPropertyChangedEventHandler PropertyChanged;

The next thing our ViewModel needs is a reference to the Model, which is our StackCalculator class.  So we add a private field of type StackCalculator and in the constructor initialize it to a new instance of that class.

Lastly we need to give the View access to our ViewModel.  So in our MainPage class we add a private field of type StackCalculatorViewModel.  In the constructor we assign it to a new instance of that class.

And here is the “tricky” part – we set the MainPage.DataContext to point to the ViewModel.  The DataContent property is inherited by all the child controls, so now all the controls can access the ViewModel.  Not only that but DataContext is the default data binding source, which will come in handy later.

    publicsealedpartialclassMainPage : Page

    {

        StackCalculatorViewModel _viewModel;

        public MainPage()

        {

            _viewModel = newStackCalculatorViewModel();

            _viewModel.PropertyChanged += _viewModel_PropertyChanged;

            var collectionChanged = (INotifyCollectionChanged)_viewModel.Calculator.Stack;

            collectionChanged.CollectionChanged += collectionChanged_CollectionChanged;

            this.DataContext = _viewModel;

            this.InitializeComponent();

            // initial to defaults

            DecimalSelection.IsChecked = true;

            UpdateEnterBoxButtons();

            UpdateStackBox();

        }

You’ll likely notice we removed the StackCalculator field from MainPage, and instead reference the StackCalculator object held in the ViewModel.  This is temporary code that will go away once the ViewModel is fully fleshed out. 

Moving Logic to the ViewModel

Now we have an empty view model and we need to pick some logic to move into it.   Buttons tend to be pretty easy to support in a ViewModel, so we’ll start with those.

To bite off a reasonable chunk of work we are going to limit this to the buttons 0-9, add, subtract, multiply, divide and drop.

Buttons are easy to support with a ViewModel because they support having a command – meaning we can provide an instance of ICommand which allows us to execute code when the button is clicked.  It also allows us to enable/disable the button when conditions change.

ICommand and DelegateCommand

ICommand, as an interface, is perfect for our use in the ViewModel.  However there isn’t an implementation of that interface that is ViewModel friendly.  So we need to code our own implementation.  The most common implementation is along the lines of what I call DelegateCommand.  Simply put when one constructs a DelegateCommand one provides delegates to the implementations you want of Execute and CanExecute.  Thus the implementation is a simple Adapter to the required interface.  Add a method to raise the CanExecuteChanged event when needed and you are done.

My particular implementation has 2 constructors:

·        One that takes an ExecuteHandler

·        Another that takes an ExecuteHandler and CanExecuteHandler

The version that just takes an ExecuteHandler supplies an implementation of CanExecute which always returns true.  This is makes it just a little easier for supporting buttons that are always enabled.

    delegatevoidExecuteHandler(object parameter);

    delegateboolCanExecuteHandler(object parameter);

    classDelegateCommand : ICommand

    {

        privateExecuteHandler _executeHandler;

        privateCanExecuteHandler _canExecuteHandler;

        public DelegateCommand(ExecuteHandler executeHandler):

            this(executeHandler, CanAlwaysExecute)

        {

            // nothing

        }

        public DelegateCommand(ExecuteHandler executeHandler, CanExecuteHandler canExecuteHandler)

        {

            _executeHandler = executeHandler;

            _canExecuteHandler = canExecuteHandler;

        }

        publicvoid RaiseCanExecuteChanged()

        {

            var eh = this.CanExecuteChanged;

            if(eh != null)

            {

                eh(this, EventArgs.Empty);

            }

        }

        publicbool CanExecute(object parameter)

        {

            return _canExecuteHandler(parameter);

        }

        publiceventEventHandler CanExecuteChanged;

        publicvoid Execute(object parameter)

        {

            _executeHandler(parameter);

        }

        privatestaticbool CanAlwaysExecute(object parameter)

        {

            returntrue;

        }

    }

Using DelegateCommand in our ViewModel

Ok, now that we have an implementation of ICommand we can use, lets wire it up in our ViewModel.

First we add private methods for Execute/CanExecute that we need for the commands we will expose.  As an example here is are the implementation for the add command:

        privatevoid OnAddExecuted(object parameter)

        {

            _calc.Add();

        }

        privatebool OnAddCanExecute(object parameter)

        {

            return _calc.CanAdd();

        }

We also expose the command as a property so the Button can bind to it, like this:

        publicICommand AddCommand

        {

            get

            {

                return _addCommand;

            }

        }

And in the constructor we create the DelegateCommand instance providing the right methods, like this:

        public StackCalculatorViewModel()

        {

            _enterText = String.Empty;

            _calc = newStackCalculator();

            var collectionChanged = (INotifyCollectionChanged)_calc.Stack;

            collectionChanged.CollectionChanged += OnStackChanged;

            _addCommand = newDelegateCommand(OnAddExecuted, OnAddCanExecute);

            _subtractCommand = newDelegateCommand(OnSubtractExecuted, OnSubtractCanExecute);

            _divideCommand = newDelegateCommand(OnDivideExecuted, OnDivideCanExecute);

            _multiplyCommand = newDelegateCommand(OnMultiplyExecuted, OnMultiplyCanExecute);

            _popCommand = newDelegateCommand(OnPopExecuted, OnPopCanExecute);

            _addDigitCommand = newDelegateCommand(OnAddDigitExecuted, OnAddDigitCanExecute);

            _backspaceCommand = newDelegateCommand(OnBackspaceExecuted, OnBackspaceCanExecute);

        }

Just one last thing and the AddButton can be complete – that is raising the OnCanExecuteChanged appropriately.  Our Model doesn’t expose an event directly for this, but does let us know when the stack contents have changed.  Since we know that impacts the value returned from CanAdd, we subscribe to that event and in the handler raise OnCanExecuteChanged for the appropriate commands, like this:

        void OnStackChanged(object sender, NotifyCollectionChangedEventArgs e)

        {

            _addCommand.RaiseCanExecuteChanged();

            _subtractCommand.RaiseCanExecuteChanged();

            _divideCommand.RaiseCanExecuteChanged();

            _multiplyCommand.RaiseCanExecuteChanged();

            _popCommand.RaiseCanExecuteChanged();

        }

Then we need to update the XAML to bind to the command, which is straightforward and works like this:

            <Button

                x:Name="_AddButton"

                Grid.Column="0"

                Grid.Row="1"

                Style="{StaticResource ButtonStyle}"

                Content="+"

                Command="{Binding AddCommand}"

                />

The event handler for Clicked event was removed, and we bind to the AddCommand from the View Model.  You’ll also notice that I added a _ in front of the name of the control.  I did this to ensure I caught all references to the control in the View, since the name change will cause a compiler break. 

In the view code we remove the event handler and all references to the button – ensuring as we got that we captured all the right functionality in the ViewModel for that button.

As you look at the code you’ll notice that Add, Subtract, Divide, Multiply and Pop commands are all very similar.  But AddDigitCommand is a bit different.

AddDigitCommand

Now for buttons 0-9 we could create 10 commands – one per button.  That would work, but would be a bit monotonous to code, as well as just require a bunch of code (although it would be simple code).

Instead we can take advantage of the parameter which ICommand’s Execute & CanExecute methods.  That means we can have a single ICommand which supports all 10 buttons (0-9) and eventually will even support A-F (we’ll first need to move the Hex/Decimal support into the ViewModel, which will happen in a future article).

The implementation of that command looks like this:

        privatevoid OnAddDigitExecuted(object parameter)

        {

            var stringParameter = (string)parameter;

            var newText = this.EnterText + stringParameter;

            this.EnterText = newText;

        }

        privatebool OnAddDigitCanExecute(object parameter)

        {

            var stringParameter = (string)parameter;

            switch(stringParameter)

            {

                case"0":

                case"1":

                case"2":

                case"3":

                case"4":

                case"5":

                case"6":

                case"7":

                case"8":

                case"9":

                    returntrue;

                default:

                    returnfalse;

            }

        }

As you can see the parameter is the character to add to the EnterText.  Right now CanExecute just verifies it is an expected value between 0 and 9.  This method will get more interesting when Hex support is added.

You’ll also notice that I’ve added another property, EnterText, which contains the string the user is composing to add a number to the stack.  This is required because the AddDigitCommand needs to modify it. 

        publicstring EnterText

        {

            get

            {

                return _enterText;

            }

            set

            {

                if (_enterText != value)

                {

                    _enterText = value;

                    _backspaceCommand.RaiseCanExecuteChanged();

                    RaisePropertyChanged("EnterText");

                }

            }

        }

The property is pretty simple.  You’ll notice the setter raises the PropertyChanged event and also tells the backspace command to re-evaluate if it can execute – this is because the BackspaceCommand being able to execute depends on the length of EnterText.

Because this is just one step in a multi-step refactoring we do need some temporary code to keep everything working.  Because we can’t fully move dealing with that text to the view model until the Hex support is done.  So you’ll notice in the View there is now code which updates EnterText on the ViewModel when the TextBox’s text is changed.  There is also code that does the reverse and updates the TextBox when EnterText changes.

Just like the other commands we need to update the XAML and remove code from the View.  The only real difference is we also set the CommandParameter property to define what should be passed into the Command’s methods.

            <Button

                x:Name="_FourButton"

                Grid.Column="2"

                Grid.Row="2"

                Style="{StaticResource ButtonStyle}"

                Content="4"

                Command="{Binding AddDigitCommand}"

                CommandParameter="4"

                />

Wrapping It Up

Lets review what we’ve done:

·        Created a ViewModel and made it available to the XAML markup

·        Created DelegateCommand to expose ICommand objects from the ViewModel

·        Exposed commands from the ViewModel for most of the buttons

·        Migrated the XAML to use the commands

·        Removed code from the View

·        Added some temporary code in the View for EnterText to keep things working until the next step.

Hopefully you can see that the net effect is logic that was previous in the View and coupled with the XAML markup is now in the reusable ViewModel and is completely decoupled from the markup.

One thing that might have escaped notice is that there are a variety of controls which accept an ICommand, beyond the simple button.  For example the HyperlinkButton takes an ICommand, so we could change the markup to use hyperlinks instead of traditional buttons.  Which gives us a glimpse of the flexibility a good ViewModel can give us when it comes to defining different markup over the same logic.

Complete code attached.

MyCalc - part 2.zip

There is an increasing trend for Microsoft platforms to build what is called a “Universal App”.  In its ideal it is an application that you code once, and then it runs on desktop, tablet and phone platforms. 

This opportunity introduces new challenges – with a main one being that the different platforms have differences.  Differences in APIs, differences in capabilities and differences in display size and orientation.

All of these threaten the ideal of reusing most, if not all, of the code between the platforms.  The less code you can share between the platforms, means:

·        A higher cost for development – meaning either more resources needed, or more time required

·        More code that needs to be maintained

·        Higher probability of bugs, especially that impact one platform but another

The Model-View-ViewModel pattern has the potential to increase code reuse across the platforms.  This can be done by minimizing logic in the View and designing a View Model that is agnostic of the details of the View.  This will allow us to develop a different View for the different platforms, while sharing the code in the ViewModel and Model. 

To illustrate this I’ve created a Windows Store application, called My Calc, which is purposeful coded in a naive View centric way.  As is if one were to make the application available phone would be a large incremental cost.

MyCalc is a simple stack calculator application.  One can push numbers on the stack.  Operations, such as Add, take their operands from the stack and replace it with the resulting value.  Purposefully the set of operations implemented as basic, as the object is to focus on ViewModel development, and not develop a fully featured calculator app.

In the various parts of this blog we’ll first refactor the application to have a ViewModel, and end with porting the application to phone by coding up a phone specific View.

Attached is our starting solution.  It consists of 3 projects:

·        MyCalc.Shared

o   Contains code shared across the platforms

·        MyCalc.Windows

o   Contains code specific to Windows

·        MyCalc.WindowsPhone

o   Contains code specific to phone

The shared project contains a StackCalculator class.  This is our Model, or business logic.  It doesn’t know anything about the UI.

You can ignore the WindowsPhone project for now, as all it has in it is the broiler plate code the Visual Studio put in when the project was created.

The Windows project has the MainWindow.  If you’ve done UI development in XAML, WPF or Silverlight then likely you’ve seen (and written) code similar to this.

Here is a snippet of the xaml

            <Button

                x:Name="SixButton"

                Grid.Column="4"

                Grid.Row="2"

                Style="{StaticResource ButtonStyle}"

                Content="6"

                Click="SixButton_Click"

            />

            <Button

                x:Name="ThreeeButton"

                Grid.Column="4"

                Grid.Row="3"

                Style="{StaticResource ButtonStyle}"

                Content="3"

                Click="ThreeeButton_Click"

            />

        </Grid>

        <Grid

            x:Name="StackGrid"

            Grid.Column="1"

            Grid.Row="1"

            >

            <Grid.ColumnDefinitions>

                <ColumnDefinition Width="Auto" />

                <ColumnDefinition Width="Auto" />

            </Grid.ColumnDefinitions>

            <Grid.RowDefinitions>

                <RowDefinition Height="*" />

                <RowDefinition Height="Auto" />

            </Grid.RowDefinitions>

            <ListBox

                x:Name="StackBox"

                Grid.Column="0"

                Grid.ColumnSpan="2"

                Grid.Row="0"

                Margin="4"

                FontSize="32"

                ItemContainerStyle="{StaticResource ListBoxItemStyle}"

                />

            <TextBox

                x:Name="EnterBox"

                Grid.Column="0"

                Grid.Row="1"

                Margin="4"

                Width="400"

                FontSize="32"

                TextChanged="EnterBox_TextChanged"

                />

There are a few things I’d like to point out about this code:

·        The elements (buttons, ListBox, TextBox, etc…) have names so we can reference them in the code behind

·        Events are wired up to methods in the code behind, such as the Clicked and TextChanged events.

These are indicators that this UI was coded up in a traditional way without a ViewModel (or at least not a well designed one).  When we look at the code we get that confirmed with code like this:

        privatevoid EnterBox_TextChanged(object sender, TextChangedEventArgs e)

        {

            UpdateEnterBoxButtons();

        }

        privatevoid UpdateEnterBoxButtons()

        {

            if (EnterBox.Text.Length == 0)

            {

                EnterButton.IsEnabled = false;

                BackspaceButton.IsEnabled = false;

            }

            else

            {

                EnterButton.IsEnabled = true;

                BackspaceButton.IsEnabled = true;

            }

        }

Here we see that the logic in the View is very tightly coupled with the XAML markup, since the View not only responds to events from the controls, but directly updates the state of various controls.

While one could theoretically compile this code against 2 sets of markup (and there are some challenges to just making that happen) we are quite limited in the changes that could be made – other than just layout and style changes.  For example the View code expects both an Enter and Backspace button – but what if, due to space constraints, on phone we would rather just use the ones on the soft keyboard rather than have such buttons in our main UI.

MyCalc - part 1.zip

The most common form of misuse is using the UI thread for a long period of time.  In severe cases this causes the application to hang and for Windows to detect it is not responsive.  In minor cases this can interfere with animations or missing transitional visual updates.

Unfortunately most UI technologies make it really easy to make a mistake.  UI programs are very event driven.  And these technologies call back into the application on the UI thread to handle these events, which naturally causes people to write code to handle those events on the UI thread, unless they do additional work to move the logic to a background thread.

Components like ThreadPool and BackgroundWorker can help with this task, but it is still easy to make a mistake and occasionally block the UI thread.

Operations that are always slow are easy for developers and testers to detect during development so it can be fixed.  But real applications don't always run at the same speed - network connections, responsiveness of remote computers, and local thread timing can all make UI thread violation issues hard to reproduce or even detect in the first place - especially if the symptom is a subtle paint issue.

This makes detecting the issues almost random which can cause a steady stream of bugs coming in.  Worse it is hard to get confidence that the state of the application is improving.

Wouldn't it be nice if there was a way to detect these issues deterministically?  That would help one identifying all existing issues and help prevent new issues from being added.

The answer is something I call the UI Thread Watchdog.  Its responsibility is to detect misuse of the UI thread and complain.  It has 2 approaches to achieve that.

The first way is to provide methods which components can call to validate if they are being executed on the UI thread or not.  These methods are easy to implement.  They just need to compare the current Thread with the Thread being used for the UI.  The Dispatcher object has this information.

Using these methods is also easy, just call the watchdog right method from your code.  Now one could do a brute force approach and call the watchdog from just about everywhere.  But one often gets more "bang for the buck" if one picks strategic locations to "instrument".  Key places are the ones which may take a while, such as:

• Code which interacts with networking
• Code which interacts with other processes
• Code which interacts with the file system
• Code which acquires locks
• Code which makes blocking calls, like waiting on handles
• Code which interacts with the hardware

The second way the UI Thread Watchdog works is that is occasionally polls the UI thread to see if it is responsive.  Implementing this isn't as easy, but isn't hard. 

On a background thread one occasionally does an Invoke to the UI thread.  Then checks to see if the invoked method gets called within a certain amount of time.  If it doesn't execute then something time consuming is using the UI thread, preventing processing of other messages.

The hard part of this is deciding how often to poll and how long to wait before declaring the UI thread as blocked.  The balance is to make the times small enough to detect issues, but long enough to avoid false positives.  I suggest starting with small values and then increment the values up if you hit a large number of false positives.

This isn't deterministic like the validation methods, but can improve detection of these issues significantly - and works on code not "instrumented."

Attached is code which implements a simple thread watchdog using these techniques to demonstrate the ideas.

Some ways this can be improved are:

• Freeze the UI thread on a not responsive validation so the culprit will be on the stack when the issue is debugged
• Disable the checks on the shipping build so users don't see the issue
• Log the violations to the application's log

WatchDoggie.zip

I don’t know exactly why this is, but I assume it has something to do with all the tricks MMC does to give each managed snapin its own UI thread, and needing to marshal a request back to the main UI thread owned by the console.

There are 3 APIs you need to know about when launching a child window (modal or modeless) inside a managed snapin.

1)      If you want a child window of the console then use Console.Show/ShowDialog

2)      If you want a child window of a property sheet then use PropertySheet.Show/ShowDialog

3)      If you want a child window of a winforms window (previously launched w/ Console/PropertySheet APIs) then use Form.Show/ShowDialog

The same rules apply for simple MessageBoxes.  The APIs to use are Console.ShowDialog(MessageBoxPrameters), PropertySheet.ShowDialog(MessageBoxParameters) and MessageBox.Show().  Follow the same rules as above.

In one project I worked on we had some common code which needed to launch dialogs & show messages – but that code could be called from anywhere and so it didn’t know what API to call.  What we did was make an interface called INotifyUser which had Show/ShowMessageBox/ShowDialog methods.  Then we had 3 concrete implementations, one for each case – ConsoleNotifyUser, PropertyPageNotifyUser and WinformsNotifyUser.  The caller of the common code would pass in the correct implementation, allowing these API differences to be abstracted away from the common code.

As time went on this interface changed into an abstract class, NotifyUser.  This class had abstract methods for Show/ShowMessageBox/ShowDialog, for the concrete sub-classes.  It also added higher level methods like ShowYesNoDialog, ShowConfirmDialog, etc… which internally called ShowMessageBox with the right parameters. 

This approach turned out very well.  Everything dealing with the details of child windows was encapsulated in one place, which provided a nice consistent API. 

Late in the project we had a spec change to use the Task Dialog in Windows for things like the YesNo and Confirm dialogs.  After implementing a TaskDialog class which P/Invoked the APIs, we were able to wire it into the NotifyUser.ShowYesNoDialog/ShowConfirmDialog/etc implementations – and update all our dialogs without having to hunt down all the code which dealt with these dialogs. 

After that it was straight forward to update the methods, and callers, to take advantage of the additional functionality of the Task Dialog (extra text sections, icons, etc…).

I thought it actually worked out rather nice, and is a great example of the sort of power you get when you encapsulate logical functionality behind an interface.  And those unit testers out there will appreciate how this helped make the logic more testable by allowing test code to use its own test double implementation of NotifyUser.

Enjoy

Overview

Some WPF controls, such as Buttons, are command sources.  A command source has 3 properties, Command, CommandParameter and CommandTarget.  When the control does it’s action (like Click for Button)it Executes the command, using the CommandParameter and CommandTarget as inputs.

WPF has provided an interface called ICommandSource to encapsulate this concept.  (Although there seems to be nothing significant which consumes the interface – just classes which implement it.)

Most (all?) command sources implementations care about the CanExecute state, and usually disable themselves if CanExecute is false.  The implementations listen to the CanExecuteChanged event for the command, and when it is raised query the new CanExecute status.

And that is where the issue begins – the implementations don’t unsubscribe from the event (except when the Command property changes).  So if the command object has a lifetime longer than any control(s) which list to it’s CanExecuteChanged event it will cause a memory leak of the control.  This is because when you register a handler for an event the delegate isn’t just a function pointer, but also include a reference to your instance.

The RoutedCommand Winkle

At this point you are probably saying to yourself “The logic seems sound, but I use commands and my app doesn’t appear to leak”.

The answer is because most apps use RoutedCommand, rather than their own implementation of ICommand.  The RoutedCommand.CanExecuteChanged implementation is to be a proxy for CommandManager.RequerySuggested, which if you read the docs or look at the IL keeps a weak reference to the delegate.  That allows the delegate to be GCed, and along with it the strong reference to the command source which subscribed to the event.

So to hit this you need to have a custom ICommand implementation which implements the CanExecute event the way most .NET events are implementd.

Why I Think WPF’s CanExecuteChanged Implementation Is Wrong

No doubt someone on the WPF team thought they were being rather smart –after since most RoutedCommands are declared as static fields their lifetime is roughly the application’s lifetime.  But I don’t think they were clever enough – because they redefined the standard contract for a .NET event.

Now anyone subscribing with RoutedCommand.CanExecuteChanged needs to be aware of this non-standard behavior – since if they don’t hold a strong reference to their delegate then it will be GCed and at some point the event seems to stop working.  (A really fun problem to debug BTW)

Since they also have this nice ICommand interface which RoutedCommand is one implementation it also means that if you implement an ICommand you have to be aware of this behavior and also implement your event in a similar way holding weak references to the delegate, because the built-in consumers of the event (Button, etc…) rely on this behavior.

Furthermore since RoutedCommand.CanExecuteChanged event is really CommandManager.RequerySuggested each RoutedCommand instance shares the same event.  This means when the event is raised the sender field is null.  Another inconsistency from regular .NET event behavior.

To me this is a big mess, and unfortunately one we probably will have to live with for the whole lifetime of WPF.  Why I consider it a mess is not the technical specifics of the solution, but because they redefined the standard .NET event contract.

While we could argue that the .NET event contract has flaws, the fact of the matter is it is now a standard.  And this means that both producers and consumers of that contact know how to correctly implement their end. 

What RoutedCommand.CanExecuteChanged has done is made a different contract where it holds weak references to the delegate.  This means that producers and consumers need to be coded differently that a standard .NET event.  That is the issue from my point of view.

If the WPF team has decided to do their own custom Observer pattern implementation that didn’t overload “event” I would be happy, since it would clearly be a different contract.  By this I mean imagine if on ICommand instead of defining the CanExecuteChanged event they did something like this:

    interface ICommand

    {

        void RegisterCanExecuteListener(EventHandler listener);

        void UnregisterCanExecuteListener(EventHandler listener);

        bool CanExecute(object parameter);

        void Execute(object parameter);

    }

Then they could clearly document the contract for the CanExecuteListener and no one would get confused with .NET event semantics.

How To Properly Implement A Command Source

Now that I’m done with my rant I’ll give you some advice on how to deal with this.  Specifically in how to correctly implement your own command source implementation which will not leak regardless of the implementation of ICommand.

The short answer is to use WeakEventManager.

Unfortunately we need the long answer because since RoutedCommand.CanExecuteChanged doesn’t follow the standard contract it doesn’t work with WeakEventManager.  Specifically because:

·         WeakEventManager doesn’t hold a strong reference to the delegate, so it will be GCed

·         Since the sender parameter is null, WeakEventManager can’t which listener to deliver the event to

Notice the impact of not following the standard pattern means you can't use components designed to work with the standard pattern. 

The key is in the WeakEventManager implementation to use a proxy class for the ICommand implementation.  This proxy class does 2 things:

·         Holds a strong reference to the delegate registered with ICommand.CanExecuteChanged

·         Since there is a 1:1 relationship between the proxy and the ICommand, and the handler delegate has a reference to the proxy we can get the reference to the associated ICommand

The complete implementation of a WeakEventManager which works with all ICommand implementations is in the attached file.  The class is called CommandCanExecuteChangedWeakEventManager.

Then all the command source implementation needs to do is to use that and all will be well.

The Attached Project

If you build and run the attached project you will see a couple of buttons.  One demonstrates the memory leak using Button. Simply open task manager, click the button and watch memory usage go up.  Click the GC button to ensure yourself that the objects really have a strong reference back to them.

The other parts of the UI are to demonstrate that CommandCanExecuteChangedWeakEventManager really works, both to deliver events and to avoid the memory leak.

Use at your own risk and other standard disclaimers apply.

Enjoy

CommandWeakEventManager.zip

However this isn’t perfect.  We have 3 major complaints with this setup:

·         The tedium of implementing a new WeakEventManager

·         Implementing the IWeakEventListener interface

·         The scalability of WeakEventManager

Implementing a WeakEventManager

Implementing a WeakEventManager isn’t hard.  In fact it is fairly mechanical.  But that doesn’t make it good – especially if you need to implement a dozen of them.  Personally I hate implementing this sort of code because:

1.       It is boring

2.       It is more places where bugs can be introduced

Currently my team copy-and-pastes an existing WeakEventManager and then modifies it.

I’ve thought about how to simplify this by using generics or helper classes or something.  Unfortunately none of those ideas have significantly reduced the work enough to justify implementing it.

So I’ve come to the conclusion that code generation is the answer.  In order to handle 90+% of the cases all one needs for the metadata is:

·         The event source type

·         The event name

·         The event args type

I hope to explore this in the future and blog about it.  As an aside I’d love to see Visual Studio come with this kind of built in support.  Imagine being able to right click on an event declaration and select “Generate Weak Event Manager” from a menu and have it generate the code and add it to your project?

Implementing the IWeakEventListener

I believe encapsulation is a good thing, especially for implementation details.  Whether a given class uses a WeakEventManager to subscribe to events listens to is an implementation detail.  Users of that class shouldn’t care, just so long as the implementation meets the contact and is well behaved (i.e. doesn’t cause memory leaks).

Unfortunately the pattern for using WeakEventManager is to implement IWeakEventListener on the class which needs to do the listening.  Look at CollectionViewSource, CompositeCollection and BindingExpressionBase.  Due to this choice we know something about their implementation.  That doesn’t seem very encapsulated to me.  What happens if the class no longer needs to use a WeakEventManager?  What happens if I directly call the RecieveWeakEvent method – which is public on those classes?

And don’t get me started on what the implementation of RevieveWeakEvent needs to look like if you subscribe to more than 1 event.

Thankfully we don’t have to rely on this pattern.  We can implement a small class which implements IWeakEventListener.  This class can either raise its own event, or call a delegate or whatever.  We can then contain an instance of this class in whatever class needs to do the listening.

But we don’t want to implement tons of these little listener classes.  So generics to the rescue.  Using generics are can implement a single listener class that works for all types of events.

And here it is:

   /// <summary>

    /// A common weak event listener which can be used for different kinds of events.

    /// </summary>

    /// <typeparam name="TEventArgs">The EventArgs type for the event.</typeparam>

    class WeakEventListener<TEventArgs> : IWeakEventListener where TEventArgs : EventArgs

    {

        EventHandler<TEventArgs> realHander;

        /// <summary>

        /// Initializes a new instance of the WeakEventListener class.

        /// </summary>

        /// <param name="handler">The handler for the event.</param>

        public WeakEventListener(EventHandler<TEventArgs> handler)

        {

            if (handler == null)

            {

                throw new ArgumentNullException("handler");

            }

            this.realHander = handler;

        }

        /// <summary>

        /// Receives events from the centralized event manager.

        /// </summary>

        /// <param name="managerType">The type of the WeakEventManager calling this method.</param>

        /// <param name="sender">Object that originated the event.</param>

        /// <param name="e">Event data.</param>

        /// <returns>

        /// true if the listener handled the event. It is considered an error by the WeakEventManager handling in WPF to register a listener for an event that the listener does not handle. Regardless, the method should return false if it receives an event that it does not recognize or handle.

        /// </returns>

        bool IWeakEventListener.ReceiveWeakEvent(Type managerType, Object sender, EventArgs e)

        {

            TEventArgs realArgs = (TEventArgs)e;

            this.realHander(sender, realArgs);

            return true;

        }

    }

It is easy to use.  For each event you want to listen to you:

1.       Add a field of type WeakEventListener<T> to your class

2.       Construct the WeakEventListener instance with a line like:

this.collectionChangedListener = new WeakEventListener<NotifyCollectionChangedEventArgs>(this.HandleCollectionChanged);

3.       Register the WeakEventListener with a line like:

CollectionChangedEventManager.AddListener(this.sourceCollection, this.collectionChangedListener);

4.       And of course implement your handler (HandleCollectionChanged in this example)

We now have a way to use a WeakEventManager in an encapsulated way (and have separate handlers without having to write a switch statement). 

Scalability of WeakEventManager

One unfortunate thing we discovered is that as you get thousands of weak event listeners registering/unregistering for events the internal maintenance (called “purge” inside the WeakEventManager code) gets slow.  I mean really slow – like the user thinks your app has hung slow. 

BTW if you wonder why this is happening on the UI thread  it is because WeakEventManager is a subclass of DispatcherObject and therefore has a thread affinity.  No doubt the creators thought they were being clever in avoiding synchronization issues.

Currently there is no fix for this other than reverse engineering WeakEventManager and coding a new one with a more performant purge (or at least enable purge to happen on a background thread in a non-blocking way).

So how does this work?  Well the simplistic model is that DependencyObject defines a dictionary to hold property values.  The key in the dictionary is the DependencyProperty instance and the value is the current value for that property.   Adding an attached property simply adds a new entry into the dictionary for a given object.

To define an attached property one typically writes code that looks like this:

public static readonly DependencyProperty IsTextTrimmedMonitoringEnabledProperty =

DependencyProperty.RegisterAttached(

"IsTextTrimmedMonitoringEnabled",

typeof(bool),

typeof(TextBlockService),

new PropertyMetadata( false, IsTextTrimmedMonitoringEnabledProperty_PropertyChanged) );

static public bool GetIsTextTrimmedMonitoringEnabled(DependencyObject element)

{

return (bool) element.GetValue(IsTextTrimmedMonitoringEnabledProperty);

}

static public void SetIsTextTrimmedMonitoringEnabled(DependencyObject element, bool value)

{

element.SetValue(IsTextTrimmedMonitoringEnabledProperty, value);

}

static private void IsTextTrimmedMonitoringEnabledProperty_PropertyChanged(DependencyObject o, DependencyPropertyChangedEventArgs e)

{

// handle the property being changed for "o"

}

The DependencyProperty field holds the DP instance, which as we discussed is essentially the key to the value.

The Get/Set methods are a best practice to encapsulate the details of how to get/set the value.  Like any dependency property there are scenarios where the value can be changed/retrieved directly from the dictionary – so don’t put any logic in there, beyond calling GetValue/SetValue.

Attached properties are common used to implement something called Attached Services (or Attached Behavior), which is logic which you want to associate with a given object.  The PropertyChanged method is the entry point to get that logic executing.  John Gossman has a good example for an attached service.

When writing an attached service often you’ll find that you need to keep some additional state for each object.  One way to do that is to define a ReadOnlyAttachedService.  When doing this if the read only attached property should be read outside the class implementing the property (say to be used in XAML to drive a trigger) then the DependencyProperty field and Get method are public, but the Set method is private.  If the value contains state which is internal to the workings of the attached service, then make everything private. 

If you find your state extends beyond a few simple fields then you might find it handy to define a single read only attached property which holds a value which is an instance of a data class you defined to hold all your state.