In-Depth

Porting a Silverlight App to a Metro-Style App

Many developers are worried about the compatibility of Silverlight with Metro-style applications. This project shows that those fears are overblown.

• By Michael Crump
• 03/01/2012

Windows 8, which was introduced at the Microsoft BUILD conference last year, is an exciting new OS that introduced a new UI as well as a new runtime: Windows Runtime, called WinRT. It's the backbone of the new Metro experience in Windows 8. Like many others, I've been playing with Windows 8 and kept hearing that Silverlight skills can be reused in Metro-style applications. I decided to find out for myself by taking a Silverlight 2 project and seeing how easy it was to port to a Windows 8 Metro application using C#/XAML.

Enter Silverlight 2
Several years ago, Scott Guthrie, corporate vice president of Microsoft Server & Tools Business, posted a seven-part series he called "First Look at Silverlight 2". The series walked readers through building a Silverlight 2 application. Some of the important concepts taught in the series included:

• Layout Management
• Networking
• ListBox and DataBinding
• User Controls
• Control Templates

At the end of the series, the completed project looked like Figure 1.

[Click on image for larger view.]

Figure 1. The Silverlight 2 Digg Client in its completed form.

If the user clicked on an item, Figure 2 was the result.

[Click on image for larger view.]

Figure 2. The Silverlight 2 Digg Client after a user clicked on an item.

Finally, clicking on the title would launch the default browser with the current story.

I was interested in seeing just how easy it would be to do a direct port of this code over to a Metro application. Note that I'm not trying to make this application fit the Metro guidelines in Windows 8. I simply want to run this as a Metro application in Windows 8 using C#/XAML.

The Initial Assessment
The first step was to download a completed version of Guthrie's Digg client sample, available here, and uncompress it to a temp folder. I then navigated to the \DiggSample_CSharp\DiggSample folder and inspected the files shown in Figure 3.

[Click on image for larger view.]

Figure 3. The DiggSample Silverlight 2 project uncompressed to a file folder.

After looking through the file structure, I decided I'd need only the following files:

• App.xaml. Application Initialization, which contains all of the Styles the application is using. (Note: App.xaml.cs wasn't needed, as it didn't contain any custom code.)
• DiggStory.cs. Contains a class called DiggStory with each element that will be used later in the LINQ statement.
• Page.xaml/Page.xaml.cs. The UI shown in Figure 1 with code that will definitely have to change because it uses WebClient.
• StoryDetailsView.xaml/StoryDetailsView.xaml.cs. The UI shown after a user selects an item. The codebehind looks simple and won't have to change.

Download and Installation
Using the Windows 8 Developer Preview, I launched Visual Studio 11 and selected Windows Metro style/Application and named it DiggSample (just like the original project), as shown in Figure 4.

[Click on image for larger view.]

Figure 4. A new Windows Metro-style project in Visual Studio 11.

I decided to start with the DiggStory.cs file first because it was a simple class that wouldn't need any modification. Listing 1 shows the class.

Because my project is also named DiggSample, all I had to do was copy and paste the class into my project. Right off the bat I thought I'd have to fix my namespaces. Here are the default Metro application XML namespaces:

<Application xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" 
x:Class="DiggSample.App" />

And the DiggStory Silverlight application XML namespaces:

<Application xmlns="http://schemas.microsoft.com/client/2007"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"  
x:Class="DiggSample.App">

The only difference is the first XML namespace. Because I'm creating a Metro application, I was able to leave the Metro application XML namespace untouched. The only thing I needed to do was copy <Application.Resources> out of the Silverlight application and into my Metro application.

I hit "build" and received the error shown in Figure 5.

[Click on image for larger view.]

Figure 5. The Error List window detailing an unknown type in RadialGradientBrush.

After searching the Web, I found that RadialGradientBrush isn't included in the current build (the reasoning pertains to GPU acceleration, as explained in the MSDN Forums). Nor is it supported in the Microsoft .NET Framework 4.5.

Instead of the RadialGradientBrush, I decided to use the LinearGradientBrush for this sample.

I replaced this code:

<RadialGradientBrush GradientOrigin=".3, .3">
  <GradientStop Color="#FFF" Offset=".15"/>
  <GradientStop Color="#777" Offset="1"/>
</RadialGradientBrush>

With this:

<LinearGradientBrush>
  <GradientStop Color="#FFF" Offset=".15"/>
  <GradientStop Color="#777" Offset="1"/>
</LinearGradientBrush>

This resulted in a successful build.

