Chapter 12. Share the light: Distribution and deployment

This chapter covers

Creating user controls Navigating between pages Enhancing the startup experience Hosting with Silverlight Streaming

Throughout this book you’ve seen how you can use Silverlight to ignite the web. It’s been an exciting journey as we’ve explored how to create rich and interactive solutions. Although these solutions can be exciting for you to use, ultimately you may want to share them with others. To do so, you need to learn how to effectively distribute and deploy your Silverlight content. That’s the purpose of this chapter.

Throughout this chapter you’ll learn how to share your Silverlight creations. The smallest forms of these creations are known as user controls. The process of creating a user control will be covered in section 12.1. A user control can be used as a page in Silverlight, so we’ll also cover how to navigate across multiple user controls. As the number of user controls in your applications grows, the size of the resulting .xap file does too, making it useful to know how to create a custom splash screen. Finally, you’ll see how to deploy your Silverlight content over a powerful hosted service known as Silverlight Streaming.

12.1. Creating a user control

Because Silverlight is still in its infancy, there may be times when none of the controls provided within Silverlight contains the functionality you need. For these situations, you may want to consider creating a reusable control. A reusable control can be useful when you want something more than UI enhancements. After all, these types of enhancements can be provided with the style and template features discussed in chapter 10. A reusable control allows you to reuse functionality not found in a preexisting control. For instance, imagine wanting to create a TextBox that can be locked by a user and looks like figure 12.1.

Figure 12.1. A TextBox that can be locked

This figure shows a control that provides functionality beyond a basic TextBox. This control adds an image that projects whether the TextBox can be edited. Although the desired functionality is easy to implement, you may not want to re-create it every time; this provides an excellent opportunity to create a reusable control. Now, imagine wanting to name this control LockableTextBox to use it in other projects. To do this, you must create an instance of the UserControl class.

The UserControl class is designed to represent a new control or extend an existing one. This class gives you the ability to organize small portions of a UI into more manageable components, which can then be used in your application or shared with other applications. The process to provide this kind of functionality involves the following:

1.  

Defining the appearance of the control

2.  

Defining the behavior of the control

3.  

Calling the control

This three-step process forms the ABCs of user-control development (Appearance, Behavior, and Call). Over the course of this section as you create a LockableTextBox, you’ll see how these three steps relate to one another.

12.1.1. Defining the appearance

Defining the appearance of a UserControl involves creating the XAML for the user interface. This process is the same as defining the UI for a page in Silverlight because every page in Silverlight is a UserControl. We’ll discuss this topic further in section 12.2. The XAML for the UserControl (LockableTextBox) is shown in snippet 12.1.

Snippet 12.1. XAML: The user interface for the LockableTextBox UserControl

This snippet shows the XAML that makes up the default appearance of the LockableTextBox. This UI defines a TextBox and an Image within a StackPanel . The StackPanel is important because each UserControl can have only one UIElement as a child, so you’ll almost always use one of the Panel elements discussed in chapter 3 as the direct descendent of a UserControl. Regardless of whether you use a Panel, the direct descendent will be set as the Content of the UserControl.

Setting the Content of a UserControl is an important first step in creating a reusable control. This step defines the static parts of the UI, but the real value in creating a reusable control is to provide some kind of new functionality. This functionality is generally delivered when you define the behavior of a control.

12.1.2. Defining the behavior

The functionality of a reusable control is also known as the behavior of a control. This behavior is defined in the code-behind file of the .xaml file, which will contain a class that derives from the UserControl class. It’s your responsibility to make sure this class provides the events, methods, and properties that detail the behavior of the control. Look at the code for the LockableTextBox control shown in snippet 12.2. This snippet uses a DependencyProperty, which was mentioned briefly in chapter 3, (section 3.5).

Snippet 12.2. c#: The LockableTextBox class definition

This class definition for a LockableTextBox uses a constructor to serve as the primer for the control . In addition, it provides an event handler that handles the user selecting the Image defined in of snippet 12.1. Perhaps the most interesting part is the UpdateUI method that details how the user can interact with the user control . It will automatically be called if the IsLocked property changes because the IsLocked property is set up as a DependencyProperty .

