During my MVVM presentation yesterday, I promised to upload the code to my blog. So here it is! Go ahead and run the application, put some breakpoints in there and see what is actually happening. It should give you a good baseline for a simple, and small “pay for play” MVVM framework. And if you have any questions, Just ask them in the comments, or via e-mail or Twitter…
Download: FiftyNine.MVVM.zip (517.57 kb)
When working with Silverlight, we often end up communicating with some form of services. They might be SOAP-based WCF services, which Silverlight handles fine, but lately REST-like services have become a lot more popular, and Silverlight doesn’t always handle them as nicely… They often rely on headers and HTTP verbs other than GET and POST, which Silverlight doesn’t handle very well by default.
In my world, I am currently spending a lot of time working with a Silverlight client that is used in a situation where we use federated security. This requires the client to carry around a token that tells the service who he/she is, and what claims are being made.
In this case, we are using the thinktecture IdentityServer, which after a bit of configuration works very well. It makes it very easy to integrate with using Silverlight, which is nice. All you need to do is do is to make an HTTP GET call to the identity server, passing along the credentials in the form of a basic authentication header. The identity server in turn replies with a token that identifies the client (at least if the credentials are valid). The client can then POST that token to the the service (relying party) who will then use that token to authenticate the client. And after that, everyone is happy, and the service can trust the client being who he/she says he/she is…
More...
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!
More...
20. December 2008
ZeroKoll
Silverlight
A couple of the guys at my company have started working on an internal Silverlight application. One of the guys is a former WPF developer, which gives him some serious advantages when starting with Silverlight. It actually gives him some serious advantages compared to my own sorry ass as well. However, it has some downsides as well. Downsides that sometimes end up with him sending me annoyed MSN messages.
He expects a bunch of WPF specific features to be available in Silverlight. I understand the "confusing". SIlverlight development is very close to WPF, except for the fact that Silverlight is in some aspects is tiny compared to WPF.
More...