What's New in Silverlight 3 Demo Source Code

Contains the source code for the demos from the What's New in Silverlight 3 presentation

Design 101 – The Color Wheel

One of the most common comments from Silverlight and WPF developers is their lack of design sense. Over the next little while, I’ll be posting (interspersed with other topics) on some of the basics of color theory and how they can be applied to WPF and Silverlight.

To start with, let’s talk about one of the fundamental artifacts of color theory – the color wheel.

Color WheelOriginally conceived by Sir Isaac Newton, color wheel is a representation of the colors in the visual spectrum. In the representation, the three primary colors are placed equidistant from one another. The gaps between the the primary colors is then filled with with secondary and tertiary colors.

Now, already I’ve used three terms, only one of which I would expect you to be familiar with. Primary colors (red, blue and yellow) are something that we learned about in elementary school. Secondary colors (orange, green and violet) are created by combining the primary colors. Tertiary colors are those that are formed by combining primary colors with secondary colors.

So now that we have a color wheel, what good is it? Well, it helps identify harmonious colors. When selecting colors to use in a user interface, it is important so select colors that are, in combination, pleasing to the eye. Personally, I understand the challenge to this. As a person born without the color sense gene, I think that pink and lime green go well together. But apparently, I’m in the minority. :)

There are numerous theories about the combinations of colors that promote harmony. We’ll look at some of them in more detail in upcoming blog entries, but to give you a second, two of the most commonly used ones are complimentary and analogous. Complimentary colors are found opposite one another on the wheel. For example, red-green, yellow-violet, and blue-orange are all complimentary. These colors promote stability and contrast in the image.

Analogous colors are sets of three colors that are adjacent to one another on the color wheel. In images using analogous colors, one of the colors tends to be the dominant one. The result is an image that appears to be saturated in the dominant color with the other colors offering a subtle nuances of difference.

Where does Off-Browser Silverlight Run?

Off-browser Silverlight is pretty cool. And one of the first questions that got raised is ‘where is it running’. Obviously, it’s not running within the browser. I mean, duh. But if not there, then where?

I got the first inkling of an answer listening to Mike Harsh’s presentation on off-browser Silverlight at MIX ‘09 (slides, demos and video can be found on his blog). Actually, it wasn’t his presentation, per se, but his answering of questions afterwards. I actually give Mike props for doing this presentation. Off-browser Silverlight is very easy to configure and use. It’s difficult to find 60 minutes worth of content when the user experience is ‘right-click to install…right-click again to uninstall’ and the developer experience is ‘check a box in the property sheet’. But from his easy handling of the questions afterwards, it’s pretty obvious that he knows the topic well.

One of the post presentation questions Mike was asked was related to the ‘how’ of off-browser Silverlight. Mike intimated that, basically, the Browser control was used. In other words, when installed on a client’s machine, launching the Silverlight application actually launches an application which hosts the Browser control. The Browser control then hosts the Silverlight application.

As it turns out, this is “basically” true. For the Windows platform, it’s precisely true. From Chris Hayak, the application which is launched is called SLLauncher.exe. This is also the application to which you will attach if you want to debug Silverlight apps in off-browser mode. For the Mac platform, the SLLauncher application runs webkit, which in turn hosts the Silverlight application.

The one downside of this approach is that, at least during the beta, there is no way to distinguish between multiple, simultaneous off-browser Silverlight apps. They all appear in the process list as ‘sllauncher.exe’. Hopefully this will change before SL3 goes gold.

Is WPF Dead?

One of the first questions that arose from the announcement of off-browser Silverlight was “What will happen to WPF?” The obvious source of this concern is that since Silverlight 3 can run either as part of a Web page or installed in an off-browser mode, why would there ever be a reason to write a WPF application? And since Silverlight seems to be the technology that has all of the new features, is there a possibility that WPF could languish as the ugly step child in the client application development world ?

First, let me assuage your concerns. WPF is not dead. This opinion is based on a couple of on-going development projects at Microsoft: Expression Blend/Design and Visual Studio. In the case of Expression Blend/Design, the entire application was written in WPF. For Visual Studio, the code editors are being re-written in WPF. If nothing else, the investment being made by Microsoft to these products in WPF should demonstrate its on-going commitment to the technology. And there is the on-going integration of WPF into the Live Messenger client to add more fuel to the argument.