A DependencyProperty is a special type of property that can be used in animations, data binding, and styling. It’s designed to rely on, or depend on, one or more sources of data to determine its value. These sources could be things like Storyboard elements, animations, or Binding definitions. A DependencyProperty value will change only when one of its data sources changes it. A DependencyProperty is not limited to UserControl items.

DependencyProperty fields are used all over the Silverlight API, and you’ve seen them throughout this book. You’ll usually create DependencyProperty fields in your UserControl definitions, so we’ll show you how to create a DependencyProperty in this section. You’ll see how to enhance a CLR property, called IsLocked, by converting it to a DependencyProperty. In addition, you’ll learn how to leverage the biggest advantage of a DependencyProperty : the ability to respond to changes in property values.

Enhancing Clr Properties

A DependencyProperty is a CLR property whose value is dynamically based on its data sources. To take advantage of the dynamic characteristics of a DependencyProperty, you must do two things. First, you must define the property. Then, you must register the property with the dependency system.

When you define a property as a DependencyProperty, you use an approach similar to the traditional approach, which includes creating a publicly visible property with the return type you want. With a DependencyProperty, the get and set accessors must use the GetValue and SetValue methods of the DependencyObject class. These methods are specifically designed to connect a property value with the dependency system. Table 12.1 shows the syntax of a traditional CLR property compared to that of a dependency property.

Table 12.1. Comparing a traditional property definition to a dependency property definition

This table shows the minor syntactical differences between the traditional and dependency approaches. The dependency approach uses a CLR wrapper to expose the property. This wrapper uses the GetValue and SetValue methods to interact with a property’s value . The value itself is managed by the dependency system. Integrating a property into the dependency system requires registering the property as a DependencyProperty.

To register a property as a DependencyProperty, you must call the statically visible DependencyProperty.Register method. This method requires the name of the CLR wrapper, the type of the property value, and the type of the object that owns the property. Snippet 12.3 shows how to register the IsLocked property shown in table 12.1.

Snippet 12.3. c#: Registering a DependencyProperty with the dependency system

public static readonly DependencyProperty IsLockedProperty =
 DependencyProperty.Register( 
  "IsLocked",
   typeof(bool), 
    typeof(LockableTextBox),
    new PropertyMetadata(new PropertyChangedCallback(OnIsLockedChanged)) 
  )

This snippet shows how to register a property as a DependencyProperty. Notice the name of the DependencyProperty itself . This name can be anything, but it generally follows a naming template of [CLR Wrapper Name]Property. This Dependency-Property serves as a key in the property dictionary used by the GetValue and SetValue methods of a CLR wrapper, as shown in table 12.1. Also notice the fourth parameter, which allows you to define behavioral aspects and to automatically respond to property value changes.

Responding to Property Value Changes

Dependency properties have the ability to automatically respond to property value changes in a way that you determine. To stay connected with a value change, the PropertyChangedCallback (shown in snippet 12.3) passes along a DependencyPropertyChangedEventArgs instance, which gives you three properties to help you react to a change as necessary. These three properties are described in table 12.2.

Table 12.2. The properties of the DependencyPropertyChangedEventArgs structure

Property	Description
NewValue	The value of the property after the change has completed.
OldValue	The value of the property before the change has completed.
Property	The DependencyProperty that triggered the change.

This table shows the properties of the DependencyPropertyChangedEventArgs structure. This structure is associated with the dependency property that was changed. To get the object that this property is associated with, you must rely on the first parameter passed from the PropertyChangedCallback. This parameter represents the DependencyObject whose property value was changed, so you’ll most likely need to perform a conversion, as shown in snippet 12.4.

Snippet 12.4. c#: Registering a DependencyProperty with the dependency system

 private static void OnIsLockedChanged(DependencyObject o,
   DependencyPropertyChangedEventArgs e)
{
   LockableTextBox textBox = (LockableTextBox)(o);
   textBox.UpdateUI();
 }

