Nine Silverlight 2 Features Not to Be Missed

Everybody likes buttons—everybody needs buttons—so it's not surprising that the premier of buttons and other visual controls in Microsoft® Silverlight™ 2.0 Beta 1 was the subject of headlines. Not everybody's Silverlight application will need to manipulate the DOM, or use local storage, or fetch data from a web service. But if you're building such an application, you may be more excited about these and other critical, but less visible, technologies in Beta 1. In this article we'll get right into nine Silverlight 2 Beta 1 technologies that belong in every developer's bag of tricks. Then we'll zoom in a little closer with a demo application that's built on a sampling of these features.

1. HTML DOM Integration
For Silverlight applications that are deployed as a control or element of a larger Ajax application, tight integration between Silverlight and the HTML DOM means no bump between Silverlight and its hosting page, and a better user experience. The number one use case for DOM integration before Beta 1 may well have been gaining access to HTML controls, but now that we've got Silverlight native equivalents we can move on to enhance page integration.

In Beta 1, you can do virtually everything related to the DOM from managed code. You can:

• Manipulate elements in the DOM from .NET code
• Install C# event handlers for DOM events
• Call JavaScript functions in the hosting page
• Have JavaScript functions in the hosting page call you

The key to making this work is the HtmlPage class in System.Windows.Browser. HtmlPage has a Document member that you can use to get access to DOM elements using functions such as GetElementById(). Once you've got the element, you can set its attributes or hook in events using the HtmlElement.AttachEvent() API.

2. JSON Serialization
Silverlight 2 Beta 1 applications can use the new .NET 3.5 DataContractJsonSerializer to serialize .NET objects to JSON. In our example project, below, we'll use this class to serialize our object for local storage. Since the representation is JSON, you can also use this technology to deserialize JSON strings from a web server or web service into C# objects on the client.

As we'll see in the sample, you need to set DataContract and DataMember attributes to mark a class as serializable and call out the members to be serialized (and optionally set the serialization name). These attributes give you control over how your object is serialized, allowing you, for example, to safely serialize a class that contains both an encrypted string (serialize) and its decrypted representation (don't serialize).

3. Styles and Templates
In the Silverlight control model there's complete separation between control functionality and control appearance. The only thing that's intrinsic about a button is its functionality; that is, it fires a click event when clicked. The appearance of the button and how that appearance changes for various states can be lightly or fully customized using Styles and ControlTemplates. It's important that these customizations are expressed and applied in XAML, not in code, keeping them in the realm of the designer and not the developer.

Styles are set through Style resources that are targeted at specific control types and allow you to control the visible properties of that type:

<Style TargetType="TextBlock" x:Key="TextBlockStyle">
< Setter Property="FontSize" Value="12"/>
<Setter Property="Margin" Value="5"/>
</Style>

You can then apply the style ("TextBlockStyle") to TextBlocks within the application.

Templates provide much deeper customization, giving you control over the XAML that defines the control's visible content. We can't go into any depth on control templates here, but Scott Guthrie's blog entry on the topic is a great place to learn more.

4. Local Storage
Isolated Storage gives your Silverlight application access to storage resources on the client. It's "isolated" because the store is partitioned per application, meaning no other applications can access files in your storage. On the other hand, your application (application defined by its URL) always gets the same storage, even if it's run in a different browser.

Prior to Beta 1, Silverlight local storage was cleared along with the browser cache. In Beta 1, local storage is independent of the cache, but the virtual file system presented by Isolated Storage still lives in the user's file system and can be deleted at any time. That makes local storage suitable for application settings, for caching, and for other locally-relevant but expendable data.

Beta 1 also lowers the per-domain quota of local storage to 100 KB (down from 1 MB). However, you can now ask the user for permission to increase your quota (the user can still say no) using the TryIncreaseQuotaTo() API.