Going forward, I see WPF and Silverlight moving ahead more or less in lock-step. Features in Silverlight that are successful will find their way into WPF (Visual State Manager, for example). Features in WPF that are useful will move into Silverlight (element binding, based-on styles). Since the products have different audiences, each technology will be driven forward with a different set of priorities. VB.NET and C# already have this So don’t give up on WPF because of all of the excitement from Silverlight. As a WPF developer, I found some of the excitement generated by Silverlight announcements a little odd (applause for element-to-element binding? WPF has had that for a while now). What playing with Silverlight 3 that I have done so far suggests that the disparity between the two features sets is going to be much less in the future.

That having been said, there is still the open question of when WPF should be used instead of Silverlight 3. I can see three main cases at a minimum, but they all revolve around the same restriction in Silverlight…the security sandbox.

Access to local system resources

Off-browser Silverlight runs in the same security context as on-browser Silverlight. So if your application needs access to the local file system or the communication ports on the client machine, then Silverlight is not going to work out. In fact, this limitation can be extended in include any feature that requires full-trust to operation. Silverlight doesn’t work in full-trust mode. WPF can.

Full 3-D graphics capabilities

With Silverlight 3, perspective 3-D is available. But that is not the same as the complete 3-D capabilities that WPF has. It’s nice, but if you’re looking for fully rotational 3-D images, then WPF is the choice.

Semi-Esoteric Functionality

There are instances where Silverlight is missing functionality that is available in WPF. For example, there is no Closing event for a Silverlight application. This means that you can’t stop a user from closing an application when the current record has been modified but not saved. In on-browser Silverlight, a JavaScript hack can be used to emulate this feature. But in off-browser Silverlight, there is no JavaScript available, so no Closing event can be detected. While might seem like an edge case, the functionality offered by Closing is part of most LOB application. So it might not be such a small deal as you might originally think.

I’m sure there are more differences. It’s not like WPF is not a compelling choice for a development platform. In fact, I approach the choice between the two the same way I would between WinForms and ASP.NET. Because ultimately, the decision between Silverlight and WPF will be based on the specific requirements of a project. If Silverlight (either on- or off-browser) is sufficient, then pick Silverlight. If not, then pick WPF. Regardless of your choice, you’re not in danger of dead-ending with the technology. Both areas will flourish and grow for many years to come.

Consuming WCF in Silverlight 3 Session at MIX ‘09

This session covers three separate scenarios for Silverlight and WCF interactions. The basic functionality of adding a service reference, creating proxy class and calling method hasn’t changed. However, they are trying to address some of the common pain points related to WCF

It’s now possible to remove the network traffic associated with ‘fat’ SOAP/XML messages by using a binary XML format to send the message. The demo reduced message size by 30%. But size was not the main design goal for binary XML. While compression is possible at the HTTP level, apparently binary XML reduces effort on the client and server as messages are compressed and decompressed. Binary XML is intended to improve speed. And while not every message is affected significantly (small messages and strings don’t really benefit), there is no case that MS is aware of where it gets worse. So binary XML becomes an appropriate default formatting standard.

Also included in this section was a description of why server-side error information is not accessible from within Silverlight. Specifically, if you have a server-side HTTP 500 code, the information related to the error does not get pushed to Silverlight. This is a fairly hard limitation related to how browsers pass HTTP information to plug-ins. And Silverlight is really a plug-in. The solution is an HTTP hack, there internal server errors get returned as HTTP 200 codes. And Silverlight 3 is built to pull the error information off of the response and surface it through the normal SOAP faulting mechanism.

When it comes to security WCF calls in Silverlight 3, there are two choices: browser-based and manual. The browser-based approach depends on cookies and Forms authentication at the browser level. This is easy to implement, but is open to cross-domain threats IF you have enable cross-domain access for every Web site. The manual approach has identity managed by Silverlight. When the credentials are added by Silverlight (instead of the browser), the cross-domain thread is eliminated. SL3 provides an out-of-the-box mechanism for creating the SOAP headers associated with the manual mechanism. It’s the ‘out-of-the-box’ that is new in SL3, not the technique itself.

The big gotcha in the manual mode is found in the method that WCF uses to prevent replay attacks. There is the concept of a MaxClockSkew. In indicates how far apart the client and server clocks can be. The default value if 5 minutes. which is to say that if the server system has a time of 11:05 and the client system has a time of 11:11, all messages will be rejected. This is the kind of situation that I’m sure will bedevil developers. MS is still trying to decide what the default value of MaxClockSkew will be when SL3 is released.