This snippet shows the event handler for the PropertyChangedCallback delegate specified in snippet 12.3. As you can see, this is an event handler that updates the user interface of the UserControl. This optional event handler completes the implementation for the IsLocked dependency property.

At first glance, there seems to be a lot of additional coding associated with creating a dependency property. But, considering the fact that only dependency properties can be animated or used in styling, it’s clear that understanding dependency properties is an important part of UserControl development. Once the behavior of a UserControl is completed, you can use the control by calling it.

12.1.3. Calling the control

To include a UserControl in your application, you must do two things. First, you must add an XML namespace that references the location of the UserControl. Then, you must add an instance of that control within your XAML. These two steps are the same for any UserControl. Snippet 12.5 shows how to reference the LockableTextBox control built over the past two sections.

Snippet 12.5. XAML: Using the LockableTextBox

<UserControl x:Class="MySilverlightApp.Page"
 xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" 
 xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
 xmlns:my="clr-namespace:MyClassLibrary;assembly=MyClassLibrary" 
 Width="400" Height="300">
 <StackPanel x:Name="LayoutRoot" Margin="10">
    <my:LockableTextBox x:Name="myLockableTextBox" /> 
  </StackPanel>
</UserControl>

This snippet shows how to add the LockableTextBox to a basic Silverlight page. The my namespace is used to tell Silverlight where to look for the LockableTextBox definition . This definition is used to build the control, which is referenced later . That’s all there is to it.

Creating a reusable control in Silverlight is as simple as defining a UserControl, which consists of an appearance and a behavior. These two items generally represent a small component within a Silverlight application. Alternatively, a UserControl can represent a component as large as an entire page. This fact is important because it can affect how you decide to share your content. In addition, it can also impact how you architect navigation features in your Silverlight applications.

12.2. Architecting navigation in Silverlight

Throughout this book, you’ve learned about Silverlight from the perspective of an individual XAML file. In reality, your Silverlight applications will probably use more than one XAML file. This common necessity creates an interesting problem because Silverlight doesn’t provide an elegant way to switch between XAML files directly out of the box. To overcome this problem, you must architect your application to dynamically switch between XAML files.

Over the course of this section, you’ll learn how to architect your application to switch between XAML files. This discussion will use an imaginary master/detail implementation to demonstrate how this architecture works. This demonstration will use an XAML file called Master.xaml that displays a collection of items. When one of these items is selected, the details will be loaded and displayed in a page called Details.xaml. (Both XAML files are just for illustration.) The process of delivering navigation involves setting up the architecture, implementing a navigator, and adding the functionality to each XAML file.

12.2.1. Setting up the architecture

Architecting your Silverlight application to provide navigation is fairly straightforward. Each Silverlight application is encapsulated as a System.Windows.Application instance, so you can only assign one XAML file as the RootVisual (chapter 2, section 2.4). By assigning the RootVisual to an XAML file that has a single Panel, you can dynamically add and remove other XAML files as needed. In fact, if you name this XAML file NavigationService.xaml, your application would be structured like figure 12.2.

Figure 12.2. The architecture for providing navigation

This figure shows a high-level overview of how to structure an application to support navigation. As you can see, this approach adds only one extra layer to the overall structure of an application. This extra layer is shown as the NavigationService.xaml file. This file is the one that will be used to swap XAML files, but you can’t actually swap XAML files in Silverlight.

Silverlight doesn’t let you swap XAML files like you can swap files in other technologies such as ASP. NET because of the behavior of the RootVisual element mentioned earlier. Considering each XAML file is represented as a UserControl element and a UserControl is ultimately a UIElement, you can dynamically add and remove XAML files through a Panel. You can make a NavigationService.xaml file as simple as the one in snippet 12.6.

Snippet 12.6. XAML: The XAML of the NavigationService.xaml file

<UserControl x:Class="Chapter12.NavigationService"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"   
 xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" 
 Width="400" Height="300">
 <Canvas x:Name="LayoutRoot" Background="White" />  
</UserControl>

