Tag Archives: C#

A generic version of ICollectionView used in a MVVM searchable list

In this post we will describe how to create a searchable list with WPF following MVVM principles. To this aim we will use a WPF ListView to display the searched items and a TextBox to enter the text used for the search. Most of the implementation that you will find on the web (e.g. this one) will recommend you to bind your ListView to an ICollectionView. However, this is not 100% satisfactory as long as ICollectionView does not have a built-in generic version. Consequently the ViewModel’s member exposing the binding items will return an ICollectionView which is a powerful object (see this for instance)  but is “only” an enumeration of System.Object. In this post we will show you that a generic version can be easily implemented and exposed by your ViewModel.

In this post we will create a very simple app that let you search a player in the list of all the players of the last Football World Cup in Brazil. The complete source code can be found on my Github here.

Searchable WPF ListView

Searching ‘dav’ in the ListView display a list of results starting with ex Chelsea’s player David Luis…

The key ingredients of such implementation is very simple in MVVM. First take the View which does not need more than the few lines of xaml below.

 <UserControl.DataContext>
 <Binding Path="PlayerSearchViewModel" Source="{StaticResource Locator}" />
</UserControl.DataContext>
<DockPanel>
 <TextBlock DockPanel.Dock="Top" Text="Search player"></TextBlock>
 <TextBox DockPanel.Dock="Top" Text="{Binding SearchPlayerText, UpdateSourceTrigger=PropertyChanged}"></TextBox>
<ListView ItemsSource="{Binding DisplayedPlayers}" SelectionMode="Single" ScrollViewer.VerticalScrollBarVisibility="Auto">
  <ListView.View>
   <GridView >
    <GridViewColumn DisplayMemberBinding="{Binding Name}" Header="Name" />
    <GridViewColumn DisplayMemberBinding="{Binding NationalTeam}" Header="National Team" />
    <GridViewColumn DisplayMemberBinding="{Binding Age}" Header="Age" />
    <GridViewColumn DisplayMemberBinding="{Binding Club}" Header="Club"/>
    <GridViewColumn DisplayMemberBinding="{Binding Championship}" Header="Championship"/>
   </GridView>
  </ListView.View>
 </ListView>
</DockPanel>

Let us start by exposing the non-generic version: the DataContext of the control above is bound to an instance of an implementation of the interface IPlayerSearchViewModel below.

public interface IPlayerSearchViewModel
{
   string SearchPlayerText { get; set; }

   ICollectionView DisplayedPlayers { get; }
}

A very straightforward implementation that works is the following one.

public class PlayerSearchViewModel : IPlayerSearchViewModel
{
    private readonly ICollectionView _view;
    private string _textsearch;

    public PlayerSearchViewModel(IPlayerProvider playerProvider)
    {
        _view = CollectionViewSource.GetDefaultView(playerProvider.GetAllWorldCupPlayer());
        _view.Filter += (object item) =>
        {
                    if (_textsearch == null) return true;
                    var itemPl = (IPlayer) item;
                    return itemPl.Name.Contains(_textsearch) ||
                               itemPl.NationalTeam.Contains(_textsearch) ||
                               itemPl.Club.Contains(_textsearch) ||
                               itemPl.Championship.Contains(_textsearch);
        };
    }

    public string SearchPlayerText
    {
        get { return _textsearch; }
        set
        {
            _textsearch = value;
            _view.Refresh();
        }
    }

    public ICollectionView DisplayedPlayers { get { return _view; } }
}

As I said in the introduction, this is quite enoying. You may want to create screens with many ICollectionView bindings that may contain different types, then it is becoming error prone and we are loosing the benefit of C#’s type safety. The unit test example below is showing you that the elements need to be casted while they are accessed from the ICollectionView.

[TestMethod]
public void TestingTheSearchingCapabilitiesWithBedoya()
{
    var viewModel = new PlayerSearchViewModel(new PlayerProvider());
    viewModel.SearchPlayerText = "Bedoya";
    var searchResult = viewModel.DisplayedPlayers.Cast<IPlayer>().ToArray(); //Cast objects extracted from the ICollectionView
    Assert.AreEqual(1, searchResult.Length);
    IPlayer bedoya = searchResult[0];
    Assert.AreEqual("Nantes",bedoya.Club);
}

In addition we cannot use anymore the XAML validation and intellisense provided by Resharper.

Resharper complaining because of the unknown's member of the DataContext (typed as object)

Resharper complaining because of the unknown’s member of the DataContext (typed as object)

