Ok, it has been a while since I posted now, but there has been a too much going on, and I guess I should be blogging about Silverlight 5, as it is on the agenda for MIX. I have even had the possibility to early access to the Silverlight 5 bits, but I have had too much to do to come up with some good posts about it. That is not to say that there isn’t a huge amount of really good stuff in the next release! But besides not having had time to play with it, I am not allowed to blog about it until it is actually available…
But, in the mean time, I thought I would do a quick post about a little feature that I am not seeing a lot of people using. It is nothing ground breaking, or even very necessary, but still helpful. I am talking about the ability to declare custom Xml namspaces to your assemblies…
More...
Ok, so this post is definitely going down in the books as “why would you do that” for a lot of people, but it actually has its benefits in some cases. What I want to show, is how we can work with WCF services and service interfaces without having to add a service reference to Visual Studio and instead auto generate the required code using T4 templates…
So why would I want to do that? Well, in some cases it is kind of tedious and even complicated to spin up the service just to be able to update the service reference and in some cases it isn’t even possible to get access to the WSDL that is required to create it. And in those cases, this will help you… In my case, the services and service contracts are built by one dev, and the Silverlight stuff by me. To us, this way of working makes it a lot easier to handle changes to the service contracts as we go along… I can get changes by just checking out the changed interfaces without having to try and get my solution into a state where I can update my service reference.
More...
I am currently working on a little thing in Silverlight and came across an interesting “feature”. The thing I am working on requires me to dynamically create types based on strings in a configuration file, and for this purpose, I created a simple TypeConverter called TypeTypeConverter. It is a very simple converter that takes a string and converts it to a Type. So I created a very simple implementation that looks like this
public class TypeTypeConverter : TypeConverter
{
public override bool CanConvertFrom(ITypeDescriptorContext context, System.Type sourceType)
{
if (sourceType == typeof(string))
{
return true;
}
return base.CanConvertFrom(context, sourceType);
}
public override object ConvertFrom(ITypeDescriptorContext context, System.Globalization.CultureInfo culture, object value)
{
if (value is string)
{
return Type.GetType((string)value, true);
}
return base.ConvertFrom(context, culture, value);
}
}
As you can see, it is probably a little TOO simple as it doesn’t handle errors at all. But to be honest, in my case it is actually a bit by design.
So why does this simple little thing end up on my blog? Well, because it failed… Not the code as such, but the thing I was trying to do…
More...
Ok, so MVVM is obviously about Unit testing right? Well, I don’t really agree, but it is definitely a part of why you chose MVVM, even if it is only a small part of the reason for me. I have been using the MVVM pattern for a while now, but I still haven’t started unit testing my code properly. I know I should, but for different reasons I never get around to it. Mostly due to time constraints.
And for all of you that tell me that writing unit tests will not take more time as there will be less bugs to fix, bug off! It does take time. It does include mocking or stubbing services. It does take time to figure out how to write useful tests. And first and foremost, it takes time to get the experience needed to do it fast… So argument ignored!
What I do do though though, is keeping it in my mind when I design my VMs. I always consider whether or no the VM is testable. If it is, then I know that I haven’t introduced any dependencies that I shouldn’t have. And even if it isn’t a fool proof way of limiting dependencies, it does help me…
More...