MCTS: Microsoft Silverlight 4 Development (70-506) Certification Guide

Silverlight is Microsoft's cross-platform, cross-browser, and a .NET-based framework for building in and out-of-browser Rich Internet Applications (RIAs). In simple words, you can write Silverlight applications using a language you already know (be it C# or VB), and run it on all major operating systems (such as OSX, Windows, and Linux) and browsers (such as Internet Explorer, Chrome, Firefox, and Safari).

It's worth noting that the Linux variation of Silverlight is not developed or maintained by Microsoft. Moonlight, which is the name of the Linux variation, is developed by the Mono project with aid from Microsoft and Novell, and is primarily targeted for Linux and other Unix/X11-based operating systems. In addition, your Silverlight application doesn't have to stay inside the browser. Using the out-of-browser capabilities of Silverlight, you can take your application out of the browser and into the desktop, but we will learn more on that later.

Using Silverlight you can build just about anything—from a simple media player that streams movies from your server, to a complex line of business (LOB) application that fetches data from a database and uses some business logic to transform that data into a visually stunning executive dashboard with interactive charts and gauges.

Many companies nowadays are using Silverlight to enrich their applications. Take a look at Seesmic Desktop 2 for example (http://www.seesmic.com/products/desktop), which is a social media tool for Windows and Mac built entirely in Silverlight.

The main competition to Silverlight comes from Adobe Flash. Both are browser plugins targeting rich media applications. While not a direct competitor, HTML5 can also be considered as an alternative in some cases. While Silverlight has matured into a rich line of business platform that is getting increasingly popular for creating intranet applications, HTML5 offers greater reach, as it can be viewed on more devices. But, it is also much harder to develop the same level of business applications using HTML5 instead of Silverlight.

In addition, the HTML5 specifications are not finalized yet and, thus, not all the browsers implement it evenly. For example, while some browsers fully support the Canvas control, others support just some of its features, making it difficult to use the "code once, run everywhere" approach.

Whether you are an ASP.NET developer trying to decide if Silverlight is the right technology for your next project or you are a part of a development team in a big enterprise, here are some reasons to use Silverlight over other technologies:

The adoption rate of Silverlight has recently reached the 70 percent milestone (http://www.riastats.com/), which means that almost every three out of four PCs already have Silverlight installed! With the rise in the adaptation rate comes the rise in the need for developers. A leading job-hunting site—http://www.dice.com/—has recently found that Silverlight-related jobs experienced a 12.6 percent growth in demand over the last three months, while Adobe Flash-related jobs experienced just 2.2 percent growth over the same period of time (http://www.readwriteweb.com/enterprise/2011/05/it-hiring-and-salaries-up---wh.php). In addition, Silverlight is the language of choice to develop applications for Microsoft's newest mobile phone system—Windows Phone 7, which means that if you know Silverlight, you are not only a web and desktop developer, you are also a mobile developer!

If I have to sum up the last paragraph in simple words, I would say that you couldn't have picked a better time to become a certified Silverlight developer.

Now that you know what Silverlight is, what it can do, and why you should use it, let's move on to set up your development environment. Your development environment requires the following hardware and software components:

XAML is an acronym for Extensible Application Markup Language. Being a markup language, XAML isn't any different from your everyday-used XML or HTML. XAML is, at its core, an XML file that is used by Silverlight (and WPF) to create the user interface layer of your application. You can use just about any application to create XAML such as Visual Studio, Expression Blend, or even just plain old-school Notepad.

Not every XAML file is used by Silverlight for rendering the user interface layer. In every Silverlight project you will create, you'll notice a file named App.xaml. This file doesn't have any controls added to it, nor does it have the ability to host any controls. Instead, this file is used to host the application-level style resources (such as a Resource Dictionary, which we will talk about in a later chapter) and all of the application lifecycle events' receivers (such as the startup or exit events).

XAML gives us the ability to separate the user interface (UI) layer from the code layer. A XAML element will always represent a .NET element, so every attribute we set on the UI layer using XAML actually corresponds to a property within that .NET element it represents. This direct representation is also the reason why everything you can do with XAML on the UI layer, you can do in code (using C# or VB) as well.

To see how XAML makes our life easier when working with user interface components, let's examine the following line of code:

<input type="button" style='width:100px;height:40px;' value="Submit"/>

The preceding line of code should look familiar to you as it's the basic HTML syntax for adding a button to the screen.

Now, let's add the same button using the ASP.NET syntax:

Button btn = new Button();
btn.Width = Unit.Pixel(100);
btn.Height = Unit.Pixel(40);
btn.Text = "Submit";

Finally, let's add this button using XAML:

<Button Width="100" Height="40" Content="Submit"/>

As you can see, using XAML cuts down our code from four lines in ASP.NET to one short line of code.

Button, among other controls, also known as content controls, allow us to add a child control to display the control's content. If we take our button as an example, we can add an image as its content instead of the usual text:

<Button Width="100" Height="40">
<Button.Content>
<Image Source="fun.jpg"/>
</Button.Content>
</Button>

Content controls

Content controls are used very often in Silverlight and we will dig more into them later on, but the one key concept to remember about content controls is that they can only hold one child control as content. This limitation may look strange to you right now, but as we discuss layout controls, such as the Grid control in Chapter 2, Laying out Our User Interface, you will see that this limitation is hardly a limitation at all.

The easiest way to work with XAML controls is to drag them out of the toolbox and into the design surface. We can do this using both Visual Studio 2010 or a more designer-oriented application, for example Microsoft Expression Blend 4.

The following screenshot shows what the controls toolbox looks like in Visual Studio:

The following screenshot shows what the Controls toolbox looks like in Microsoft Expression Blend 4:

<UserControl x:Class="SilverlightApplication2.MainPage"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
mc:Ignorable="d"
d:DesignHeight="300" d:DesignWidth="400">
...
</UserControl>

<Button Width="100" Height="40" Content="Submit" x:Name="btnSubmit"/>

<Button Width="100" Height="40" x:Name="btnSubmit">
<Button.Content>
<Image Source="fun.png"/>
</Button.Content>
</Button>

<ControlType.PropertyName>some-value</ControlType.PropertyName>

A Silverlight application, once compiled, will end up as a XAP (pronounced as zap) file. That XAP file, which is actually a ZIP file renamed, will contain your compiled code in the form of a DLL file, which is a manifest file named AppManifest.xaml that describes your application to the Silverlight runtime engine and possibly some resources such as images, web service connection information, or any other type of content your application might need.

Due to the fact that a XAP file contains more than just compiled code, there may be times when we need to edit its content, which is where knowing the fact that "the XAP files are basically the ZIP files" comes in handy.

Consider the following scenario:

You are developing a Silverlight application that needs to access a database in order to display data from it. To access the database, you will connect to a WCF web service that grabs the data and sends it back to your application in the XML format. In most cases, the WCF web service won't be hosted on the same machine in both development and production environments and, thus, will have a different IP address on each. As we have mentioned earlier, the XAP file contains, among other things, the web service connection information for our application inside a file called ServiceReferences.ClientConfig. So, before we move our application from a development to a production environment we need to edit this file and change the address of the WCF web service from a testing environment address to the production address.

In order to run our Silverlight application, the browser will download our XAP file to the client computer, which means file size may be an issue for users with limited bandwidth or a slower connection. We may try to reduce the size of our XAP file by re-zipping it using a stronger compression rate. But, this will come at the expense of slower decompression of the XAP file on older machines, and the slower the decompression rate is, the longer it will take for your application to start running.

A better method to decrease the size of your XAP file would be using the "application library caching" option. The application library caching, also known as assembly caching, is a packing method, which avoids packing the DLL files into your XAP file, and instead zips them into individual files alongside it. Using assembly caching may greatly reduce the size of your XAP file, providing faster initial loading time for your application.

To use assembly caching, right-click on the project name in Visual Studio 2010 and select Properties. In the new dialog box, select the Reduce XAP size by using application library caching option, as shown in the following screenshot:

You may be wondering at this point how the Silverlight runtime engine knows that we used the assembly caching option, and that it needs to download a list of external DLL files. The answer to this question is simpler than you might imagine—the AppManifest.xaml file.

We have mentioned the AppManifest.xaml file earlier when we discussed the content of a XAP file and now we can elaborate more about it. The AppManifest.xaml file has one important role—it is responsible for describing our application to the Silverlight runtime engine. Whenever you create a new Silverlight project, Visual Studio 2010 creates this file as part of the project and updates it throughout the project lifetime if necessary. As Visual Studio is responsible for updating this file, it would be rare that we need to update this file by hand ourselves.

Visual Studio 2010 will generate the content of the file, once you compile your Silverlight project. Let's take a look at a basic example of an AppManifest.xaml file:

<Deployment xmlns="http://schemas.microsoft.com/client/2007/deployment" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" EntryPointAssembly="SilverlightApplication2" EntryPointType="SilverlightApplication2.App" RuntimeVersion="4.0.60310.0">
<Deployment.Parts>
<AssemblyPart x:Name="SilverlightApplication2" Source="SilverlightApplication2.dll" />
<AssemblyPart x:Name="System.Windows.Controls.Navigation" Source="System.Windows.Controls.Navigation.dll" />
<AssemblyPart x:Name="System.Xml.Linq" Source="System.Xml.Linq.dll" />
</Deployment.Parts>
</Deployment>

As can be seen from the preceding code snippet, the Deployment element has three attributes as follows:

Under Deployment lies the Parts section. This section houses one or more AssemblyPart entries, each of which point to a DLL file that our application is using. The first entry is usually our compiled Silverlight application, which also contains the entry point class that was specified under the EntryPointType attribute of the parent Deployment tag.

Other than Parts, the Deployment element may also contain an ExternalParts section. This section will be visible only if we have used the application caching option. This section tells the Silverlight runtime engine which files it needs to download, other than the XAP file, in order to run the application. The ExternalParts section will contain one or more ExtentionPart entries, each of which point to an external ZIP file.

An example of the ExternalParts section may look like the following code snippet:

<Deployment.ExternalParts>
<ExtensionPart Source="System.Windows.Controls.Navigation.zip" />
<ExtensionPart Source="System.Xml.Linq.zip" />
</Deployment.ExternalParts>

In our sample, the Silverlight runtime engine will have to download two external files to get the application running.

Now that we know how the Silverlight application model works, let's see how Silverlight interacts and integrates with HTML to actually display the application to the user.

There are two ways to add a Silverlight application to your HTML page as follows:

Using the object tag

The object tag method is the easiest way to add a Silverlight application to your page. Using this method, you won't need to use any external JavaScript files for adding a Silverlight application to your page. This method is also supported by all the browsers that are supported by Silverlight. A basic Silverlight object tag will look as follows:

<object data="data:application/x-silverlight-2," type="application/x-silverlight-2" width="100%" height="100%">
<param name="source" value=" MyCoolApp.xap"/>
<param name="onError" value="onSilverlightError" />
<param name="background" value="white" />
<param name="minRuntimeVersion" value="4.0.60310.0" />
<param name="autoUpgrade" value="true" />
<a href="http://go.microsoft.com/fwlink/?LinkID= 149156&v=4.0.60310.0" style="text-decoration:none">
<img src="http://go.microsoft.com/fwlink/?LinkId=161376" alt="Get Microsoft Silverlight" style="border- style:none"/>
</a>
</object>

The object tag has four mandatory attributes as follows:

• data: While not used by most browsers in the context of Silverlight, it is recommended by Microsoft to have the value of this attribute set to"data:application/x-silverlight-2," to prevent decreased performance in some browsers. You can think of this attribute as a sort of MIME type.

• type: This attribute actually represents the MIME type. It identifies the object tag as a Silverlight object, which will cause the browser to initiate the Silverlight plugin in order to render the object.

• width and height: They specify the width and height of the Silverlight application. You can specify the measurements in pixels or percentages.

Inside the object tag we have several param entries, as listed in the following table:

Name	Description	Required	Default
source	This specifies the URI to the XAP file. It can be a relative or absolute URI.	Yes	None
onError	This specifies a JavaScript function to call when an error occurs while loading the Silverlight application.	No	None
background	This specifies the background color for the object tag rectangular area that displays the Silverlight application. It can accept color names (such as Red) or hexadecimal values with or without alpha (#ff000000 or #000000).	No	white
minRuntimeVersion	This specifies the earliest Silverlight version required to run the application.	No	Currently installed version
autoUpgrade	This specifies whether or not to automatically update to the specified version in the minRuntimeVersion attribute if the currently installed version is an older version.	No	true
initParams	This specifies user-defined initialization parameters using comma-separated key-value pairs, for example, UserName=JohnnyT	No	None

There are many more parameters you can use with your Silverlight object tag, and you can read more about them at Microsoft's MSDN web page—http://msdn.microsoft.com/en-us/library/cc838259(v=vs.95).aspx.

If the browser fails to render the Silverlight application, it will fall back to the content inside of the object tag. The default content of a Silverlight object tag will look like the following screenshot:

You can always change the content of the object tag to your liking by simply removing all the content the object tag currently has (remember, don't delete the param entries!) and writing your own HTML code instead.

Silverlight started its life as an in-browser technology offering rich UX, media playing capabilities, and animation. Starting with Version 3, Silverlight gained the ability to run applications outside the browser, as sandboxed desktop applications. In Silverlight 4, the out-of-browser feature gained a serious boost with the introduction of "elevated trust". Not only can you now access local files and folders on the user's computer (pending his/her approval for your application to run in elevated trust mode) but you can also use COM automation to connect to other applications, for example Microsoft Office. Other important features of out-of-browser applications are toast notifications (a notification API), full screen mode support (for kiosk-based applications), and complete control over the application window. A great example for an out-of-browser Silverlight application is Seesmic Desktop 2, which you can see in the following screenshot:

While we won't go into detail here on how to create and work with out-of-browser applications, as we have a chapter dedicated to this subject later on, we will address some of the differences between in and out-of-browser applications as follows:

The installation process of an out-of-browser application is quick and painless; the user either right-clicks on the application surface or chooses install, as shown in the following screenshot:

To make things easier for the user, we can create an installation button that will initiate the installation process. We will discuss this method in Chapter 6, Interacting with the Host Platform of the book.

There is a lot more in the subject of out-of-browser applications and while this chapter only provided a glimpse of the possibilities of the features,Chapter 6, Interacting with the Host Platform, will dive much deeper into it.

With this we will end the introductory chapter of this book. We've learned about what Silverlight is and what we can do with it. We've set up a development environment for Silverlight. We've learned about XAML—what it does and how to use it. We've also looked into the Silverlight application model and learned what a XAP file is and what it contains, and we finished off with an introduction to the integration of Silverlight with HTML and the concept of out-of-browser applications.

I hope that you gained as much as possible from this chapter and grasped all the basics of Silverlight, as we are now ready to move on to laying out a user interface, which is the topic of our next chapter.