An often overlooked feature of C# (and OO programming in general) is the use of abstract classes to maximise code re-use. Put simply, if you have code in related classes that is the same but needs to call implementation specific methods, you can probably use an abstract class to consolidate this code. Lets dive right in with a simple example.

This is production code that has been stripped back to highlight the use of abstraction. In my scenario I had a number of user controls that had to implement the same functionality to each display three different views. The initialisation code ran through the same method calls in each control but the implementations of the called methods were different. Enter the abstract class …

public abstract class ControlBase 
{
    public int ViewMode { get; set; }
 
    protected abstract void SetSaveButtonEnabled();
    protected abstract void SetCollapsedView();
    protected abstract void SetSummaryView();
    protected abstract void SetExpandedView();
    protected abstract void HideAll();
 
    protected virtual void InitControl()
    {
        SetViewMode();
        SetSaveButtonEnabled();
    }
 
    protected virtual void SetViewMode()
    {
        HideAll();
        switch (ViewMode)
        {
            case 1:
                SetCollapsedView();
                break;
            case 2:
                SetSummaryView();
                break;
            case 3:
            case 4:
                SetExpandedView();
                break;
        }
    }
}

The InitView() and SetViewMode() methods are the same across all controls. Obviously the actual code to render the correct view is specific to the implementation of the control itself. So how does it work? Firstly, an abstract class can never be instantiated … it can only be inherited from. Any methods specific to the implementation are declared as abstract. In the abstract base class we know what the method signature should be but we can’t implement it at this level. Once the signature is provided and declared abstract we can call that method in the abstract class code as demonstrated in the SetViewMode() and InitControl() methods. At runtime this will result in the implementation of the method in the child class being called.

Our inherited class would look something like this …

 
public class Control1 : ControlBase
{
    protected override void SetSaveButtonEnabled()
    {
        //control specific code here 
    }
 
    protected override void SetCollapsedView()
    {
        //control specific code here 
    }
 
    protected override void SetSummaryView()
    {
        //control specific code here 
    }
 
    protected override void SetExpandedView()
    {
        //control specific code here 
    }
 
    protected override void HideAll()
    {
        //control specific code here 
    }
}

In the child class we override the abstract methods. Failing to override all the abstract methods on the base class will result in a compile time error unless your child class is also abstract.

That’s really all there is to it. By using this technique I saved having the InitControl() and SetViewMode() methods being implemented with the exact same code in all of my child controls. This would at best have been copy-paste coding which is horrible and to be avoided at all times. A bug in one of those methods would have resulted in needing to update all the implementations to fix it. Add the complexity of working in a team and another team member may not realise that the code is repeated in multiple controls. By using the abstract class there is only one implementation to maintain making maintenance much simpler while allowing a much more object oriented design.

More info on MSDN

If you’re using a Repeater control and have a requirement to have radio buttons in the repeated rows you may find yourself in a head scratching mess. You may find that checking one radio button does not result in all other buttons being unchecked. The radio buttons will essentially start to behave like a bunch of check boxes … not cool.

With normal html radio buttons we group them together using the ‘name’ attribute. All radio buttons with the same value in the name attribute become mutually exclusive resulting in the familiar behaviour where only one radio button in that group can be checked at any one time. In an asp:RadioButton control the name attribute maps to the GroupName parameter which normally works fine.

Things start to go astray when the radio buttons are added to a repeater however. You may be aware that asp.net will insert its own unique id for each control which is not the same as the id you originally gave it in code or markup. It does this to ensure that any elements that have the same id end up with a unique id once rendered. In the case of the repeater this is very necessary as you are taking the same elements with the same id and emitting them multiple times. Unfortunately a repeater also mangles the name attribute of the controls. Normally this can be safely ignored but radio buttons rely on this attribute to work out which group they belong to. All of a sudden each radio button belongs to its own little group and so we end up with check box behaviour.

This is a known issue explained in detail here, however, Microsoft have not yet fixed this and give no indication of if or when it will be fixed.

So now what? Well … there are a couple of work-arounds, none of which are particularly elegant.

1) Avoid using the repeater or radio buttons and see if you can solve the problem with other controls.

2) If you’re stuck with repeaters and radio buttons the most elegant solution is to use javascript to de-select other radio buttons using the click event.

