As a very small group of people might have noticed, my blog has been more or less dead for the last couple of weeks…or months to be honest… The reason for this is that I have had a bit to do as I have packed up my life in New Zealand and moved back to Sweden. This is a little bit more time consuming that you’d expect, so I have had to move my focus away from certain things. And unfortunately, my blog was one of the things I had to axe.
The move back to Sweden did however make me think about localization, as building apps in Sweden often means adding at least 2 languages, Swedish and English. The topic has been in the back of my mind for a long time, but I never really settled on a good way to handle the whole thing. However, at this point in time, I felt that I really had to come up with some options. And with the introduction of a specific feature in Silverlight 5 called markup extensions, I felt that it might be time to have a look at it.
I really tried not to write this post. A lot of other Silverlight devs have already written it so I shouldn't, but I have had enough… I have finally got asked about the death of Silverlight so many times that is has pushed me over the edge…
Silverlight isn’t dead… It isn’t dying… It isn’t about to be killed…
How do I know this? Well, except for some of the information I am hearing from Microsoft about it, it doesn’t make sense… It makes no sense at all!
Ok, so in my last post, I gave a brief introduction to WCF for the complete n00b. As a follow up to this, I would like to have a look at some different ways to consume these services.
The “normal” way to do it is obviously by adding a service reference to the project in VS, but there are alternatives that can make sense.
The samples I am going to use are specifically for Silverlight as they focus on simple bindings and features that Silverlight supports, but it can still be used for any .NET client.
Ok…So I am more of a general .NET and Silverlight developer, but it is hard to get around the fact that WCF infiltrates most of the projects I ever work on. And after having read a substantial part of Juval Löwy’s book about WCF, I have realized that there was a lot that I didn’t know and didn’t fully understand. Not that I am saying that I get it all now, but I have a better understanding at least.
The thing is that WCF isn’t really very hard in most cases, but having a basic understanding makes it a lot easier. And to be honest, the basics will take you a long way when working with Silverlight, since Silverlight doesn’t support a lot of the more advanced features. To be honest, the WCF support in Silverlight is fairly basic, but it is enough…
So based on this, I thought I would try and write a down to earth and simple introduction to the main concepts in WCF.
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…
Earlier this week, I had the pleasure of presenting at the NZALM conference here in Wellington. Even though it was an ALM/Visual Studio conference, there was a “lot” of MVVM talk.
I did one intro session called “MVVM – The Naked Truth” and one deeper one called “MVVM – Going Beyond Hello World”. Both sessions went well according to me, but on the other hand I might be a bit biased… Hopefully the attending people would agree with me, but you never know.
As part of the talks, I did both write and show some pre-written code that I promised to put up here on my blog. So here it is:
MVVM - The Naked Truth.zip (18.88 kb)
MVVM - Going Beyond Hello World.zip (333.08 kb)
I also mentioned another blog post that would contain even more code samples. And since the search functionality on my blog for some reason is broken (I think it has to do with a new engine version with old theme…), I thought I would link to it from here instead. So here it is: https://chris.59north.com/post/SLAMD-session-code.aspx
If you have any questions about the code, just give me a yell or drop a comment and I will help out as much as I can!
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.
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 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…
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…
Ok, so Silverlight is a very cool technology, and Microsoft has done a whole lot of things to make sure that it performs the way it should. They have done things like forcing you to run long running tasks, such as webservice calls, in an asynchronous fashion. But if you start doing long running tasks on your own, you need to make sure to handle the multithreading yourself. Why? Well, if you don’t, you will perform all of that stuff on the UI thread.
And why is performing heavy things on the UI thread a bad thing? Well…it just is!