Fortunately we can create our generic version of ICollectionView and get back to the comfortable world of type safety. In this example, I will only provide the generic enumeration and the generic version for the SourceCollection member but you can add others. Indeed, you may create a generic version of the Filter predicate to avoid dealing with System.Object in your lambdas but with your generic type T instead.

public interface ICollectionView<T> : IEnumerable<T>, ICollectionView
{
    IEnumerable<T> SourceCollectionGeneric { get; }
    //Add here your "generic methods" e.g.
    //e.g. Predicate<T> Filter {get;set;} etc.
}

Actually, the implementation of the ICollectionView is really easy as long as you already have the non-generic instance at hand ICollectionView

public class MyCollectionViewGeneric<T> : ICollectionView<T>
{
    private readonly ICollectionView _collectionView;

    public MyCollectionViewGeneric(ICollectionView generic)
    {
        _collectionView = generic;
    }

    private class MyEnumerator : IEnumerator<T>
    {
        private readonly IEnumerator _enumerator;
        public MyEnumerator(IEnumerator enumerator)
        {
            _enumerator = enumerator;
        }

        public void Dispose()
        {
        }

        public bool MoveNext()
        {
            return _enumerator.MoveNext();
        }

        public void Reset()
        {
            _enumerator.Reset();
        }

        public T Current { get { return (T) _enumerator.Current; } }

        object IEnumerator.Current
        {
            get { return Current; }
        }
    }

    public IEnumerator<T> GetEnumerator()
        {
            return new MyEnumerator(_collectionView.GetEnumerator());
        }

    IEnumerator IEnumerable.GetEnumerator()
    {
        return _collectionView.GetEnumerator();
    }

    public bool Contains(object item)
    {
     return _collectionView.Contains(item);
    }

    public void Refresh()
    {
        _collectionView.Refresh();
    }

       //Complete implementation can be found on github.co/bpatra/MVVMSample

    public event NotifyCollectionChangedEventHandler CollectionChanged
    {
        add
        {
            lock (objectLock)
            {
                _collectionView.CollectionChanged += value;
            }
        }
        remove
        {
            lock (objectLock)
            {
                _collectionView.CollectionChanged -= value;
            }
        }
    }

    public IEnumerable<T> SourceCollectionGeneric

        get { return _collectionView.Cast<T>(); }
    }
}

Therefore the implementation of the the ViewModel becomes cleaner and statically typed. First the new version of the ViewModel interface.

public interface IPlayerSearchViewModel
{
    string SearchPlayerText { get; set; }

    ICollectionView<IPlayer> DisplayedPlayers { get; }
}

Then, the implementation.

public class PlayerSearchViewModel : IPlayerSearchViewModel
{
    private readonly ICollectionView<IPlayer>; _view;
    private string _textsearch;

    public PlayerSearchViewModel(IPlayerProvider playerProvider)
    {
        _view = new MyCollectionViewGeneric<IPlayer>;(CollectionViewSource.GetDefaultView(playerProvider.GetAllWorldCupPlayer()));
        _view.Filter += (object item) =>;
        {
            if (_textsearch == null) return true;
            var itemPl = (IPlayer) item;
            return itemPl.Name.Contains(_textsearch) ||
                        itemPl.NationalTeam.Contains(_textsearch) ||
                        itemPl.Club.Contains(_textsearch) ||
                        itemPl.Championship.Contains(_textsearch);
        };
    }

    public string SearchPlayerText
    {
    get { return _textsearch; }
        set
        {
            _textsearch = value;
            _view.Refresh();
        }
    }

    public ICollectionView<IPlayer>; DisplayedPlayers { get { return _view; } }
}

You do not have to cast or worry anymore on the the type of the objects contained in you ICollectionView. You will also detect binding errors statically with Resharper.

resharperClever

Resharper handles typed generic collections in databinding

Executing PSake build script with Teamcity

For my build tasks I have been using MSBuild for a while. I found out that it is fine to use it for standard build tasks such as invoking msbuild.exe itself. However, when it comes to really custom actions it is really painful. I did not want to struggle any longer with xml config files and would like to stay as close as possible to a simple procedural programming language. Most of all I was fed up by the quoting issues when invoking external executables. When writing such actions I wanted to stick to a shell scripting language that I already know. Still, basic scripting can be a little bit improved when it comes to build process. To be precise, the notion of task (or target) is extremely handy because you can split a build step in sub tasks that you may combine differently depending on the build config. While it looks like overkill for a small project it will ease your life in large projects where packaging can be complex.