This snippet shows a basic XAML file that includes a single Canvas , which is a type of Panel. It’s important to use a Panel element because it allows you to dynamically add and remove UserControl elements. Because UserControl elements represent pages in Silverlight, a Panel is a perfect way to swap pages. But, to load other pages, you must implement a navigator.

12.2.2. Implementing a navigator

To implement a navigator, you create the code to swap UserControl elements. This code should be added to the code-behind file of the XAML file that contains the Panel that will house the UserControl elements. In figure 12.2, this XAML file was named NavigationService.xaml. If you assume that this file has a code-behind file named NavigationService.xaml.cs, you’ll have a class named NavigationService. This class is responsible for swapping UserControl elements (snippet 12.7).

Snippet 12.7. c#: The definition of the NavigationService class

This snippet shows a basic implementation of the NavigationService class. Although this looks like a lot of code, it can be broken down into three smaller parts. The first part is the currentPage member variable that tracks the UserControl currently shown to the user . The second part is the constructor for the NavigationService class, which loads the default page of the application into the root Panel . The third part is where the page-swapping magic happens.

The third part of implementing the NavigationService class involves declaring the Navigate method, which is responsible for removing the currently visible User-Control and loading the next one to be shown. The swap occurs by first retrieving the root Panel of the NavigationService . This Panel shows the currently visible User-Control, which needs to be removed, so the pageToRemove variable is declared . This variable is assigned by searching through the root Panel for a UIElement of the same type as the currently visible UserControl . If it’s found, it’s removed . Then, the new UserControl is loaded into view . This is one approach to creating the Navigate method; you may choose to go further.

If you choose to implement your own Navigate method, you may create something much more complex. You may choose to start an animation that fades between UserControl elements. Alternatively, you may decide to keep all the UserControl elements loaded in memory to shrink the load time. Regardless of what enhancements you choose to make, the Navigate method needs to be called from your UserControl elements. This method is what enables you to navigate between pages.

12.2.3. Navigating between pages (a.k.a. UserControls)

To navigate from an XAML file to a new one, you must call the Navigate method defined in snippet 12.7. This statically visible method uses a UserControl to load a new page, so you can load any XAML file by creating an instance of its class. For instance, if you want to navigate to the Master.xaml file, you could use the code in snippet 12.8.

Snippet 12.8. C#: The code to go back to the list view

NavigationService.Navigate(new Master());

This snippet shows an instance of the Master.xaml page created and navigated to. Based on the scenario described at the beginning of this section, this page will show a collection of items. When a user selects an item, that item will be loaded into the Details.xaml page, so you need to be able send that item to the Details.xaml page. You can accomplish this by creating a custom constructor and calling the Navigate method (snippet 12.9).

Snippet 12.9. c#: The code to load the details page into view

NavigationService.Navigate(new Details(item));

This snippet demonstrates how to load a page that requires data. You should assume the item used in this snippet represents the SelectedItem of an ItemsControl. That’s really all there is to it!

This demonstration is a small sample. In reality, there are a lot of situations that aren’t covered by this implementation, but our sample provides a solid starting point for implementing navigation in your Silverlight applications. This task is important because your Silverlight applications will often have multiple pages, as well as resources. As the number of these items grows, so does the size of your application. And as your application grows, so does the time it takes to download. For this reason, Silverlight gives you the opportunity to use a custom splash screen.

12.3. Using a custom splash screen

Silverlight empowers you to create a consistent experience from start to finish. Part of this experience involves the initial loading of an application. Sometimes (if an application is larger in size or the network is running slowly) this initial load can take longer than expected. Silverlight will automatically show a splash screen anytime the initial load takes longer than 500 milliseconds, and Silverlight allows you to customize this splash screen to ensure a consistent user experience.

Throughout this section, you’ll learn how to create a custom splash screen. The first step in this three-step process is creating the appearance of the splash screen. Once it’s created, you can integrate the splash screen with your solution to ensure it’s used while a Silverlight application is being downloaded. While this download is proceeding, you can choose to monitor its progress and update your splash screen. All these steps will be shown as a basic splash screen is implemented.

12.3.1. Creating the appearance

The first step in creating a custom splash screen is defining its appearance. You must take two important facts into consideration:

