Tuesday, September 27, 2011

Always use a comma in property initializers

C# has a feature that lets you always have a comma after an item in initializers even if they are the last property or item.  For example this is all valid code:

I am of the opinion that you should always include the comma even when it is the last item as it makes source diffs cleaner later if you need to add or remove an item.  For example compare this diff where a comma wasn’t included for the last property, with the next one where a comma was used for the last item.

I think you will agree it is much easier to identify what changed in the second example.  The same holds true for when you remove a property or item from you initializer.  The source diff will always be clean if you always use a comma, so use it!

Sunday, August 28, 2011

What to do when your Sharepoint WebPart is causing authorisation issues

Whilst working with a client to customise some of their public facing Sharepoint pages I developed a number of custom web parts.  One of these web sites was getting some of its information by enumerating the different sub sites of the site collection.  Unfortunately while this worked well when the site’s users were authenticated it didn’t work if they were anonymous users, which of course the majority of the sites users would be.  When an anonymous users navigated to a page with this webpart they were prompted for their credentials.

There is a simple solution to this problem which is to us the SPSecurity.RunWithElevatedPrivileges method, passing in a delegate to the work that is requiring authentication.  Your code would look something like this:

Sunday, August 21, 2011

GuessWho a sample data library

I just published by first nuget package.  It is a library for generating sample identity information.  It allows you to write code like this:

Which produces this output:

For more information I recommend you check out the project page over at github or bitbucket.

Wednesday, July 20, 2011

Creating a custom SharePoint navigation menu

While working on a public facing SharePoint website I was asked to build layout that worked well with mobile devices.  For the most part I achieved this by editing the master page and then choosing which CSS file to link to based on whether or not it was the mobile page was being requested.  This approach worked well for most of my content, but the standard SharePoint navigation menu was somewhat problematic in that it lays itself using tables and is rather complicated.  I wanted it to be much simpler and just use a simple unordered list.

I ended up writing a custom ASP.NET control to do just that.  Of course I want the new menu to respect the same visibility settings for the different links and to stay in sync with changes to the sub site names.  The best way to achieve this is to use SharePoint’s built in site map.  My code ended up looking like this:

And the markup:

Sunday, July 3, 2011

What is wrong with WPF?

When WPF was first announced, I got me extremely excited.  I watched a number of the early demos and saw what was possible in terms of styling and animation and it just seemed amazing.  One demo showed how simply a ListBox’s template could be changed to display as a map of the world and each item was a country. Combine that with the promise of rich media support and hardware acceleration and I was convinced WPF was going to be the best thing ever.

Such was my excitement that I started working with WPF as soon as I could get my hands on it.  I have been working with it professionally since 2006 and over that time I have found a number of problems that routinely rear their ugly heads. I find it hard to stop thinking about a problem until I have a solution, but the nature of the problems combined with the fact WPF closes up so many possible extension points means I haven’t been able to come up with a solution using WPF as we know it today.

This combined with my OCD desire to solve problems has caused me to spend a lot of the time I should be sleeping thinking about how I could design a successor to WPF that was free of these problems.  Unfortunately I don’t have enough spare time to actually build the thing so I asked the tweeps to convince me I shouldn’t waste my time by starting to write a replacement. @jtango18 asked me why I would want to in the first place and this post will attempt to answer that question.

Poor design experience

One of the much touted features of WPF was supposed to be how it enabled designers and developers to focus on what they were good at.  Blend being the tool for designers and Visual Studio being the tool for developers.  The problem is that Blend is only any good for doing a design when you have some data to display and tends to fall down quite badly if you have certain constructs in your XAML or code behind.  Everything will work when you run the application but the designer just blows up.

Blend does have tools for generating some design time data, but this is limiting because of the time it takes to set it up and it also won’t work if you have different data templates which are selected based on the type of the object you are displaying.  There are many other small annoyances with using the designers, but the thing that frustrates me the most is that I often have to run my app, navigate to the part I am working on look at it, then go back and tweak the design and repeat infinitum.  When you are trying to decide on the best margin or colour for something in a data template I find my self wasting enormous amounts of time repeating that cycle.

My UI framework would be built with this in mind and would allow the designer to attach straight to the running process and edit the view live.  You could make use of the real data and get instant feedback as you made changes even when you are 3 or 4 templates deep.  I think this might actually be achievable with WPF as some of this can be done using tools like Snoop, but it would take a lot of work to get it to the same level of functionality that Blend supports.

Poor Animation Performance

I simply cannot understand this one, but I suspect it boils down to rendering performance.  I have often found animations involving a few objects, especially objects that have a few effects applied (eg drop shadow) do not animate smoothly into position.  I refuse to believe that my laptop is incapable of rending a few UI vector shapes moving around with a couple of simple effects applied smoothly.  For crying out loud it can render this @ 60 frames per second at 1920 x 1200 and it has to do extra work like updating physics for 100s of objects:


Animations Fail To Play

Quite often when you have a UI component that has different states you would like it to look different in each state.  In .NET 4.0 the VisualStateManager was added to help with this sort of thing.  However I sometimes find animations between states, or animations that should loop while in a given state simply fail to play some of the time.  I have never been able to get it to work 100% of the time, it will work most of the time and then just fail for no apparent reason.

I encountered similar issues before the VisaulStateManager was added to the framework and in those situations it boiled down to not being able to apply the animation, because another animation was already applied to the object.  Given that animation was one of the key things WPF was supposed to make easier it is more than a little silly how many workarounds I have to use to get it to work properly.

Drag and drop

There is no inbuilt support for doing drag and drop with nice Windows shell effects, such as drag descriptions and thumbnails.  WPF is supposed to be about creating rich user experiences, but it doesn’t even let you easily do shell style drag and drop.  I have implemented a bunch of Blend behaviours which make this possible, but you wouldn’t believe how much trouble and how many hacks I had to use to get them to work properly without flickering.  Not to mention how MS decided to make the methods for accessing the mouse’s screen coordinates internal, you need the screen coordinates to prevent accidental drag and drop operation when the view is scrolling.

Missing effects

When you are trying to design a nice looking UI, gradients and drop shadows can go a long way.  Inevitably though you wind up wishing you could use a bevel, inner shadow, inner glow and maybe an outer glow.  If you have worked with Photoshop you will know how these effects can be used to create some quite striking visuals, but alas WPF doesn’t have support for them.

You can off course get some of these by using the old bitmap effects, which works fine as long as the object you are applying it too is tiny, but as soon as you add it to a big object things start to chug very very badly.  No worries I hear you say, you can just write your own graphics shader to do it for you.  Unfortunately WPF doesn’t support multi-pass shaders which are required for these effects.  Well actually it sort of does, the built in shadow effect does use multiple passes, but they don’t expose that functionality to you so you’re stuck with a single pass.  The end result is that you end up using lots of PNG images made by Photoshop and you can kiss your resolution independence goodbye.

Video and other media support is poor

I have worked on a couple of projects where the level of support for video playback in WPF has been very disappointing.  In both cases I ended up having to ditch WPF and go back to WinForms in conjunction with DirectShow.  WPF is fine if all you want to do is play a video here and there, but as soon as you want to do more than that you run into problems.

For example say you have multiple videos all playing at once and it is imperative that they stay perfectly in sync with one another.  This is not possible in WPF because your access to the underlying resources is too limited.

Another example, you would like to have one video playing in a loop and then, when the user presses a button immediately start playing another video with no noticeable pause between the videos.  However there is no way to tell WPF to buffer a video other than to play it, you can play it and pause it, but you still don’t know when the buffering is complete so it is hard to transition between the two.

Triggers are messed up

When I was first learning about triggers I thought they were awesome, but after you learn the limitations it starts to disappoint you.  For example you can’t use data triggers outside of a data template, why is that?  Then there is how you can’t say you want the trigger to fire when the value is not equal to the one you provide.  I actually spent quite a bit of time digging about in Reflector for a way around that one and eventually discovered that underneath it all triggers actually do support the idea of not equal, but it is never exposed anywhere.  I couldn’t make a nice fix for it though, because the trigger collections test to make sure they only receive specific implementations.  That just plain sucks, why can’t I write my own triggers? 

Some would say so I can’t so that I don’t write triggers that perform badly and then blame MS for poor performance, but I think that is the stupidest reason ever.  By giving me more power, sure it does increase the ways I can blow my head off, but it also lets me do amazing things that no one has thought of before.  Given that I’m a responsible adult let me decide if I want to play with fire or not, I won’t blame you if I burn my self.

Implementing Virtualizing Panels is Hard

So you have a list that has hundreds or thousands of items and you want to scroll smoothly.  You can sort of get away with the built in virtualizing stack panel, but it isn’t smooth and if you have your own layout you can forget about it all together.  We need a way to solve this problem that doesn’t take many, many hours to get something that is passable.

Binding Memory Leaks

By default if you bind to a POCO object that doesn’t implement INotifyPropertyChanged you get a memory leak, where the object you are binding too will never ever be garbage collected.  This is crap and should not happen.

Lack of composition and extension points

WPF was supposed to be all about composition over inheritance.  Control and Data templates do to some degree achieve this goal, but I just wish they had applied the same thinking to the rest of the framework.  For example the Button control’s inheritance hierarchy has eight classes before you get back to object. There is a school of thought that suggests that if the team had realised the power of attached properties earlier a lot of the functionality would be implemented as something like Blend behaviours instead of separate classes.