The tool that I will present in this post is called PSake (pronounce saké like the asian alcohol) and is described by the Wikipedia as

a domain-specific language and build automation tool written in PowerShell to create builds using a dependency pattern similar to Rake or MSBuild.

This was all I needed: a build tool in Powershell.

Even if I will not cover this in the present post, one of the main benefit of using Powershell for build scripts is the possibility to use directly Powershell extensions such as Azure or Sharepoint Cmdlets. Even if you do not need it right now, they may become extremely useful in the future of your Windows based software project.

In this post I will describe how to use PSake for a very simple build task: patching the AssemblyInfo.cs file for a visual studio .NET solution. I will also show you the organization of the targets that I have chosen.

Let us recall that the version of the .NET assembly produced by the compilation of your C# project uses the AssemblyInfo.cs file that you can find under the /Properties folder. The lines that are automatically generated in the AssemblyInfo.cs file regarding the assembly version are

[assembly: AssemblyVersion("1.0.0.0")]
[assembly: AssemblyFileVersion("1.0.0.0")]

Consequently, the task has to patch the AssemblyVersion so that it contains major.minor while the AssemblyFileVersion will be major.minor.build. Once the task will be finished all AssemblyInfo.cs in the code source repository will be patched similarly, for example with [assembly: AssemblyVersion("6.3")] and [assembly: AssemblyFileVersion("6.3.567")]. If you are not familiar with product versioning you may read the wikipedia page. Here we chose a major.minor.build sequence where the major and minor numbers are fully handled by the owner of the project. However, the .build number is provided by the continuous integration system which will be Teamcity in our case. Similarly to food industry where, given the number of a ready-made meal you are supposed to be able to track back where the beasts came from, in software, you should be able from the product version to track back the source of your product and its external dependencies. This is why both source code and build history are precious and why the Teamcity database should also be backed up.

The task presented here may not the best advocate for PSake over MSBuild XML configs because using the <FileUpdate> command performs the same kind of patch easily. In addition the MSbuildExtensionPack has a built in AssemblyInfo task for this purpose. But, if you are a .NET developer I am pretty sure you will be at ease, then think as an illustration for PSake.

Here is the source code for the task.

The outer braces: task PathAssemblyInfo defines the scope of the target. The command does not depend from where the script is run because we use the $PSScriptRoot variable (available since Powershell 3.0). It basically looks for all AssemblyInfo files in the solution directory and patch them with the appropriate version numbers. The detailed implementation of the functions GetAssemblyVersion, GetAssemblyFileVersion and PatchFile can be found here.

Now let us look on how to combine and invoke the PSake targets from Teamcity. I have a /build directory at the root of the repository which looks like

The organisation of build target with PSake

The organisation of build target with PSake

The PSake project is located under the /build folder. In the /targets directory we put all targets where one target equals one file with the same name. The bootstrapTargets.ps1 loads all build targets that are put in the subdirectory with the same name. In bootstrapTargets.ps1 I also put the high level targets, the one that will be called by the Continous Integration. Here, I have defined a high level target Example that executes first our PatchAssemblyInfo then another target that I have called RenameMSI (only for the example). You can also put in bootstrapTargets.ps1 some functions that will be reused by the different targets.

Now see how to invoke the PSake Example task within Teamcity. Create a Powershell using at least the 3.0 version.

Invoke the Example PSake task within TeamCity

Invoke the Example PSake task within TeamCity

The script in the Teamcity editor (and only this one) assumes the current directory is the repository root. The first line imports the module while second one invoke the Example task using PSake. The third line below is important so that exceptions thrown in the script appear as build failures.
if ($psake.build_success -eq $false) { exit 1 } else { exit 0 }

To conclude, I would say that PSake is good alternative to those who know Powershell and want to use less XML for their builds.

Unit Testing Drag and Drop logic with MVVM pattern in WPF

I recently had a discussion with a friend about the Model-View-ViewModel pattern (MVVM) for UI apps and the fact that it allows unit testing where you would not have thought it possible in the first place, for example, logic involved by drag and drop. We agreed on the fact that most of MVVM posts are very theoretical regarding MVVM and when they are not, the testing part, is only mentioned never detailed. That is why I decided to write this concrete post focusing as much as possible on the testing topic.

 

The objective of this post is to detail the code architecture and the techniques involved to the testing of a very simple WPF app. This app enables the user to rank via drag and drop the list of the french football clubs and save this ranking. This could be a part of larger app that could be used, for example, to bet the final table… However for the sake of simplicity of this post we will focus mainly on the WPF control ListView containing the football club rows. The source code can be found in this github repository.

 