The second scenario covered in this session involved pushing messages to Silverlight. It was possible in SL2 to push message to the Silverlight application, but the knowledge required by the developer to implement it has been reduced. Because I’m very familiar with WCF, the technique does not seem advanced. Basically, the idea is to have the SL3 client make a one-way WCF call with a callback contract. The OneWay mode means that there is no calling context hanging around on the client. The callback allows the service to call back to the Silverlight application. In the Silverlight application, there is an event raised when the callback method is invoked from the service.

The third and final scenario talked about REST in Silverlight 3. As it turns out, SL3 doesn’t have much added in this area. Mostly because “the REST story in SL2 was pretty complete” This is actually pretty true about WCF in Silverlight in general. It’s not that there aren’t things that people would like to do with WCF in Silverlight (different bindings, for example). But the reality is that the limiting factor for most new feature requests is the HTTP stack from within the browser. It was mentioned that it’s possible to roll your own HTTP stack by going out to JavaScript through the HTTP DOM, but that technique will probably not work if the Silverlight application is running on off-browser mode.

Off-line and Off-Browser Silverlight

The big announcement at yesterday’s keynote was the availability of an off-line and off-browser mode for Silverlight 3.0. Just to clarify the terms, off-line mode indicates that Silverlight will not require a live connection to the Internet in order to continue functioning. Practically, this means that a Silverlight application will able to be installed on the client’s computer. Off-browser means that Silverlight apps will no longer appear to need to be running within any browser.

As a point of clarification, this last feature doesn’t mean that Silverlight will have free reign over your computer. Off-browser Silverlight apps will still run in the same security sandbox that they have in the browser. It’s just that you won’t need to explicitly launch the browser to start the application. In fact, the installation process for the Silverlight application includes the ability to place links on the desktop on the system tray

So what are the ramifications of these changes?

First, it opens up a world for Silverlight applications. While I’m a huge fan of WPF, there are a number of roadblocks to wide acceptance. It needs to have the .NET Framework installed (3.5 or 3.0). Which, in itself, implies a Windows platform (according to the Mono project, they are not planning to support WPF). Full WPF applications need to be installed. Yes, you can use XBAP to deploy the application, but that model has implications on security (it runs in the browser-driven security sandbox).

Silverlight, on the other hand, runs on both Windows and Mac. And while it requires an installation step, to call it an install is really overkill. It’s basically an XCOPY from one place to another on the client’s system. The conclusion, though, is that WPF and off-browser Silverlight do hit different target markets.

The second question is how does it change your Silverlight development process.

The goal of off-browser Silverlight was to have the same application run in both modes. And it certainly appears that is the case. However, being able to run the same application off-line and on-line does have an impact on your approach to development. For example, UI pieces might be different. The ability to retrieve data for a combo box, for example, might depend on being able to call out to a WCF service. That isn’t happening in off-line mode (although it would if you were just off-browser). So to create a solid off-line scenario, you may need to provide additional functionality or enable/disable functionality that is currently in place. This is not an insurmountable problem, but it does require some care and design effort.

All in all, off-browser/off-line Silverlight is an interesting idea and I’m looking forward to not only working on apps in this space, but also to see how others take advantage of it. Exciting times indeed.

Having an Out-of-Browser Silverlight Experience

The fundamental philosophy used to develop the off-browser functionality for Silverlight applications was to reduce the friction surrounding the moving of the application from in-browser to out-of-browser. Specifically, there is no separate download that is required to take a Silverlight application off-line. As a developer, you need to make a change to the manifest to support installation, but nothing more than that. And because the off-browser application runs in the same sandbox as the in-browser application, there are also no security warning messages on installation.

From the user’s perspective, there are two methods to take the application off-browser. The first is the right click on the application. A second option (besides the Silverlight Configuration that has always been there) is visible to indicates that the application to be installed. Also, it is possible to place a button on the application that will install the application.

The manifest is where most of the information used in the installation exists. The name, description and icons related to the application are stored there, along with the flag indicating whether the application can be taken off-browser.

Updating the Silverlight application is exactly the same as the traditional Silverlight application. Which is to say that updates are downloaded and installed automatically. This keeps it consistent with the Silverlight model, where new versions are automatically picked up. The biggest difference is that once a new version is detected and downloaded, the Silverlight application does not automatically terminate and start running the new version. It waits until the next time that the application starts before launching the new version.