This inheritance tree can makes things rather difficult, because quite often you end up having to have a case in your code for both FrameworkElement and FrameworkContentElement, why the hell they don’t implement a common interface I have no idea.

When you put this together with so many places where your ability to extend the framework has been deliberately limited (eg triggers, low level video access and multi-pass shaders to name a few) you end up with a sour taste in your mouth.  I have spent many hours over the last few years getting around these problems in software projects I have been working on, but if WPF was just built a little differently I wouldn’t have the problem or there would be an elegant solution rather than painful hacks.

In Conclusion

So am I crazy and these problems only exist for me or have you had these problems too?  Feel free to leave a comment or haggle me @calebvear on twitter, I would love to hear about your experiences.

PRIEMTIVE NOTE: I have heard some of the news about Windows 8 and the new DirectUI and Jupiter APIs. Of course at the moment most of what I have heard seems to be largely speculative. I do hope that it will solve many of the issues I have today, but I doubt it will solve all of them.

Thursday, April 7, 2011

WPF Bindings Not Updating When PropertyChanged Raised When Bound Against a Proxy Object

Last week I came across an issue with binding NHibernate proxy objects to a WPF UI.  My problem involved a read only property that was not updated in the UI even though the property changed event was being raised.  It worked fine when I first created the object, but after loading it at a later time the updates didn’t work anymore.  Upon closer inspection I discovered that the object we were binding to was an Nhibernate proxy object.  To understand what was going on better I have put together a simple example, consider the following class:

This is a very simple shopping cart, we might have a WPF TextBlock bound to the Total property so that we can show the shopping cart’s total value.  Everything would work find, but if we loaded this class lazily so for example through a Customer.CurrentShoppingCart property, then the total TextBlock wouldn’t be updated.  The reason for this is that in order to delay loading of the shopping cart NHibernate uses a proxy object instead of the actual value when it initializes the Customer’s CurrentShoppingCart property.  How the proxy works can be seen in the following diagram.


When our TextBlock binds to the Shopping Cart Proxy’s Total property it also subscribes to the PropertyChanged event.  The proxy passes this subscription onto the actual shopping cart which adds the event handler to its PropertyChanged delegate and you would think all is well.  You of course would be wrong, here is what happens when the Shopping Cart raises a property changed event.


Essentially for our event to work we need the sender to be the shopping cart proxy and not the actual shopping cart.  To do this we will need to extend one of NHibernate’s proxy implementations.  We were using the Castle proxy implementation so the following code will work with that.  It would be quite possible to implement something similar with the LinFu version, but I’ll leave that as an exercise for the reader.  Before we start I will mention you can get the full gist here: https://gist.github.com/906916

First up we need to create a new version of the LazyInitializer, which will intercept calls to add or remove subscriptions and keep track of them in the proxy.  We will also subscribe to the target objects PropertyChanged event when it is created so that we can forward on property changed calls, to our subscribers.  We will leave everything else as it was.

The next thing we need to do is extend ProxyFactory to create our version of the LazyInitializer.  This is pretty straight forward and looks like this:

When then have to make our own implementation of IProxyFactoryFactory, our implementation is a straight copy of the one in the NHibernate.Castle.ByteCode assembly only we return our FixDataBindingProxyFactory instead of the Castle version.

And our last step is to update our config so that we use our new IProxyFactoryFactory.

We have now solved the problem.  I would like to thank Ioannis for a blog post he wrote related to this problem which included a solution although it didn’t fix my problem did point me in the right direction.

Happy coding!


Monday, March 7, 2011

Resharper Intellisense Annoyance

I have been using Resharper for about 5 months now and I must say that generally I have been loving it.  It has really helped improve the speed which I am able to do things in Visual Studio.  Its all the small things like moving a class to a different project or creating a new file which are just so much easier with Resharper.  Not to mention the navigation features like navigating to a specific member in the file your in or opening any file in the solution with ease.

The one thing that hasn’t always been pleasant though is that I haven’t been able to figure out a way to make Resharper’s Intellisense parameter info show me generic methods very well.


In this example the first method shown in the tooltip is actually a generic method that takes a generic parameter called TModule, but I can’t tell that from the parameter info tooltip.  When I am looking over some code I quite often want to see what other overloads of a method their are so I press Ctrl+Shift+Space to bring up the parameter info tooltip.  I have discovered that I can navigate to end of the method name an hit Ctrl+Space to show the method list which does show the generic parameters, but I would like to see it in the parameter list as well. 

I have been able to find a setting for this and I am wondering if there is any way to achieve it.  If you know of a way to do this let me know as I would love to hear it.  If I do get an answer on this I’ll update the post accordingly.

Sunday, February 27, 2011