List view control displaying the football clubs that can be reorganized by drag and drop. The order can be saved

List view control displaying the football clubs that can be reorganized by drag and drop. The order can be saved.

We will use an external library that wraps all the complex events handling regarding the mouse action involved in the drag and drop. Following unit testing principles, we will only test our logic which will be the movement of elements in the collection the ListView is bound to. In order to add little bit of extra complexity, we would like to allow not only the movement of one row but also of a block of contiguous rows.

 

There are tons of blog posts and articles on theoretical description of MVVM written by brilliant developers so I will try to be as brief as possible and will focus more on the example.  The fundamental and natural principle on which MVVM and other UI pattern are based on is to separate the UI from the business logic. In one sentence, the application logic should not be tied to UI elements. The Model/View/ViewModel comes in three parts as well summarized in this blog
  • A view is simply a UI page. It does not know where the data is coming from.
  • A ViewModel holds a certain shape of data, and commands, that a View binds to.
  • The model refers to the actual business data, which is used to populate the ViewModels.
The basic interaction rules can be summarized in the drawing below.
MVVM interactions overview

MVVM interactions overview

Speaking more in term of WPF, the view contains the UserControls, the windows. A view class definition is split between the xaml file (simplifying UI design) and the associate .cs file called code behind. If an application is coded following MVVM principles the code behind should be small, containing code on the UI elements that are difficult to expressed with XAML syntax (e.g. keyboard bindings).

 

Now it is time, to present the external tools that we are going to use in this small app. The drag and drop mouse interaction will be handled by the open source project GongWPF. For unit testing we will use the Visual Studio Test framework and Moq for creating mock objects. For a real and more sophisticated app written with MVVM, I would recommend you to use a framework. Personally, I do like MVVMLight.

 

Let us describe the code of our app starting by the so-called model part. This is a natural way because, in real scenarios this may be existing parts, written before ever considering the UI. However, in this fake app it is going to be very simple. The main business interface is IFootballClub exposing three properties regarding the club.
The core model is represented by the interface IChampionship. It is extremely lightweight in our situation because, in this post, we want to focus more on the View/ViewModel interaction. However, we have added the property CurrentChampionShipRanking and GetGoodBetCount as examples of methods that could be put in the model.
Let us now present the interface for our ViewModel, IChampionshipViewModel, which is the most important part of this blog post. Therefore, it will be the only interface where we provide the implementation. This implementation will handle the drag and drop core logic and will be the system under test for our matter. The list of football clubs will be kept in the FootballClubs observable collection. This collection handles natively all the notifications for the view. The Save action will be handled by the SaveClick property whose type is ICommand. An ICommand is an interface for an action that can be executed.

 

Remark also that IChampionshipViewModel extends IDropTarget which is the main interface provided by GongWPF for handling the drag and drop events. This interface contains two methods void DragOver(IDropInfo dropInfo) and void Drop(IDropInfo dropInfo)
To complete the overview let us present the xaml for our view. Indeed, following MVVM principles, our custom UserControl is essentially XAML leaving no code behind. The most important part is the binding of the View to the ViewModel via the DataContext property. In our case, we have used a ViewModelLocator (a very simple one with no IoC container) see  this post for more information on the ViewModelLocator pattern. Naturally, the ListView ItemsSource (the list of rows) is bound to the FootballClubs property of the IChampionshipViewModel interface. For each column, we can bind to a property of the interface IFootballClub. Note also, that the Resharper AddIn enables intellisense and type validation of those bindings which is really valuable for early detection of errors.
Finally, the ListView control has the following GongWPF attributes:
dd:DragDrop.IsDragSource=”True”, dd:DragDrop.IsDropTarget=”True”, dd:DragDrop.DropHandler=”{Binding}”

Thanks to these attributes, GongWPF will be able to make a bridge between the mouse UI events and the methods of the IDropTarget interface which our ViewModel extends.