This goes in the <head> tag …

 
 //I use jquery to make life easier but you don't have to 
<script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.5/jquery.min.js"></script> 
 
<script type="text/javascript">
    function MakeRbExclusive(rb) {
        var rbs = $('#rbData :radio');
        for (var i = 0; i < rbs.length; i++) {
            if (rbs[i] != rb) rbs[i].checked = false;
        }
    }
</script>

And our repeater …

<div id="rbData">
    <asp:Repeater ID="repeater" runat="server">
        <ItemTemplate>
            <!-- I have bound to simple Dictionary<string, string> created in page load for example purposes -->
            <asp:Label ID="lbl" runat="server" AssociatedControlID="radio"><%#Eval("key")%></asp:Label>
            <asp:radioButton ID="radio" runat="server" value=<%#Eval("value")%> onclick="MakeRbExclusive(this);"/>
            <br />
        </ItemTemplate>
    </asp:Repeater>
</div>

3) Avoid the use of a repeater completely and add your controls dynamically from code behind in a loop to achieve the same result. I *really* don’t recommend this. It is finicky at best and takes very careful coding. Dynamically added controls are not automatically tracked in viewstate and can create big problems if not carefully coded. I have had to do this in the past but it is definitely an option I’d only consider once I have exhausted all others.

Happy coding!

We’re touring through Spain for five weeks avoiding motorways like the black plague. This is the town of Morella in the background … as you can see the bike is fully laden … three box luggage kit, tank bag and we’re two up … you could say we’re making use of the ‘tourer’ aspect of the bike’s design …

This video is of us having a little fun on a nice little stretch of road between Barcelona and Morella … I have to give the bike credit here for still handling given the weight its got on it

www.youtube.com/watch?v=vhaDmqhEeTI

We are often required to implement the singleton pattern in our code. While doing this yet again I thought there must be a generic way to do this and I came up with the following code …

public static class Singleton<T> where T : class, new()
{
   private static volatile T _instance;
   private readonly static object _lockObj = new object();
 
   public static T Instance
   {
       get
       {
           if (_instance == null)
              lock (_lockObj) if (_instance == null) _instance = new T();
 
           return _instance;
       }
  }
}

This allows you to use any class as a singleton …

var mySingleton = GenericSingleton<MySingleton>().Instance;

It’s not perfect … there is nothing stopping the developer from creating a new instance of the class which breaks the singleton pattern. Doing it the normal way makes it impossible to create more than one instance of a class but this way allows the flexibility to use a class as a singleton even if it’s not implemented that way and also allows a mix of singleton and instances of the same class.

In any event it makes interesting use of generics and I just thought it was cool so I thought I’d share

I often have to insert multiple rows of (usually) test data into tables. The simplest but most tedious way is to rewrite the INSERT statement over and over with different values …