Next, I added a new User Control called StoryDetailsView. I then opened the existing StoryDetailsView.xaml from the DiggStory solution and noticed the XML namespace was identical to the default Metro application. So I copied and pasted the entire StoryDetailsView.xaml inside my Metro application and hit "build" again. I was immediately greeted with the error shown in Figure 6.

[Click on image for larger view.]

Figure 6. The Error List window detailing several unknown members.

There's an error stating that the NavigateUri doesn't exist on HyperlinkButton. It existed in Silverlight and Windows Phone, so where is it in WinRT?

This is where I discovered the differences in the XML namespaces being used. Hovering on top of the HyperlinkButton brings up the text shown in Figure 7.

[Click on image for larger view.]

Figure 7. The Windows.UI.Xaml.Controls.HyperlinkButton in Windows Runtime.

This demonstrates that a Metro-based Hyperlink class inherits the ButtonBase class without any special properties or events, such as NavigateUri. I can quickly fix this by removing NavigateUri and adding a Click Event Handler that will navigate to the Web site in the default browser. Here's how to fix it:

<HyperlinkButton x:Name="hlbStoryTitle" Content="{Binding Title}"  
  Click="HyperlinkButton_Click" Style="{StaticResource TitleLink}" 
  Tag="{Binding HrefLink}" />

Notice the Tag on the HyperlinkButton to pass the current URL. If I add the event handler and build the project again, it will compile successfully.

Next, I needed to add in our event handler for the HyperlinkButton and copy/paste the existing Close Button event handler:

void HyperlinkButton_Click(object sender, RoutedEventArgs e)
{
  Windows.System.Launcher.LaunchDefaultProgram(
    new Uri(hlbStoryTitle.Tag.ToString(), UriKind.RelativeOrAbsolute));
}
void CloseBtn_Click(object sender, RoutedEventArgs e)
{
  Visibility = Visibility.Collapsed;
}

By using Windows.System.Launcher.LaunchDefaultProgram, I was able to pass it a URI so it automatically launches the default browser. This method can only be called from a click event or some other user interaction.

In Silverlight 2, the MainPage was just called Page.xaml. This changed in Silverlight 3 with the name MainPage.xaml (which is also what Metro applications use).

With that out of the way, let's look at the XML namespaces again.

The Page.xaml inside the Silverlight application looks like this:

<UserControl x:Class="DiggSample.Page"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" 
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" 
xmlns:Digg="clr-namespace:DiggSample">

I was able to copy and paste the entire Page.xaml inside of my MainPage.xaml file and fix the following namespaces for the Metro application:

<UserControl x:Class="DiggSample.MainPage"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" 
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" 
xmlns:Digg="using:DiggSample">

Notice that DiggSample.Page turned into DiggSample.MainPage (remember what I said earlier about Silverlight 2?), and instead of using "clr-namespace" I used the "using" statement in WinRT applications.

If I run the application, it won't compile because I don't have event handlers set up for the buttons. That's OK for the meantime.

Here are the existing methods in MainPage.xaml.cs:

• searchBtn_Click. I know I'll need to see if the Digg API has changed and that I can't use WebClient in Metro applications.
• DiggService_DownloadStoriesCompleted. Will more than likely be removed because it's part of the WebClient.
• DisplayStories. Can be reused as long as the Digg API didn't change.
• StoriesList_SelectionChanged. Can be reused completely.

Initial Assessment of the Digg API
One thing I had to research was the Digg API. I assumed (correctly) that it had changed since 2008. But what had changed?

In Scott Guthrie's example, it calls the following URL:

 http://services.digg.com/stories/topic/{0}?count=20&appkey=http://www.scottgu.com

Here, {0} is the name of the search term.

I tried that URL and found out it returns nothing. After reading the Digg API -- which is deprecated again -- I found that it's changed to the following:

http://services.digg.com/search/stories?query={0}&appkey=http://www.scottgu.com 

Again, {0} is the name of the search term.

So I replaced the URL with the new one, leaving the appkey as is. (Request your own appkey if you're planning on using the digg API in your own applications.)

The next review item was the XML returned by the service, to see how well it matched the DisplayStories method. Listing 2 is sample XML returned by the Digg API using the service mentioned earlier.

I took each item from the DiggStory class, made sure it still existed and that the data type was correct. The only item that concerned me was the ID, as Guthrie's sample code cast ID as an integer. From looking at some random sample data it appears the ID is no longer an integer. I did several Google searches and others had hit this issue and recommended using a string, which I did.