Silverlight »

[13 Nov 2008 | 0 Comments]

One of the things you'll notice when you start writing Silverlight applications is that you cannot call a service synchronously anymore, as you could in, for example, a typical ASP .NET WebApp.  In Silverlight, everything is async by default - which means you won't have a GUI that hangs, for example.  Great, right?  That's what I thought as well.

But: you'll have to change the way you used to think about your programming model.  If you don't, and if you keep thinking about it as you did before, you'll run into quite a few possible problems.

A little example: a certain project I've been working on consists of generating a Silverlight GUI based on an XML, which will typically result in some kind of questionairre, with lots of panels (which represent a step in the questionairre), dropdowns, checkboxes to tick and untick, fields to fill out, et cetera.  Some of these checkboxes and fields require some kind of validation or rule: if you check one checkbox, other checkboxes must be enabled/disabled, or certain text fields must be filled out.  So we wrote some rules.  Some of the text fields that must be filled out must have values that are of a certain type, or are in a certain range - so we wrote some validators.  Other textfields must have a value that corresponds to a database value, before you can continue to the next step. So we ... got stuck!

Problem: we used to validate our fields when clicking the "next"-button to go to the next step.  Worked flawlessly, untill we ran into the database validators: these call services which check a field value against a value in the database.  Easy way out: call the service synchronously, and only continue with the other checks once you get a returnvalue.  But Silverlight doesn't allow a service to be called synchronously... and when calling the service async, there's no easy way of "blocking" the program flow 'till we get something back from our service call.  Or is there?

Well... there are certain techniques some people try to apply to get their async service to behave as if it were sync, like toying with some threading options, using ManualResetEvents, or other "smart" tricks.

One simple word of advice: don't.

None of them really work, and they all come down to one thing: your application architecture/model is wrong.  Or better: it's not in touch with the way modern applications are designed - or should be designed.

Don't get me wrong - I've been programming synchronously for years, as have most people, so I do understand the challenges you'll face when this isn't an option anymore.  But don't try to get an async service to behave sync - you will fail, and if you don't, you'll end up with bulk, unnecessary code.  Change the way you think, change your architecture, so it fits the async programming model.  This is ALWAYS possible.  It will require some effort, but you will succeed, and in return, you'll get an application that not only works as the language you program in has intended, but at the same time is ready for the future, AND stays responsive.  Better yet: think AHEAD.

To get back to my little validation problem: instead of trying to incorporate some kind of "waiting"-behaviour for my validation, we turned the model around.  A value isn't valid by default anymore, it's invalid by default; my database validation services can now run async, and the value will become valid (if it is) when the async call returns.  Only when everything is valid, the user is able to continue with the next step.  And because a value is invalid by default, the user can never continue to the next step untill all async database validation service calls are completed.  One little (well...) change, a world of difference.


To end this post with a really stupid one-liner: the future is async, get used to it. ;-)

Silverlight »

[24 Jun 2008 | 0 Comments]

For those of you who have been living under a rock for the last few weeks: Silverlight 2 beta 2 has been released!

I must say though: I wasn't that impressed at first. Not enough new stuff, not the controls I wanted, quite a few bugs, ... but I got to know the new features better, and, well, I'm slightly impressed now. I'm not going to document all the new features here (lots of sites do that already) - just the ones that stand out, for me.

Let's start with the "bad": only one new control (the tabControl)? Still only basicHttpBinding in WCF? I was at least expecting a simple ComboBox...

... on to the "good". I've only got one word for you: VisualStateManager! What a wonderful addition - no more coding&running animations from codebehind for simple state changes - once you get used to it (and it's quite straightforward), you'll be convinced this is a real time-saver!

Silverlight 2 is still beta software, so you can expect to encounter quite a few bugs. Here are a few I've encountered, including solutions - hope it helps some of you out!

1) When using the VisualStateManager, you might notice Visual Studio will give you an error on the line "": 'The attachable property 'VisualStateGroups' was not found in type 'VisualStateManager''. This code is, btw, generated by Blend - it should work.

And it does :-) It's just that Visual Studio thinks it doesn't.

Solution: try building your app, it just might work. And if it doesn't (and fails to build due to this specific error), close the file containing the VisualStateManager-syntax. Your app will build&run.

2) After some heavy switching between Blend & VS, I noticed that, when running my app, the latest version wasn't what was being shown. (Re)building with F5 just started an older version of my app, ignoring my recent changes (even after cleaning the complete solution). I've had this happen quite a few times already...

Solution: right-click your SL-app > Debug > Start new instance. The latest version of your app will build&run. Another way to make this work is changing the port of the development webserver.

3) WCF calls are giving me headaches! I made a very, very simple application: SL client calling a WCF service from a ServiceHost. Added crossdomain.xml, added reference via VS, it automatically created the necessary config-files, all very easy. But: calling my WCF service kept on giving me 404-errors... I checked and rechecked everything: the binding was correct (basicHttpBinding), the service was running correctly (I could access it, view the WSDL, ...), the automatically created ClientConfig-file was correct, everything looked ok.

So... I tried exactly the same in SL2B1, just to make sure I wasn't missing something - but in beta1, everything worked as you'd expect it to.

Solution: well, apparently there are quite a few issues with WCF calls and SL2B2. Ranging from failed installs to wrong config-files to wrong bindings to... But in my case, the problem was situated on the crossdomain.xml-file. After reading through a few posts on the Silverlight.NET-forums (this post and this post were very helpful - check 'em out if you're having WCF issues), I decided to try and change the crossdomain.xml-file to a clientaccesspolicy.xml-file (for the correct xml, see this post). After this, my service call worked flawlessly!

I'm absolutely positive my crossdomain.xml-file is ok, but apparently beta2 has some issues with it. So, if you're have problems with WCF service calls from SL, and you're using a crossdomain.xml-file, try using a clientaccesspolicy.xml-file instead.

Happy coding/designing!