INSERT INTO User VALUES ('Penny', 'Penny')
INSERT INTO User VALUES ('Sheldon', 'Cooper')
INSERT INTO User VALUES ('Leonard', 'Hofstadter')
INSERT INTO User VALUES ('Howard', 'Walowitz'
INSERT INTO User VALUES ('Rajesh', 'Koothrappali')

Its not a big deal but as a developer I hate writing the same statement over and over … it just goes against my grain. Its also more of an overhead to repeatedly call insert for each row. Here’s a better way …

INSERT INTO User
SELECT 'Penny', 'Penny' UNION ALL
SELECT 'Sheldon', 'Cooper' UNION ALL
SELECT 'Leonard', 'Hofstadter' UNION ALL
SELECT 'Howard', 'Walowitz' UNION ALL 
SELECT 'Rajesh', 'Koothrappali'

This inserts the same data as the first example but uses only one insert so has less overhead. If you happen to be running SQL Server 2008 there’s a new syntax to achieve the same although the above example will still work. In SQL Server 2008 you can use this syntax …

INSERT INTO User
VALUES ('Penny', 'Penny')
, ('Sheldon', 'Cooper')
, ('Leonard', 'Hofstadter')
, ('Howard', 'Walowitz') 
, ('Rajesh', 'Koothrappali')

Viewstate is often touted to be heavy and slow and better off disabled in most aspx applications. When used properly veiwstate can be quite a useful tool with not too much overhead. Use it improperly and all the horror stories you’ve heard start to come true …

If you view page source in an aspx application that has viewstate enabled site wide you will see the hidden __VIEWSTATE field will have a long encoded string of data. This is quite heavy and takes some time to trasmit betweeen the server and client. Our aim is to minimise the length of this data load to the point where overhead is no longer a concern.

First of all viewstate is enabled by default across the entire project so the first thing we need to do is turn it off. The idea is to opt in to viewstate rather than opt out. We only want to turn it on for the controls where we specifically want to maintain state.

In each masterpage or at the top of each page you can place this code in the page directive to disable the viewstate.

<%@ Page EnableViewState="False"  ViewStateMode="Disabled"%>

Or you can disable the viewstate across the whole application by putting this in the Pages tag in web config.

<Pages EnableViewState="false"  />

Now that Viewstate is off by default … we can choose which controls we want to maintain state for. Most text fields and simple controls will be fine without viewstate. As a general rule leave it off until you have a specific reason to turn it on. The give away will be when you try to access the value of a control in code behind and get the default value no matter what value was set. In this case its time to turn on viewstate for that control only. We do this by using the same code as we did to turn it off …

<asp:DropDownList runat="server" ID="myDdl" EnableViewState="True"  ViewStateMode="Enabled"/>

You can add this to any control and access its value from a postback. If you view the page source again you will see the __VIEWSTATE field is much smaller … naturally the larger number of controls you enable viewstate for the larger the field will be.

Use it with caution but don’t write it off as bad practice.

All over the web I see the code you see below. While it will work it is wrong … don’t do it! A web response stream is a stream like any other, you need to ensure that it is closed when you are finished with it or it will not release its resources. In the case of a web response (or request for that matter), failing to close it could mean the server will run out of connections. In a high traffic web site this won’t take all that long.

Let’s take a look at the code … what would happen if the call to Write throws an exception? Execution would stop right there and the exception will get bubbled up the call stack. The call to Close will never happen and the response stream will remain open reducing the server’s connection capability by one.

 var responseStream = response.GetResponseStream();
 responseStream.Write(byteData, 0, byteData.Length);
 responseStream.Close();

We can avoid this by putting the call to Close in a finally block as below. This would guarantee that the call to Close will be made even if an exception is thrown. This code is perfectly valid, but cumbersome to have to do every time you need to ensure a resource is released.

var responseStream = response.GetResponseStream();
try
{
    responseStream.Write(byteData, 0, byteData.Length);
}
finally
{
    responseStream.Close();
}

The code can be rewritten as below to produce the same behaviour. The ‘using’ keyword automatically calls Dispose (as good as calling Close) on the resource as soon as it falls out of scope resulting in the same behaviour as our finally block. Any time you use a stream, db connection or any resource that needs to be released, use a ‘using’ statement and you can’t go wrong.

using (var responseStream = response.GetResponseStream())
{
    responseStream.Write(byteData, 0, byteData.Length);
}

With the release of the new Windows Phone 7 I figured it might be time for me to get into the mobile market. I’ve been developing business systems for a long time now and the mobile platform offers me the ability to release some funky consumer based apps that I can actually sell. So I figured I’d have a go … I wrote a simple app that was more of an exercise for me to learn the platform rather than something which was going to change the mobile world forever. It didn’t take long and I was ready for release … and this is when the pain started.

I submitted my app and after waiting a few days was notified that it had failed testing because the icon for the tile was missing should the user pin the app to their home screen. My bad .. an error in the resources file was causing the image to not be found .. easy fix. At this point I figured that the rest of testing must have been fine because this was nothing that would stop the app from being tested. Not so. I resubmitted only to be failed again because of a bug … fixed it … resubmitted .. failed again for another unrelated bug … fixed it .. failed again because I had no easy way of a user finding the version number or support contact. Sent an email to support asking for clarification as to what they wanted me to do for a user to be able to find this information … I have never received a reply. I gave up waiting and resubmitted with my email address in the support email field this time despite this being optional … failed again for the same reason … added an about screen and finally passed. Talk about a mission!

Now I don’t argue that the bugs weren’t mine .. they were .. and its a credit to Microsoft’s test team that they test so thoroughly. I do think its a bit rough that the testers take a test and stop approach even if the bug they find does not prevent further testing. Not only does it waste my time but it is certainly not the most efficient way for the Microsoft test team to carry out their work either. They had to test my app six times when they could have just done this twice. A missing icon did not in any way prevent testing. So why was it failed just for that with no further testing done until I resubmitted with the icon bug fixed?

In case you didn’t know … Microsoft allows only five free app submissions .. that is … each time an app fails testing you use one of your free submissions up. I, like may others, thought this meant five free apps can be released not just submitted. Naturally enough I was trying to release mine for free .. it was just an exercise after all
… but due to a testing process which stops and repeats at each bug … by the time I came to release it I either had to pay a fee to release it for free, or put a price on it. This makes my suspicious side believe that A) the testers are lazy and move on to the next app a soon as they have an excuse to reject the one they are testing and B) they do this on purpose to reduce the number of free submissions you have so that you either pay to release you app for free or you put a price on it. I put a price on it and am now quite confident no one will download it … the functionality does not justify even a small price.

