10 Things Silverlight Devs Need to Know About the Windows Runtime
Every Silverlight developer needs to know these differences between Silverlight and the Windows Runtime before starting on a WinRT app.
- By Michael Crump
Now that the final versions of Windows 8 and Visual Studio 2012 have shipped, most Silverlight developers are looking at ways to translate their existing skill set to Windows Runtime (WinRT) apps built with XAML. Because you're already familiar with XAML, you need to understand what the Windows Runtime consists of, and how it's different than what you're used to. In this article, I document 10 things I've found while building my first WinRT app using XAML/C#; I hope they'll save you time and energy getting used to this new platform.
1. Fundamental Differences
It's important that you first understand the fundamental differences between Silverlight and WinRT apps. Take a look at Table 1 for a quick comparison of each platform's technology.
Windows 8 is more flexible in terms of environments, allowing not only XAML but HTML. This opens the platform up to Web developers as well as Silverlight and XAML developers.
WinRT apps are built primarily for touch input, whereas with Silverlight, a mouse and keyboard are the primary input devices. As I move between each item in this list, keep these differences in mind.
|Hosted inside a Web browser via plug-in
||Run on top of the Windows Runtime inside Windows 8
|Can run on Windows/Macintosh/Linux (with support via Moonlight)
||Can only run on Windows 8
|Majority of apps written in C#/Visual Basic/XAML
|Partial support for XNA is available in version 5
||XNA has been removed; however, Direct3D is available in C++ apps
|Uses the Microsoft .NET Framework 2.0-4.5
||Uses only the Microsoft .NET Framework 4.5
|Visual Studio 2008 and later can be used, as well as Windows and Mac OSes
||Development only via Visual Studio 2012, and only Windows 8 as host OS
|Built primarily for mouse/keyboard input
||Built primarily for touch input
Table 1. A comparison between Silverlight and WinRT apps.
2. Application Lifecycle
The application lifecycle of Silverlight applications versus WinRT apps is very different. The Silverlight application lifecycle is shown in Figure 1.
[Click on image for larger view.]
|Figure 1. The application lifecycle of a Silverlight app.|
In Silverlight, the user typically types a URL into a browser, and the <object > tag located in the HTML page loads the plug-in. The plug-in then downloads the XAP file (which contains the application code) and creates an instance of the Application class, then fires the start-up event. Finally, the Silverlight application is rendered inside the browser. The application will continue to run until the browser is closed.
In a WinRT app, this process is managed completely by Windows 8, instead of the user, as shown in Figure 2. When the user launches a WinRT app, it's quickly up and running. This app can be suspended when the user switches away from it, or when Windows enters a low-power state.
[Click on image for larger view.]
|Figure 2. The application lifecycle of a WinRT app. |
The app has 5 seconds to handle suspension. During this time, it's best to use Isolated Storage to persist settings that may benefit the user upon resuming; if the user switches back to the app, it's resumed.
Finally, if Windows has detected low memory, it might terminate the application while in suspended status. The user also has the ability to terminate a WinRT app at any time, but Windows 8 will primarily be managing this.
3. XML and Code Namespaces
XML and code namespaces have changed from Silverlight to the Windows Runtime. Let's look at an example of each.
Starting with XML namespaces, look at the following highlighted text for Silverlight:
And for the Windows Runtime:
You should use the using statement in your WinRT apps instead of clr-namespace, and you should never declare the assembly, as was done in Silverlight applications.
Taking a look at code namespaces, you'll quickly find that a majority of the changes occur in the UI-related classes. For example, in Silverlight applications you would typically find the following using statements:
In WinRT apps, they'll look like the following:
A great way to see a Silverlight 5 versus Windows Runtime comparison by namespace can be found at Tim Greenfield's Web site. He documents the differences in an easy-to-read manner.
Almost every application built today requires some sort of Web request. It might be pulling down an RSS feed to the daily news or weather, for example; whatever it is, applications need to connect to the Web, and this is no different with WinRT apps. Before you can begin to write WinRT apps, you must be aware of a few things:
- WebClient is no longer available in the Windows Runtime. HttpClient is the way you'll typically send/receive Web requests in WinRT apps.
- WebRequest in the Windows Runtime makes use of asynchronous programming. You'll need to understand special keywords such as async, await and Tasks <T>.
- Any callbacks, such as IAsyncResult, used in a Silverlight application will need to be rewritten.
Before looking at a code sample, I want discuss asynchronous programming. The Windows Runtime introduces a special keyword, async, which, when used correctly, avoids the bottleneck of your application being executed line-by-line. The async keyword enables the await keyword in that method. The await operator is applied to a task to suspend execution of the method until the task is complete. The Tasks <T> simply represents an asynchronous operation that can return a value.
Let's take a look at a sample of each, in Listing 1 and Listing 2. Again, notice the highlighted text.
In Listing 1 (the Silverlight example) I used the tried-and-true WebClient to make the call and return the XML response. In Listing 2 (the WinRT example) I marked the method as async and created a variable, client, that instantiated a new HttpClient that would later use the await keyword to asynchronously create our HttpResponseMessage.
I finished up by calling Task <T> to return the response as a string, which would be passed to the DisplayStories method. This method isn't shown, but it uses standard LINQ to parse the XML data.
This example demonstrates how using async, await and Task <T> made the application more responsive in case the request took a while to return. While these keywords may look strange at first, after building your first WinRT app they'll become second nature.
5. Storage: Files and Isolated Storage
Table 2 compares files and isolated storage for each platform.
|Isolated storage: Create, read, update or delete anything in the application sandbox
||Isolated storage is identical to Silverlight
|Read or write a file to the Documents Folder and so on via the Open/SaveFileDialog or by using elevated trust (Silverlight 4)/td>
||Read or write a file to the Documents folder and so on if indicated in the Application Manifest, or use the File and Folder Picker API
|Read or write a file anywhere on the local hard drive disk (HDD) via Open/SaveFileDialog, or by using full trust (Silverlight 5), neither of which require user intervention
||Read or write a file anywhere on the local HDD only through the File and Folder Picker API
Table 2. Silverlight versus WinRT app files and isolated storage.
I'll break these down into three groups: isolated storage, special folders (such as Documents and Pictures) and local files located anywhere on the hard disk drive (HDD).
For isolated storage, you'll quickly find that there are no differences between Silverlight and the Windows Runtime. A user can create, read, update or delete anything, as in Silverlight. The API for saving the files to isolated storage has changed slightly, but you still have free access to do anything in your sandboxed application.
For special folders, including Documents, Pictures and so on, you have the ability to prompt the user in a WinRT app by using a File or Folder Picker API, or write directly to these folders by specifying them in the Application Manifest.
For any other file or folder located on the local HDD, you have the ability in a WinRT app to write to it through the File and Folder Picker APIs. You can't write to a folder (such as C:\Temp\) in WinRT apps without first prompting the user. (In Silverlight 5, by contrast, you could use full trust to write to that folder without user intervention.)
6. Navigation: No More URI
In Silverlight applications, you typically use NavigationService.Navigate and pass it to a URI to navigate to a new page, like so:
this.NavigationService.Navigate(new Uri("/Page1.xaml", UriKind.Relative));
You can also implement more sophisticated application navigation by using the Frame and Page controls. Page controls represent discrete sections of content, while the Frame acts as a container for Page controls and facilitates navigation to pages.
The Frame control usually uses the UriMapper to navigate to a new page in XAML, rather than codebehind. Here's a sample of the Frame control as well as the UriMapper (both of these reside in the System.Windows.Navigation namespace):
Source="/Home" Navigated="ContentFrame_Navigated" NavigationFailed="ContentFrame_NavigationFailed" >
<uriMapper:UriMapping Uri="" MappedUri="/Views/Home.xaml"/ >
WinRT apps still have the concepts of Frame and Page classes. The Frame is responsible for navigation and determining if you can navigate, go back or go forward to a page. You can create a new page by using one of the built-in templates and navigate to it by calling the following:
Of course, this is generally more helpful if you can pass data to the page to which you're navigating. For example, if you had a TextBox named tb1 and wanted to pass the contents of it to another page, you could use the following code:
When the new page loads, you can retrieve the contents of the tb1.Text in the OnNavigatedTo event.
Silverlight controls such as Calendar, ChildWindow, DataGrid, DataPager, DescriptionViewer, MultiScaleImage, OpenFileDialog, RichTextBox, SaveFileDialog, TabControl, TabItem, TreeView, Validation and WebBrowser are no longer present in the Windows Runtime. Instead, Microsoft has replaced some of them with controls that interact with touch devices more easily. Here's a list of the most important ones:
- ListView displays a collection as a stack of items.
- GridView is used for grid-based layouts and grouping of items.
- Semantic Zoom allows you to zoom in or zoom out on a collection.
- FlipView is an items control that displays one item at a time.
- Media Player is similar to the MediaElement in Silverlight, but now has built-in playback buttons.
- Progress Ring is a progress indicator with a circular motion.
- Application Bar is typically used to replace menus.
- CarouselPanel, RichTextBlock and WrapGrid are a few other new controls you may find beneficial in your next WinRT app.
Many of these new controls can be found in Figure 3.
[Click on image for larger view.]
|Figure 3. Some of the new WinRT app controls.|
Animations are a key component of the new Windows UI. After logging into Windows 8 you'll see animated live tiles that display information such as new e-mails, the weather, trending news topics and so on. Opening an application launches an animation. When a user adds or removes an item inside an app, an animation might appear. In short, animations are everywhere in Windows 8, so it makes sense that Microsoft baked animations into the Windows Runtime.
Animation Easing in Silverlight allows you to apply built-in animation functions to your Silverlight controls. The result is a variety of animation effects that make your controls move in a more realistic way. The only issue with this is that few people are interested in Silverlight animations, as Windows XP and Windows 7 don't have the "fast and fluid" feel of Windows 8.
WinRT apps have a built-in animation library provided out of the box. It includes a variety of animations such as page and content transitions, as well as many others that you can see here.
Note that there are two types of WinRT animation:
- Theme transitions animate loading, unloading or changing screen location.
- Theme animations are built to run on user interaction; you must trigger them.
You can also create custom animations if the supplied animations don't fit your needs. I haven't yet found a case for building my own animations.
Charms allow you to have everything at your finger tips without going through a whole lot of effort. With a swipe to the right-hand side of the screen you can bring up the Charms bar, which allows you to do things like create Search contracts to allow your application to integrate with the built-in Windows Search.
You can also make use of the Share contract to share content in your application with other apps. For instance, a user that has opened an RSS reader might want to share a link with her friends; this can be done easily with this built-in contract. Many other examples can be found at here. This functionality was missing completely from Silverlight applications, as they were sandboxed inside a Web browser -- you'd have to write code for similar functionality.
One of the best features of Windows 8 is the built-in marketplace, which is designed for app discovery and reach. One problem that plagued Silverlight developers was an inability to find customers for their applications. The Windows Store already has 231 global markets (at the time of this writing) available to discover and purchase your app.
There's also a solution for customers wanting to deploy their WinRT app to their internal infrastructure, as well as a flexible business model (free, paid or trial) for those wanting public discovery of an application. The Microsoft Advertising SDK is also available if you want to give your app away and make money off of ad impressions.
There's a low barrier to entry, as the registration fee is $49 for individuals and $99 for companies. Microsoft shares up to 80 percent of the revenue generated from app sales, providing even more incentive for developers.
Only the Start
These 10 items are only the start. As you begin building your application, you'll likely find other differences between the Windows Runtime and Silverlight. The good news is that the Windows 8 community is thriving, and many folks are blogging and helping others understand this new platform. Microsoft has also provided excellent guidance about the way apps should look and feel, as well as plenty of sample source code. So what are you waiting for? Go ahead and begin building your first WinRT app!
About the Author
Michael Crump is a product manager that works at Microsoft on the Azure platform. He is a is a developer, blogger and speaker of topics relating to cloud development. He’s passionate about helping developers understand the benefits of the cloud in a no-nonsense way. You can reach him on Twitter at mbcrump or by following his blog at michaelcrump.net.