One-bytes #2: Selection in WPF, OnPropertyChanged parameters

*** #2.1 Item selection in WPF selector-enabled items control***
In WPF we can use multiple types of controls to display collections of items which allow user to select one or multiple items from the collection. In this post I’m going to discuss what single selection possibilities they offer.
Let’s start with inheritance hierarchy – controls that allow such selection inherit from System.Windows.Controls.Primitives.Selector. If we take a look at what properties they have we find four that may be involved in selection process:

  •  SelectedIndex – Gets or sets the index of the first item in the current selection or returns negative one (-1) if the selection is empty.
  • SelectedItem – Gets or sets the first item in the current selection or returns null if the selection is empty
  • SelectedValue – Gets or sets the value of the SelectedItem, obtained by using SelectedValuePath.
  • SelectedValuePath – Gets or sets the path that is used to get the SelectedValue from the SelectedItem.
    source: msdn.microsoft.com

So, there are three ways get the selected item: i) its integer index in the collection, ii) the item itself, iii) one desired value from the item. 
I have prepared a quick demo to show that. The app displays a ListBox of custom class objects and once an item is selected displays all three ways to present the selection. Let’s take a look into the code, starting with the class of objects that our list will contain:

The list will be generated and stored in view model. The view model will also have three public properties: i) ItemSelectedIndex of type integer bound to SelectedIndex property of  our ListBox, ii) ItemSelectedItem of type Item bound to SelectedItem, iii) ItemSelectedValue of type string bound to SelectedValue. Let’s take a look at complete ViewModel class:

And now the most important part – the view. As mentioned above as a container for collection we will use ListBox and bound properties as it was described when discussing the view model class. The only thing that’s left is setting correct value to SelectedValuePath property. In this case we want to use Name property of our item class so we need to set SelectedValuePath to “Name”. Here’s how to set the ListBox up:

Now, to use the selected index, item or value which are bound to corresponding properties in view model we need to add some controls and again bound them to view model properties:

And that’s it. To sum things up – there are three ways to access selected item in a selector control in WPF: by its index, by the item itself or by one particular value in the item.

*** #2.2 Passing property name to OnPropertyChanged()***
Second thing I want to mention today is a hint how to make invoking OnPropertyChanged() method in a property setter a bit more controlled when not using any MVVM framework.
ViewModels usually implement INotifyPropertyChanged interface which purpose is to notify views when a property has been updated. This is done by invoking OnPropertyChanged method with property name passed as a parameter.

That is not the best way. What if we decide to change the property name and the backing field can also be changed somewhere else? In this case we need to go and manually change the hard-coded property name. So what can be done instead is this:

Having passed the parameter this way we can simply go to the property, right click and rename it using Visual Studio renaming tool which will update all calls to this property. Definitely better!

Design Patterns #10: State

Design patterns episode 10 – State