• The splash screen is used while a .xap file is being downloaded, so it doesn’t make sense to create the splash screen’s XAML inside of your Silverlight application. Instead, you must create the XAML within the web page that hosts your Silverlight application or in a separate file that’s part of your web application. Either of these actions will ensure your splash screen is accessible while the .xap file is being downloaded.
• The splash screen can’t use managed code, so you must use a scripting language like JavaScript for any runtime features of a custom splash screen.

With these constraints in mind, you can move forward with creating your own splash screen. For instance, you may want to create a basic animation that runs while a Silverlight application is being downloaded. Such an animation might be defined in an XML file called splash.xaml and look like the code in snippet 12.10.

Snippet 12.10. XAML Result: The XAML for a custom splash screen. Assume this XAML is stored in a file called splash.xaml.

This snippet defines a basic animation within a Canvas element. This animation rotates an Ellipse around a TextBlock , which shows the progress of the download. The progress of the download will be updated as the download progresses (section 12.3.3). For now, please notice the root Canvas element .

The root element of a splash screen must be one of the Panel elements mentioned in chapter 3, so you can’t use a UserControl element as you would if you were defining a page. This has to do with the fact that managed code can’t be used with a splash screen. Once you’ve chosen a Panel and created the appearance of the splash screen, you can integrate it with your web application.

12.3.2. Integrating the custom splash screen

The second step of using a custom splash screen is integrating it with a web application. You reference the XAML of the splash screen when you create an instance of the Silverlight plug-in. You can reference this XAML by using the splashScreenSource property as shown in snippet 12.11.

Snippet 12.11. JavaScript: The createObjectEx function call that associates a splash screen with Silverlight application

This snippet uses the splashScreenSource property to reference the splash screen created in snippet 12.10 . This property isn’t required by the createObjectEx function. By using this property, you can point to where a custom splash screen’s XAML is stored. As mentioned earlier, this XAML can be defined in a separate XAML file or defined within a hosting web page. Either way, when the splash screen’s XAML is loaded, you have the option of using the onSourceDownloadProgressChanged and onSourceDownloadComplete event handlers to monitor the load progress .

12.3.3. Monitoring the load progress

The third, but optional, step in creating a splash screen is monitoring the load progress. To accomplish this, you use the onSourceDownloadProgressChanged and onSourceDownloadComplete event handlers of a plug-in instance. These event handlers are shown in snippet 12.12.

Snippet 12.12. JavaScript: The event handlers used for monitoring the download progress of a .xap file

This snippet shows the onSourceDownloadProgressChanged and onSourceDownloadComplete event handlers referenced in snippet 12.11. The onSourceDownloadProgressChanged event will fire anytime the progress of a download has changed by .5% or more. If this event is triggered, you may access the total progress through the second parameter of the onSourceDownloadProgressChanged event. This parameter exposes a floating-point property called progress. The value of this property is between 0.0 and 1.0, so you must multiply the value by 100 in order to convert the value to a percentage. Once the progress has reached 1.0, the onSourceDownload-Complete event will fire.

The onSourceDownloadComplete event will fire when the requested Silverlight application has been completely downloaded. Because the Silverlight application will automatically start when it’s completely downloaded, you probably won’t use this event. Instead, you’ll probably use the Application.Startup event mentioned in chapter 2, section 2.4 because, at this point, you can begin using managed code instead of relying on scripted code. Scripted code still has its place, though, particularly when you need to reference a hosted Silverlight solution.

12.4. Hosting with Silverlight Streaming

Silverlight Streaming is a free hosting service, provided by Microsoft, that gives you several gigabytes of space to rapidly deploy Silverlight content. This content is best described as either a rich Silverlight application or a media experience in the form of an audio, video, or image file. Once they’re hosted, these content types can be requested through either a third-party web application or a set of REST APIs.

To demonstrate how to request a Silverlight application from Silverlight Streaming, this section will use a basic Silverlight application, which can be hosted in Silverlight Streaming in four easy steps. The first step involves preparing the application for streaming. From there, you’ll see how to package your content so that it can be deployed over Silverlight Streaming. Once it’s packaged, you can then upload the content into Silverlight Streaming as shown in section 12.4.3; once it’s uploaded, you can use it.