Considering that the only complaint I have heard about WP7 is the lack of good apps … you would think that microsoft would be working hard to get developers on board rather than treating them like second rate citizens. Knocking back an app repeatedly for each bug one by one is ridiculous when that bug does not prevent further testing. It demoralizes a developer, wastes our time and is ridiculously inefficient.

I am now working on an iPhone app … I might go back to a WP7 app later … I really should buy a device to test on. And this is my final problem .. I already have everything that I need to develop iPhone apps. To develop for WP7 I need to buy a device. This represents a decent investment which I may not recoup given the tiny market share held by WP7 at the moment. Given my experiences with app submission I am less likely to actually take this risk now due to the downright idiocy of the submission and testing process.

You did well with the OS Microsoft … it only took you ten years and a hiding from your competitors … don’t let a bad submission process screw you and your hopeful developers over … pick up your game …

I have often wondered about Linq to objects. When we use a linq Select or FirstOrDefault statement what is the complexity of the call? Does it iterate through the entire list until it finds the object it is looking for in which case we are dealing with O(n) complexity? The other day I had to write a small migration tool that answered my question. Linq to objects does in fact iterate through every item in a list until it stumbles across the object it is looking for. Take the following case…

 
private List<int> 
private List<int> list2;
 
Public LinqTester()
{
	Console.WriteLine("Populating lists ...");
	list1= new List<int>();
	list2 = new List<int>();
 
	for(var i = 0; i <= 100000; i++)
	{
		list1.Add(i);
		list2.Add(i);
	}
	list2.Sort();
}
 
public void LoopTest()
{
	Console.Write("Starting loop test ... ");
	var start = DateTime.Now;
	foreach (var num in list1)
	{
		list2.FirstOrDefault(x => x == num);
	}
	var timeTaken = DateTime.Now - start;
	Console.WriteLine(string.Format("Time taken = {0}", timeTaken));
}
 
public void BinaryTest()
{
	Console.Write("Starting binary test ... ");
        var start = DateTime.Now;
	foreach (var num in list1)
	{
		list2.BinarySearch(num);
	}
	var timeTaken = DateTime.Now - start;
	Console.WriteLine(string.Format("Time taken = {0}", timeTaken));
}
 
//output
//Starting loop test ... Time taken = 00:01:16.5160000
//Starting binary test ... Time taken = 00:00:00.0170000

From this simple test we can see that using a binary search is by far more efficient than using linq to objects. When you think about it the compiler has no way of knowing if the list is sorted or how to compare the objects contained in the list if they are objects rather than primitives. It is impossible for the compiler to optimise the search so it can only do a linear search through the collection until it finds the item it is looking for. If you’re dealing with small collections this isn’t an issue but when the collections get large or if you’re concerned about performance then it’s worth considering whether linq is the appropriate choice.

Power Commands is a free and extremely useful plugin for visual studio. Among its many features is ‘Collapse All’ so that you can collapse the solution tree in the solution explorer and ‘Open Command Window’ to open a command window in the directory of the selected project. These are the two features I use the most and prove invaluable as the solution I use at work has 91 projects attached to it … this can be really painful to navigate when a number of the projects are expanded. Well worth the download …

Download Here