A few weeks ago, the new VS2010 beta was released, including a long-awaited upgrade of WPF, which enables features like the Visual State Manager for WPF.  Next to that, a beta of Silverlight 4 was released at PDC last week, which – amongst others – enables SL Out of Browser to run in a trusted environment, thus enabling it to access (parts of) the local file system and COM interop.

From that moment on, the internet has been buzzing with questions and concerns about when one should use WPF and when SL when building a rich app using the Microsoft stack.  On ZDNET, an article appeared which stated that everything would be rebranded to Silverlight – so the term “WPF” will be obsolete in the (near?) future.  We’ll just have different subsets of Silverlight.  How this is going to be implemented remains to be seen.  This is what the article has to say about that:

Some day — Microsoft won’t say exactly when — Silverlight and WPF are going to merge into one Web programming and app delivery model that, most likely, will be known as Silverlight, Brad Becker, Director of Product Management for Microsoft’s Rich Client Platforms, told me this week at TechEd. Now that the two share the same compiled assemblies, tools and the like, that idea isn’t really so far-fetched.

 

So, what do you do when you want to decide on using WPF or SL for an application?  That’s probably a question a lot of people are asking themselves at the moment – this question for sure sparked some heated but very interesting discussions at my company. :-)

Just stating “WPF for desktop clients, SL for web clients” doesn’t cut it anymore now that SL can run on the desktop, even on Mac, trusted.  It even provides you with a very, very easy upgrade model (simplified: update the XAP on the webserver, and all clients, even the OOB installed ones, will be updated automatically). 

Some business requirements automatically make the choice for you: need WS security standards?  Use WPF.  Need heavy 3D graphics?  Use WPF.  Need full local file system access?  Use WPF.  Do not try to get Silverlight to behave as a WPF client by using workarounds – if you need a workaround to get something done that’s included out of the box in WPF, it’s probably better to just use WPF.

Next to that, I – personally, not necessarily my company’s view – would use Silverlight, even for desktop applications.  Why?  Well, that’s more a matter of how I think applications will/should evolve than anything else. 

Let’s elaborate on that a bit.  It’s clear that the division between the online and offline worlds is fading.  People want to be able to access their applications and data anytime, from everywhere.  Silverlight is already a nice fit in this model: it runs in the browser and on the desktop when needed.  We can now develop an application that can easily be installed locally or accessed through the browser, without actually having to develop 2 separate applications.  And if you absolutely need two separate apps, one which has more features than the other, you could share most if not all your code.

Now, back to the “rebranding of WPF to SL”.  I’m hoping that Microsoft, won’t just rebrand this, but that they’ll go for a new, truly pluggable model.  At the project start, you should decide what requirements your application needs, and depending on those requirements, certain features will be enabled or disabled.  The Silverlight Core CLR could be the base feature set (so: no more differences in XAML markup/features between SL and WPF), and if you need more functionality, your project should just reference the necessary assemblies, which would then be included in the XAP (of course, assembly caching and XAP shrinking should be used here). 

This would allow for true plugability: does your application need to comply to the WS standards?  Reference the necessary assemblies, and it will.  Does your application need full access to the local file system?  Reference the necessary assemblies, and it will, but it will of course disable some features in the online version of your app. 

In a sense, what I’m aiming for is not plugability of certain features, and not just a few different sets of the .NET framework to choose from, but the ability to be able to plug in parts of the .NET framework when needed – much like you plug in third party controls.  One base framework (based on SL’s Core CLR), and a pluggable model for all the other namespaces.   Something to think about?

A while ago, we were busy developing custom controls for Silverlight (2 at the time).  One of those controls was a Wizard control, which in turn consisted of a list of another custom control, the WizardSlide.  Obviously, this list was implemented as a Dependency Property “WizardSlides” (collection of WizardSlide) on the Wizard control. 

However, after some testing, I noticed some pretty strange behaviour: everything worked quite fine when only one instance of the Wizard control was used in our application, but from the moment on we started using multiple instances, the WizardSlides-collection property seemed to behave itself as if it were defined on the class instead of on the instance of the class.  All of a sudden, we were able to access the combined WizardSlides of instances 1 & 2 through the WizardSlides property on either of the Wizard instances.  To make matters even more strange, this didn’t happen if the collection property contained a simple type (like string or int), but it did happen when it contained a UIElement (or derived) type (like the WizardSlide control). 

We tried lots of different approaches to solve this problem, searched the internet, posted questions on the Silverlight forum, but to no avail: no-one could explain why this happened nor offer a solution, and we finally opted for a less-than-ideal approach, constricting the number of WizardSlides to 8 instead of having a dynamic collection.

Last week, I was helping out one of our clients with their Silverlight application.  An application which uses custom controls.  One of which contained a collection that seemed to behave as a singleton instead of on an instance level…  I remembered the problems I faced with this before, already thinking we wouldn’t find a solution to keep this collection dynamic.  However, I started searching around again, and lo and behold, it wasn’t long before I found this page on MSDN, describing the exact problem we were facing AND offering a reason and solution.  I am, by the way, 100% sure this page wasn’t there last year ;-)

Apparently, what’s happening is this: when you create a dependency property, it gets its default value through the dependency property metadata you define.  If that property is a reference type, this default value isn’t a default value per instance, it is a default value that applies to all instances of the type.  This means that when using the collection defined by the collection property metadata (which is singular/static!) as the default value for new instances, your collection dependency property is actually referring to that singular collection, and is thus accessible through any instance of your control!

Interesting, no? :)  What’s even more interesting is that there is a very, very easy to solve this: to make sure your collection property isn’t shared between all instances of your control, reset the property value to a unique instance as part of the class constructor call.  In the Wizard control with a WizardSlides collection, this looks as such:

public Wizard() : base()
{
     //... other constructor tasks

     SetValue(WizardSlides, new ObservableCollection<WizardSlide>());
}

Hope this helps some of you out! :)

In the next few weeks, I’ll be speaking at a few events.

• Tuesday November 17th: RIA Evening Seminar @ KHM

I’ll be speaking about Rich (Internet) Applications, mainly focussing on Silverlight. In this 90 minute session. I’ll talk about the “why” and “what” of rich applications, and show off a few of the features that make Silverlight stand out.

Location: Katholieke Hogeschool Mechelen (website)

• Wednesday November 25th: Microsoft User Experince @ Vitra
  
  For the second time, Microsoft is organizing this event together with Vitra & partners.  This event is aimed at developers & decision makers, and consists of in depth sessions on Sharepoint, Silverlight, WPF and Sketchflow in the afternoon (@ MS Corporate Village, Zaventem), and short introduction sessions in the evening (@ Vitra showroom, Diegem).  I’ll be presenting the Silverlight session: this is a 45 minute session, repeated throughout the afternoon.  In this session, I’ll talk about Silverlight 3 & its new features.

Don’t hesitate to say hello if you see me! :)