12.4.1. Preparing to stream!

Creating content for Silverlight Streaming is no different than creating a standard Silverlight application. For the sake of completeness, let’s create a basic Silverlight application that displays a basic greeting. The XAML for the Page.xaml file in this application looks like snippet 12.13.

Snippet 12.13. XAML: The code for the Page.xaml file of a basic application

<UserControl x:Class="MySilverlightApp.Page"
  xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" 
  xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" 
  Width="400" Height="300">
  <Grid x:Name="LayoutRoot" Background="White">
    <TextBlock Text="Hello, Silverlight Streaming!" />
  </Grid>
</UserControl>

This snippet displays a basic XAML file, which will be compiled into a .xap file. Note that .xap files are supported by Silverlight Streaming, but to deploy the application through Silverlight Streaming, you must package it up for deployment.

12.4.2. Pack it up!

Silverlight Streaming makes it easy to deploy Silverlight applications. Once you’re ready for distribution, you must perform two simple steps. The first step is creating a manifest file that details the application. The next step is packaging the .xap file into an easily deployable archive file. This archive file will include the manifest file created within the first step that details the content.

Detailing the Content

To describe your Silverlight applications, you must create a manifest file. This manifest file is an XML file that must be named manifest.xml. This file must adhere to a specific format, which includes a root element called SilverlightApp that begins the description of the application. A sample manifest with this element is shown in snippet 12.14.

Snippet 12.14. XML: The manifest file used to deploy a basic Silverlight application

<?xml version="1.0" encoding="utf-8" ?>
<SilverlightApp> 
  <source>MySilverlightApp.xap</source> 
</SilverlightApp>

This basic Silverlight Streaming manifest file uses the SilverlightApp element to begin describing the application . The element responsible for referencing the Silverlight application is called source . Note that the SilverlightApp element can have other child elements including those shown in table 12.3.

Table 12.3. The elements that can be used within the manifest.xml definition

Element	Description
Source	The path to the .xap file of a Silverlight application.
Height	The height of the rectangular region that will present the Silverlight Streaming content. This value may represent a percentage or number of pixels.
Width	The width of the rectangular region that will present the Silverlight Streaming content. This value may represent a percentage or number of pixels.
Background	Represents the background color. This value can either be a named value or a hexadecimal string.
isWindowless	Determines whether or not the plug-in is displayed in windowless mode through a Boolean value.
frameRate	The maximum number of frames that can be rendered within a second.
inplaceInstallPrompt	Specifies whether or not to display the in-place installation prompt if the required version of Silverlight isn’t installed.
Version	The version of Silverlight required by the application, such as. 2.0.
enableHtmlAccess	Specifies whether or not the content within the application can access the HTML DOM.
onError	The name of the JavaScript function that handles any unforeseen errors.
onLoad	The name of the JavaScript function that runs once the plug-in has been loaded.
jsOrder	Gives you the flexibility to specify the order in which multiple JavaScript files are loaded. If there are JavaScript files in the package not mentioned, they will be loaded in a random order after those specified in jsOrder have been loaded.
loadFunction	This is the name of the JavaScript function to call before the Silverlight plug-in is created.

The elements in this table should look somewhat familiar because they represent the parameters passed to the createObjectEx method. The order of the elements mimics the order in which they appeared in chapter 2. If any of these elements don’t make sense, please flip back to chapter 2 for more details. There are two exceptions to the order of these elements.

First, the createObjectEx method doesn’t take a jsOrder parameter, nor does the createObjectEx method take a loadFunction parameter. These two elements are useful if you decide to use the Silverlight 1.0 approach of using JavaScript instead of managed code. Regardless of which method you use, you must package a Silverlight application for deployment. This task involves compressing the necessary files into an easily distributable package.

Compress It!

As you’ll soon see, the Silverlight Streaming service requires a single file, which must be a valid, compressed .zip file. A valid .zip file is defined as having a manifest.xml file. In addition, this .zip file needs to have all the goodies associated with your Silver-light application. These goodies may include the file types shown in table 12.4.