Happy Christmas!! Isn’t it a good time to write a post?
Let me start with an apology. In previous post about patterns (composite) I promised to keep that one week/one pattern schedule but as you can see I have failed. But in the meantime I posted something different (one-bytes #1) so I feel forgiven to some extent. Learnt by experience I promise nothing this time. With that being said we can proceed to the next pattern.

Today’s hero is the State. We all know those simple machines which operation model is frequently very simple but closed within exact patterns. For instance the example given in Head First book – a vending machine. It allows only two or three possible interactions (insert coin, get coin back or get the product) and serves one particular purpose (sell products). Its operation model is base on states: the machine can have a coin inserted, can be out of products, etc. So the machine changes its internal state and this change implicates change of behaviour.

DEFINITION
Let’s take a look at the definition and the diagram.

The State Pattern allows an object to alter its behavior when its internal state changes. The object will appear to change its class.
(Freeman, Eric, et al. Head First Design Patterns. O’Reilly Media, Inc. 2004) 

In object-oriented programming the above definition is realised by representing these internal states by different implementations of one interface (or inherited from an abstract class). The important thing is the fact the state changes internally. It is not possible to set state from outside. If we go back and think about strategy pattern we will probably see that these two pattern are similar but that closure to changes from outside is what makes them different.


This the diagram depicting the state pattern and similarly to strategy pattern we have encapsulation of behaviour in a separate class: behaviour of Operation() method in context class is encapsulated in state object. It is possible to have multiple states but transitions between them must be done privately. User of state context must not be able to enforce the context to switch state in any other means than normal operation on the context, intended by designer. We don’t have any public method to set the current state from outside. And that is the key to state pattern.

EXAMPLE
I have used a prepaid electricity meter to show the pattern. It can be thought of as a state machine: it can be switch off, switched on but idle, conducting electricity to appliances or be out of credits. Let’s start with the meter interface:

It exposes two properties: one is the credit that the meter is topped-up with, the other is current state of the meter. Both of them are get-only: there is specific method to top-up and the state cannot be set from the outside. Other than that we have methods to turn the meter on/off, start delivering power (for specified number of cycles)  and already mentioned TopUp() method.

The implementation of the meter is slightly more complicated. First we need to equip properties from the interface with setters. Next we need properties for each of the possible states. In this case there are three states: OnStateOffState and MinusState. Other than that we have methods to manipulate with credit and a constructor. This is important: we initialise state instances, set credit to zero and set current state to OffState. The last step is four methods from the IMeter interface. These methods don’t have their own implementation but they call current state object to execute its corresponding operations.
Now the abstraction of state class. In this case I’m using abstract class because I need some not public members, force the inheriting classes to set reference in constructor to the meter the state is going to be used with, and reuse some common pieces of code.

As you can see states will have all the methods that the meter will call in different states. The TopUp() methods has default implementation because it will the same for OnState and MinusState, method ReachZero will be called whenever the meter runs out of credit. It doesn’t need to be virtual because no override will ever be needed.
The last pieces of code would be actual implementations of the sates. Let’s take a look at just one:

As you can see each state provide its own implementation of actions possible for the meter (except for TopUp() which as stated earlier can be shared and in this case it is, but it isn’t in OffState where it is overridden to simply write out on console that the meter is off). Note that some of them changes the state – that’s the core of this pattern: the internal change of state.
Having all the states implemented we can see how it works:

The above would generate output like this:
As you can see we invoked Start() method on one and the same object and we got three different results which all depended on the state in which the object had been, and some of which changed the state of the object. That’s the way how the state pattern works.

Before I prepared this example I had prepared another: a model of vending machine. It is a WPF app. The reason I decided to go for something different was the fact that it had become a bit unclear in the code. Simple console app is much better to illustrate the  pattern. However I did not abandoned the code and you can take a look at this as well. Here’s quick video how it works and the source code you will find at the bottom of this post.

So that’s it for today. Hope you like it 🙂 Before you go please find some useful links below. Enjoy!

Source code – IMeter: TXT file
Source code – Vending machine: GitHub

One-bytes #1: Menu item commands, boxing vs. ToString()

Hello there!
With this post I’m starting new category: one-bytes. These posts will be compiled of two or three shorter forms abut things that don’t qualify for so to say full-size post. Name of the category refers to snack meals, so called one-bite foods: one bite => one byte. Quick to prepare, good to get your taste-buds tingling.  Enjoy!

*** #1.1 Binding a command to MenuItem in ContextMenu ***
It happend one time that I had been struggling with binding a command to a MenuItem in ContextMenu. The code was more or less like this:

It turned out that since ContextMenu is not present in WPF visual tree it was not possible to bind the command as it’s usually done. The solution was to use BindingProxy class that inherits from Freezable.

Having this class we can create its instance as a resource (in my case it was an user control) and set the Data property to {Binding}:

This will bound the Data property to whatever is set as DataContext in the user control itself. Now, through the BindingProxy instance we can access that DataContext outside the visual tree:

This solution was proposed by Thomas Levesque.
Sources:
Blog post by Thomas Levesque
Question on StackOverflow

*** #1.2 String.Format() vs. boxing ***
There is a thing using String.Format() method with value types (such as integers). That thing is the fact that this method takes objects as args and if a value type given as parameter it will be boxed. Boxing is a process when a value type is converted to an object. That involves moving the value from stack to heap and replacing it on a stack with a reference to heap address where the actual value is stored. (More on boxing/unboxing can be found here: [link]).
So, what can be done to avoid that – simply pass arguments with ToString() method invoked. This will save a bit on performance – that’s the theory. So I tested it. I take an array of one million integers and another array with the same amount of doubles and pass them into String.Format() method. And the theory is confirmed – avoiding boxing by invoking ToString() method makes it faster.

To make the results reliable I arranged everything as unit tests run one after another (not parallel) and the actual tests were preceded by a test that did nothing – that is to make sure that the filling arrays in test class constructor does not distort actual test running time. So the results are that the process without boxing is faster by 3,7% for doubles and 4,9% for integers. Please, keep in mind that the test sample was one million values.
Does it mean that it’s no point in invoking ToString()? My opinion is that in this case boxing operation is redundant and not necessary so it should be avoided.

Design Patterns #9: Composite

Design patterns episode 9 – Composite

With unexpected delay but patterns are back! In this episode – composite.

The composite is generally used to model tree-like structures in a way that classes that are using the composite can handle its elements in one particular way without having to distinguish whether an element has children – a composite, or hasn’t – a leaf (in other words, whether we can go further down the tree or element is a dead-end).

The first thing that comes up when thinking about that kind of structure would be a directory tree where folders are composites and files are leafs. Or any other structure alike: corporate structure (managers and subordinates), online shops (categories and concrete items) and many many more.

DEFINITION
Let’s see how the Head First book defines this pattern:

The Composite Pattern allows you to compose objects into tree structures to represent part-whole hierarchies. Composite lets client treat individual objects and composition of objects uniformly.
(Freeman, Eric, et al. Head First Design Patterns. O’Reilly Media, Inc. 2004) 

So, in other words we have tree structure of objects and collection of objects and the client doesn’t need to care about if it’s a leaf or a composite. This is the key feature of this pattern. For instance, let’s think about file system where we have files and directories. Both of them are elements of file system and should be treated the same: the client can perform the same operations on both – rename, delete, get size etc. But obviously we can do more things with directories (as this is a collection of files and directories), therefore composite pattern isn’t applicable here (of course you could use typecasting to make it work but that’s a different thing).
The diagram shows what discussed above – both concretions are treated the same, nothing different can client do with one or the other type. The diagram presented here is different than what’s in the book. The book adds further methods: add()remove(),  getChild(). But isn’t that inconsistent with the definition? How can you add a further child to a leaf? You could throw an exception but wouldn’t that violate the Interface Segregation Principle? That kind of issues have been greatly discussed here by the guy who I quoted on multiple occasions.
So, to conclude this aspect of the pattern – my opinion is that we should stick to ISP and not force any class to implement something that the class doesn’t use. Period. Let’s move on to code example.

EXAMPLE

In our code example we’re going to build a store’s menu. Let’s start with the abstraction:

Our IStoreElement consist of name property and a method to list self in the menu: there will be different implementations of this method for leaves and composites. This method can take optional argument as we want to nicely format the menu by indentation of sub-components.
Now the leaf class:

Leaf’s implementation of ListOut() method works that it returns a string with given number of dashes and its name.
And finally composite class:

This class is equipped with private list of objects that implement our base interface. This list can be set in constructor.
The ListOut() method starts with the same thing that counterparting method in leaves but before returning the value recursively invokes the same method for all IStoreElements that the composite holds in its private list. This invocation takes indent parameter increased by 1. This way we achieve that nice formatting of the list once requested in the topmost component.
Now, let’s see how it work all together:

We generate the list and then print to the console the string returned by ListOut().

To sum things up: he Composite Pattern is used to represent tree-like structures where all their elements can be treated uniformly, where single components are called leaves and collections of components are called composites. The pattern can be equipped with methods to modify the content but this lead to violation of Interface Segregation Principle.

Next week: the State Pattern. I hope that this time without any delay. Check the links and source code below. Thank you!

Composite pattern by Christopher Okhravi: link [YouTube]
Composite vs. Decorator by Christopher Okhravi: link [YouTube]
Composite pattern by Michael: link [YouTube]
Source code: TXT file