Unfortunately, as brilliant as it is, GongWPF does not do everything and its our responsibility  to implement the logic that moves the elements within the ObservableCollection FootballClubs. 
Following the TDD principles let us write tests first. But before that, let us have a glimpse at our SUT (system under test) which is the class ChampionshipBetViewModel. The model IChampionship is injected as a constructor parameter. We will not discuss further the SaveClick part but we use a custom implementation of the ICommand interface which basically execute the lambda expression passed as parameter. This Action typed lambda updates our model with the reranked list of football clubs.
Here comes our first unit test. I think it is a good thing when a test can expressed in term of a simple sentence such as “Given… When … Then…”. Logically, the test method name should be closed to this sentence. The first one will assert that ” given a list of four rows when the the source is the first row and the target is the second one then the list of row should be reordered“. Remark that the target (the InsertIndex in GongWPF API) corresponds to the row instance preceding the inserted item. Being clear with this convention, the GongWPF interfaces are easily mocked using Moq, resulting in the following unit test. We assert that after executing the Drop method the list is club2, club1, club3, club4

For having a proper case coverage it is also important to assert “negative” situations such as the following one “given a list of four rows, if the source is the block containing the two last rows and the target is the second one then the drop action should not change the order

Remind, that we have for specification to be able to move a block of contiguous rows at once but we do not want to move two discontinuous blocks. Therefore, the DragOver method should handle properly this situation: the styling that allows insertion should be set in the first situation and not set at all in the second one. To assert this with unit tests, we use the VerifySet methods on the mock object dropInfo. For both properties DropTargetAdorner and Effects, we verify they are set when the selected items forms a contiguous block and not set when the two selected rows are not adjacent. If those conditions are not met the tests would fail, indeed, Moq framework would throw exceptions.

We finish this post by showing the true implementation of the ViewModel. We do not provide the details of the method MoveAllLeft and MoveAllRight they can be found on the github (they probably can be reviewed and shortened) .

To conclude, we have shown the basic ingredients for the testing of a ViewModel, this tests suite can be extended to complete a strong code coverage (there are many corner cases in our situation). Not also, that the MVVM pattern allows you to test the command, for example the SaveClick. Thanks to the Moq VerifySet method, you can check that the setter on the UserBet property for the mock Mock<IChampionship> is called (see project on github).

All tests running successfully

All tests running successfully

An unexpected quadratic cost in Excel Interop

My current task at work is the development of an excel addin. This addin is developed in C# .NET and is based on the Excel Interop assemblies, we also use Excel DNA for the packaging and the User Defined functions. While developing a new feature I stumbled upon a technical oddity of Excel Interop which I will describe to you in this post.

Let me start this post by reminding you that a range in Excel is not necessarily a block of contiguous cells. Indeed, try it yourself by starting excel right now. Then you can select a range, keep the Ctrl button of your keyboard press on and select an other block of contiguous cell. Then, you have several cells selected that you can name (as shown in the screenshot). Finally, you have created a named range with non-contiguous cells.

ranges

Having said that, let us assume that for our addin we need to reference programmatically the range of all lines of the form, with usual excel notations, Ax:Cx where x describes a set of row indices. 

Then we need to use the method Application.Union of Micorsoft.Office.Interop.Excel and finally produce few lines of code that  looks like that.

In the chart above we have monitored the time execution of the BuildUnionAll method for different values of the parameter count.

linear

Remark: in the case of BuildUnionAll there is no need to use a loop and the Union method, we could have just ask for the range “A1:Ccount”. Note also that for small unions you may also use a syntax with semicolon to separate contiguous cells blocks e.g. worsheet.Range[“A1:C3;A8:C12”]. However, this does not work for large ranges made of multiple non-adjacent cells blocks.

So far so good, we see an almost linear curve, which is natural regarding to what we were expecting.

Now, change a little bit our expectation to something quite different and more realistic where we would truly need the Application.Union method. Then let us say that we would like to have the union Ax:Cx mentioned above but for x odd index only. We want the IEnumerable<int> to have the same size than before, so let us use the method in the code below.

Similarly, we monitor the performance curve.

quadratic

Argghhh!!! we get an awful quadratic cost which makes our approach completely broken for large unions. This quadratic cost was unexpected. Actually I did not found documentation on this (the msdn doc on Excel.Interop is really minimalist). However, it seems that the rule is that the Union method has a linear cost depending on the number of Areas in the input ranges. The Areas member of a Range is the collection containing the blocks of contiguous cells of the range.

This experimental rule, leads us to review our algorithm in a different way. If the cost of an Union is important (linear) when there are many areas in a range. Then we will try to minimize this situation: we will let our algorithm perform the union preferably on ranges having fewer areas. Once again, the basic techniques from school bring a good solution and we will design a very simple recursive algorithm based on the divide and conquer approach, inspired for the merge sort algorithm.

To the end, we recover an almost linear curve. The asymptotic complexity here (if the rows to pick are not adjacent to each other) equals the merge sort one which is O(n.ln(n)).

divideAndConquer