XAML: Event Handlers for Templated Items of Collection Controls

Recently, while fighting my way through XAML required to create a relatively simple UI for a Windows Phone 8 application I have come across some unexpected difficulties. When it comes to hacking markup I prefer to modularize it as much as possible – many of us do. Here we follow the same ideas that govern us when we write imperative code and break it into relatively small and simple functions and classes to assemble them into something bigger on higher levels. The benefits of this approach are well known: better isolation, finer specification of responsibilities and less code duplication. With markup we usually behave worse – the code for pages frequently feels quite monolithic and it is difficult to explicitly split it into parts each of which pursues its own goals. Here XAML gives us ControlTemplate and DataTemplate allowing to improve the state of affairs to some extent. The DataTemplate is primarily used with collection controls so that we can specify the way each element should be displayed. In my specific case the parent control was LongListSelector, which should have displayed a list of more or less complex items.

Testing: Factory Method

These days I am working slowly on a Windows Phone application. Making my first steps in this direction turned out to be quite frustrating, although this is a topic for another post. As a disciplined developer (ha!) I started the project with unit tests and while writing these I noticed that there is a thing that I do automatically now. Including a kind of factory method into each and every test class which I write has become a habit for me, saving a lot of time and effort.

C#: Side Effects and LINQ's Defferred Execution

It is difficult for me to imagine a program that doesn't deal with collections of some type – all our applications do proliferate with Arrays, Lists HashSets, DataTables and dozens of others. When writing code in C# the first tool I consider when faced with a collection is LINQ. Its capabilities combined with the fact that LINQ queries can be applied to nearly everything make it a very powerful tool saving a lot of time for any .NET developer. Still, no power comes for free and every piece of equipment must be used with some caution.

 

One of the paradigms widely used by LINQ is lazy evaluation. Most LINQ methods, although it seems that these just return results immediately, are actually deferred. What it means is that whenever you write something like var strings = myArray.Select(n => n.ToString()); the only thing done at the moment of execution of these lines is creation of a query object. Real work in this case is not approached until someone wants the results. This is a well-known fact about LINQ and generally doesn't do any harm. However, when the processing wrapped into LINQ queries is not pure in the functional sense of the word quite strange and difficult to track down problems may occur. Below I will try to demonstrate such a case. 

C#: LINQ and IEqualityComparer

When writing programs in C# with the help of LINQ I have come across the IEqualityComparer<T> generic interface several times. The name conveys the purpose of the interface clearly, still, surprisingly, my first attempts to apply it were marked by strong confusion - the thing merely didn't work the way I wanted it to. Moreover, after going to Google and StackOverflow I have noticed that I'm not the only one to face difficulties with it. After inspecting multiple SO questions and answers related to the topic as well as some other articles I have both found the solution that fitted my needs for the moment and got some understanding of the way IEqualityComparer is actually used by LINQ operators. Here I will try to explain what I got from there.