Table 12.4. The file types accepted within a Silverlight Streaming application

File type	Sample extensions
Audio files	.mp3, .wma
Assemblies (Silverlight class libraries)	.dll
Images	.jpg, .png
JavaScript files (primarily for Silverlight 1.0)	.js
Text files	.txt
Video files	.wmv, .vc1
XAP files	.xap
XAML files	.xaml
XML files	.xml

This table shows the list of file types supported within Silverlight Streaming. If you try to put an invalid file type in the .zip file, Silverlight Streaming will reject your upload request, so you should try to stick with the file types shown. Noticeably absent are code-behind types such as .cs. This restriction can serve as a friendly reminder that you must compile your code before sending it to the Silverlight Streaming service. After you’ve compiled your code, you may ship it.

12.4.3. Ship it!

Deploying content through Silverlight Streaming is so simple that it hardly requires mention, but we’ll discuss it for the sake of thoroughness. In addition, this topic will help bridge the gap to the final step of using the content.

Silverlight content can be deployed by visiting http://streaming.live.com. This site requires a free Windows Live ID. Once you have this ID, you can begin uploading your Silverlight content. This upload process involves selecting a name for your application and choosing your compressed package. This process will also give you the ability to edit the contents of the manifest file through a simple input form. Once your content has been uploaded, you may use it.

12.4.4. Use it!

To use your uploaded content, you must target a web asset—you must have a web application ready to access the content from Silverlight Streaming or create a new one. You can’t navigate to a URL and use the uploaded Silverlight application. Instead, once you have a web asset in mind, you can use one of two ways to access the uploaded content.

One of the approaches is to use the Silverlight Streaming APIs. These REST-style APIs allow you to manage your Silverlight Streaming applications. These APIs include an authentication service to prevent any funny business. Although they’re extremely valuable, these APIs are outside the scope of this book.^[1] But, we will cover the other approach for accessing content within Silverlight Streaming.

¹ You can find out more about the Silverlight Streaming APIs by visiting http://msdn.microsoft.com/en-us/ library/bb851621.aspx.

The other approach for accessing Silverlight content involves embedding the content within a web page. This approach is slightly different than what you’ve seen up to this point. In fact, a Silverlight Streaming application can be integrated within your web application through one small code snippet—like snippet 12.15.

Snippet 12.15. JavaScript: Referencing a hosted Silverlight application

<iframe src="http://silverlight.services.live.com/invoke/7867/
 My%20Silverlight%20App/iframe.html" scrolling="no" frameborder="0" 
 style="width:500px; height:400px"></iframe>

This snippet shows how to reference a Silverlight application hosted within Silverlight Streaming. You’ll notice that this application is hosted within an HTML iframe, which makes the application easily deployable. That’s all there is to including a Silverlight Streaming application in your web pages.

The Silverlight Streaming service provides a quick and easy way to deploy Silverlight content, but there are some advertising, bandwidth, and streaming constraints that you should be aware of before you use it. To review these constraints or sign up for the service, visit http://streaming.live.com.

12.5. Summary

Throughout this chapter, you’ve seen how Silverlight empowers you to deliver a rich experience from start to finish. This experience begins with a splash screen, which Silverlight allows you to customize. Once the application has started, it will most likely require a navigation scheme, which can also be customized. Regardless of how far you go with your customizations, you can easily deploy that content through a local web server or with Silverlight Streaming.

Collectively, these items give you a lot of flexibility to deliver rich, interactive applications using Silverlight. We hope that this book has informed you how to do just that and that this book has given you the tools you need to be a confident Silverlight developer. And you’re now ready to ignite the internet and put Silverlight 2 in Action!

We hope you’ve enjoyed this book, and we welcome your comments! If you liked it, we encourage you to write an online review on your blog or on a retailer’s website (such as Amazon.com). The official forum for this book can be found on the publisher’s website at http://www.manning.com/Silverlight2inAction, where you can ask questions, post comments, and report any errata. Thank you!