Make the XmlSerializer Your Friend

Over the years I have had to do a number of integrations with third party xml web services. These have included credit card payment gateways, government agencies, hotel booking engines and even game providers. Before all the cool kids jump in and say we should be using json, yes we should in a perfect world where we get to rewrite our software every time that the latest and greatest cool thing comes out. For those of us in the real world, these things still exist and need to be maintained and integrated with … enough said.

There are a few ways to consume xml, some good, some not. Lets have a look …

1) You can use XmlWriter and XmlReader classes to manually parse and write the xml. This method is error prone, time consuming, inefficient and difficult to read and maintain. Each time you modify the model object you also need to modify the serializer and deserializer. The one and only upside is that it gives you complete, utter control over the serialization and you can map to whatever object you like in one go. It is the most infinitely customisable way of consuming xml. I have never actually found the need to do it this way … I suggest you don’t either ;)

2) You could use an XmlDocument object or even LinqToXml. This can be handy if dealing with a simple document or you only want one or two nodes out of a complex xml structure. In general this isn’t much better than manually parsing xml if you are trying to deserialize an entire object and is only a little less verbose. Still not a great idea except for the case where it just a node or two.

3) My preferred option … use the built in XmlSerializer given to you by Microsoft. Its not difficult to use and is easily customised using attributes on your model objects. At the end of the day, the xml is a model of data which can easily be translated into model objects.

Lets start with a sample xml that we want to deserialize. Its the standard cookie cutter person-with-an-address structure but its enough to give the basic idea …

 
<?xml version="1.0" encoding="utf-16"?>
<people>
    <person dateadded="2007-09-24T08:00:00+02:00">
      <firstname>Leonard</firstname>
      <surname>Hofstadter</surname>
      <address>
        <housenumber>12</housenumber>
        <street>Some Street</street>
        <suburb>Los Angeles</suburb>
        <state>California</state>
      </address>
  </person>
  <person dateadded="2007-09-24T07:00:00+02:00">
    <firstname>Sheldon</firstname>
    <surname>Cooper</surname>
    <address>
      <housenumber>12-B</housenumber>
      <street>With Leonard</street>
      <suburb>Los Angeles</suburb>
      <state>California</state>
    </address>
  </person>
</people>

The nice touch about using the serializer is that it almost totally abstracts the fact that you are dealing with xml by mapping to a set of objects that model the data. Here are those models … we have a People class that contains a list of Person classes that each contain an Address class …

 
    [XmlRoot("people")]
    public class PeopleCollection
    {
        public PeopleCollection()
        {
            People = new List<Person>();
        }
 
        [XmlElement("person")]
        public List<Person> People { get; set; }
    }
 
    [XmlType("person")]
    public class Person
    {
        [XmlAttribute("dateadded")]
        public DateTime DateAdded { get; set; }
 
        [XmlElement("firstname")]
        public string FirstName { get; set; }
 
        [XmlElement("surname")]
        public string LastName { get; set; }
 
        [XmlElement("address")]
        public Address Address { get; set; }          
    }
 
    [XmlType("address")]
    public class Address
    {
        [XmlElement("housenumber")]
        public string HouseNumber { get; set; }
 
        [XmlElement("street")]
        public string Street { get; set; }
 
        [XmlElement("suburb")]
        public string Suburb { get; set; }
 
        [XmlElement("state")]
        public string State { get; set; }
    }

Nothing really that special … just a simple set of objects that represent the data contained in the xml. The decorators on each property and class tell the serializer how to serialize and deserialize the values. Does it output the property value as an attribute, an element or simply ignore it altogether? The decorators are optional .. if they are omitted the serializer will expect the xml to have the same elements (case sensitive) as the property names and all properties will be serialized as elements.

In this case I have purposely changed the cases of the xml and the property names to demonstrate the use of decorators to customise the serializer. You may note that in the Person class I have mapped the surname element to the LastName property by using the decorator and I have also specified that DateCreated should be emitted as an attribute. More information about the many decorators that can be used to control serialization can be found here.

From this point the serialization code is straightforward …

 
    public class Serializer<T> where T : class 
    {
        public string Serialize(T obj)
        {
            var serializer = new XmlSerializer(typeof (T));
            var namespaces = new XmlSerializerNamespaces();
            namespaces.Add(string.Empty, string.Empty);
 
            var sb = new StringBuilder();
            using (var writer = XmlWriter.Create(sb))
            {
                serializer.Serialize(writer, obj, namespaces);
            }
 
            return sb.ToString();
        }
 
        public T Deserialise(string xml)
        {
            var serialiser = new XmlSerializer(typeof (T));
            using (var stream = new MemoryStream(Encoding.Unicode.GetBytes(xml)))
            {
                return serialiser.Deserialize(stream) as T;
            }
        }
    }

The full example solution can be downloaded from GitHub
Happy coding :)

Sexism in IT

There has been a spate of tweets, articles and blog posts in recent times about sexism in the IT industry. They have ranged from the daily niggles of working with predominantly male co-workers to full blown internet lynchings of companies for the use of scantily clad women in advertising or as service staff at events. These are not anything new, these things have been happening in the IT industry for years and are only coming to the surface now because of the rise in numbers of female IT staff in traditionally male fields of expertise. There’s power in numbers and the more women in IT the less tolerated these behaviours will be. And there’s the rub … the solution to sexism in IT is more women in IT and this leads me to the motivation for writing this post.

It’s a well known fact that bad news makes for good reading. This is every bit as true for the online world as it is for traditional media channels. Any women doing any kind of research on the internet as to a career in IT would surely be dissuaded from such a choice. We have to be careful to not discourage women wishing to join the IT industry with horror stories of discrimination and objectification of women. For every company that has objectionable behaviour towards women, there must be hundreds that don’t. There might even be a few that treat their female (and male) staff very well. But somehow these are unworthy of tweets, articles and blog posts that may show the IT industry as being a place where a woman may find herself a nice career.

I have spent the last ten years working for multiple companies in multiple locations around the world and continue to enjoy my career immensely. I feel like the IT industry is in such a dynamic state at the moment with all the new devices and technologies that have emerged in recent times and it’s a volatile and exciting time to be in this field. I would encourage any person with an aptitude for computers to pursue a career in IT regardless of their race, age or gender and I think it’s a shame that some of these people may be discouraged by reading all negativity on the internet.

I am not, in any way, suggesting that the companies that step over the line should not appear in articles, blogs or be tweeted into submission. I am, however, suggesting that we should endeavour to present a more realistic image of the IT industry as a whole. Lets add some balance by also highlighting the companies that treat their female staff really well or even go the extra mile somehow. Lets tweet about what it is that makes us turn up to work every day or to spend our personal time pouring away over open source projects. If you are a female in IT, make yourself known by writing a blog and sharing your experiences, the good ones as well as the bad ones, and why you joined the IT industry in the first place.

In my time I’ve been lucky enough to have worked with a handful of very talented female developers. I even fell in love with one. We need more of these women. We need more of them now and we need more of them in the future. Eventually I really hope that the cause of the recent rants is a thing of the past and we can get back to what we love … coding!

Code Re-use With Abstract Classes

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

Radio Buttons and Repeaters in Aspx

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! :)

Barcellona to Morella, Spain

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 …

Morella, Spain

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 :)

Generic Singelton

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 :)

Insert Multiple Rows With a Single Insert

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 not evil

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.

Bad Examples

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);
}

Releasing an app to the Windows Phone 7 marketplace

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 …

Return top