Dear vividwireless from a want to be customer

Earlier today I sent this email to vividwireless and I will be interested to see what their response is.  I have posted it hear so that others can think about it and comment if they like.

Dear vividwireless,

First of all let me start by saying that your product offering is very tempting and you appear to offer some excellent services. The only sticking point for me is the credit expiry for your prepaid offering. Let me explain:

I have excellent ADSL2 broadband at home with 150GBs of download per month, my house is also outside of your coverage area so even if the speed of your service was better than my home line I couldn’t change over (if the speed was just as good and I had coverage your unlimited plan would be extremely tempting).

All of that to say that vividwireless would not be my primary connection, however I have to do a bit of travel for work and quite often my travels take me to places that you do have coverage in. When I am staying at hotels it would be very handy for me to have one of your wifi hotspots with me. The trouble is I also sometimes travel in areas where you don’t have coverage and for those places I use a Telstra Next G USB modem. Telstra have coverage in pretty much all of the places you do and a whole lot more to boot. However you have a better connection so when I am in an area you do service I would prefer to use your connection. This brings me to the dilemma. If I buy prepaid credit from you it will most likely expire before I use it all. I understand how that is good for you, but it isn’t good for me.

At the moment I purchase $150 of credit from Telstra which lasts for 365 days. This means I don’t have to worry too much about wasting half of my credit due to it expiring on me before I use it all. If I purchase $150 of credit from you it only lasts 180 days so there is a high chance that I will not have used it all before it expires as I don’t need it the majority of the time. Even if recharging before it expires will extend the time on my credit you are essentially asking me to pay $25 per month for something I don’t use all that often, but would like to use when I need to.

If you removed the expiry from your credit or at the very least made it last for a year no matter how much I recharge with, then I would sign up right now, but as it is I will just stick with Telstra. So instead of you getting some of the money I give to them you will get none of it as I can’t afford the extra $25 a month for something I might not use very much. I imagine that I am not the only one in this situation and that by changing things you could make that a key selling point and appeal to larger market.

I think you guys are doing very well so far and are offering an excellent service (from the feedback I have heard from friends) and are breathing some fresh air into the stuffy telecommunications sector, but I think you can do even better. Think outside the box a little more and ditch the credit expiry and you will remove all reasons for someone not to buy your product.


Caleb Vear

Saturday, February 19, 2011

Put your behaviour where it belongs

This past week I have been working on a feature which allows the application to record the net weight of a various loads on a shipment.  There are of course certain rules which control whether a weight can be accepted or not and other side affects to accepting a weight, such as setting the date and time the weight was accepted.  All of this should of course be controlled by my domain classes, but how often have you seen code that looks something like this:

I must confess I have been guilty of writing code like that my self, but I have learned a lot since then and I now know that this can be done better.  Too often we fall into the trap of making our domain objects just a place to hold our data.  If we do this we wind up having our core business logic and behaviours strewn all over our application.  More and more I tend to favour having private or protected setters for all my properties.  Then the only way to make changes is by calling methods which model the actions that the users actually want to perform.  In my shipping example they are accepting the weight, they aren’t just setting it.  Accepting the weight is a core business concept and it has rules which apply.  My code now looks more like this instead, which in my opinion is a vast improvement:

Your methods for changing domain states should be verbs that the business would use to describe the action that is actually taking place.  Going back to my shipping example a Weight is made up of multiple Weighs.  This is because sometimes a truck is too long to fit on a weighbridge so they need multiple readings.  They describe the process as capturing a weigh, so my method is called CaptureWeigh(decimal reading, CaptureType captureType).  There are rules when capturing a weigh which are applied in that method.  Typically though a lot of code would just add the reading to a collection provided through a property on the Weight class, but that removes the chance to have the business behaviour captured in the object that represents it in your model.
When modelling your domain this way you will find that nearly all of your collections shouldn’t be exposed as IList<T> because you want to control what happens when you add something to them.  Rather than exposing IList<T> use IEnumerable<T>.  If you need to get the count you can just use the Count() extension method, if the instance you call Count() on is an IList then it will actually just return straight away without looping through the entire sequence.  I still return the underlying IList<T> from my IEnumerable<T> property even though I don’t want people to modify it.  I realise that that means they can cast it and then make changes, but the fact that I am IEnumerable<T> means they should know that isn’t a supported scenario.  If they want to ignore that and muck with it anyway then that is their problem.  I have seen people advocate wrapping the underlying list in a ReadOnlyCollection<T> instance to prevent modification, but I feel this is overkill.  After all at the end of the day I can’t stop people from accessing the list anyway as they can always use reflection and if they are going to use things in ways that the interface clearly shows isn’t supported then good luck to them and if it blows up in their faces that is their problem!