Warning – in the beta version, there appears to be a bug associated with updating from your localhost. In the words of the Silverlight PM, it’s a little flaky.

In terms of interacting with the client, an off-browser Silverlight app still has access to the Insolated store. And through the OpenFile and SaveFile dialogs, access to the local file system. There is  a quota on isolated storage, but it is increased to 25MB from it’s current size of 1MB. That’s nice and probably sufficient for most applications.

There are still a number of open questions about off-browser Silverlight applications. Is there an event raised when the application is closed (this is done through Javascript in normal Silverlight applications)? Is there a mechanism that simplifies serialization and synchronization? Should there be a way to uninstall the application other than by right-clicking on it (what if the app can’t load)? I’m sure time and the need to make this work in the real world will provide answers.

MIX ‘09 Keynote – Part 2

More stuff on the Web server side of the equation. There is a new version of the Web Platform Installer. This doesn’t have any impact on me, at least not in the past. But there is now a gallery of community-based applications, such as DotNetNuke, DasBlog and WordPress that can be automatically installed onto a web server through the Platform Installer. Not useful to me, but nice to people who are trying to streamline the build-out of a Web server. You can see a list of these applications here.

Silverlight 3.0 has some new functionality to improve functionality. There will be hardware-based acceleration for compositing, where available. And there are a number of features aimed at improving the media experience. A gentleman from NBC came out and showed some stats on the Beijing Olympics and Silverlight. As well, NBC will do the same for the Vancouver Olympics. Forgive me for not caring, as none of this is available in Canada.

You will probably hear that Silverlight has 3D functionality. A warning that it is not true 3D, but the ability to move a 2D image in three dimensions. The actual term is ‘perspective transform’. If you have to ask about the difference, then you probably don’t care. But for those that do, visualize a flat-screen image that can be rotated about the X-, Y-, or Z-axis so that it appears to be spinning. Hit testing works appropriately (you can only click on the image, regardless of how it is oriented.

Silverlight 3.0 will provide a better experience for SEO. This includes the capability of supporting deep linking and navigation.

Going back to the idea that support for a sketch-based workflow, Expression Blend 3 will have a features called SketchFlow. This feature allows for easy navigation through a collection of pages. The interface allows for quick and simple creation of the workflow through an application. Each state in the workflow corresponds to a page.

One of the things that is interesting about the creation of the pages in a workflow is the inclusion of Wiggly controls. These are controls that, through their appearance, will not be mistaken for a completed application. The borders on the controls take on the appearance of a hand-drawn image. Yet the controls are still real WPF controls, meaning that they work in the Blend and, indeed, when the applications is ‘run’ through the SketchFlow prototyping tool..

On the Road to MIX ‘09

I’m writing this particular blog post while in the air on the way to Las Vegas. For the next three days, I’m going to be at the MIX ‘09 conference. For regular readers of my blogs, that means you can expect a flurry of posts. I tend to live-blog the sessions that I’m in (particularly the keynotes) as a way of note taking, if nothing more. In this way, if nothing more, it is completely different than the MVP Summit I was at a couple of weeks ago.

Actually, there are some other differences. Where the MVP Summit is as much about giving information to Microsoft as it is about receiving, MIX is all about the receiving. While I have some inkling about some of the announcements that you’ll be hearing about, I also know that they have kept some under wraps. Which means that they were even held back from the NDA sessions at the MVP Summit. So, even though I already have some blog posts ready to go, I will still need to pay attention to what’s being discussed. And I’ll pass the good stuff on to you as soon as I can.

The Patch I Didn’t Even Know I Needed

I have been working with WPF and Silverlight pretty steadily for the past 6 months or so. And thanks to Rocky Lhotka, a problem that I didn’t even realize I had has been (probably) corrected.

The problem was that occasionally Visual Studio would just go away. No warning. No error. Just disappear. It didn’t happen that often for me, but I have had awkward moments while teaching a course. Even in that situation, neither I, nor any of the students did anything but shrug, chuckle and restart. These things do happen in the world of software development. The fact that we were willing to just accept it unquestioningly is a blog post for another day.

However, while perusing my blog roll yesterday, I came across this post from Rocky. It talks about a hotfix for a problem that causes Visual Studio to just disappear. Way too coincidental. A quick download and, hopefully, I’m inoculated from this issue going forward. If you’re using WPF in Visual Studio, it’s a fix you might strongly consider.