Now that the mysterious WP7 app I was working on for the last few months is done (at least v1.0!) and is in the certification pipeline, I finally have some time to start playing with WinRT.
Of course, the first thing I’m playing with is the port of this WP7 app to WinRT. In this post, I’m sharing the aspects I discovered this afternoon while trying to port a project from Windows Phone to WinRT. Let’s be clear my goal was just to see what it’s look like to port the code, I wasn’t able of course to port the WP7 app to WinRT in an afternoon…
Tooling
The development environment for Windows 8 is currently:
- Windows 8 Consumer Preview
- Visual Studio 11 Beta
- Blend for Visual Studio Beta
Because I wanted to have the Windows Phone environment too on this machine, I also installed:
Hello, World
As a developer, one of the first thing we try when we target a new platform is to display some kind of message on the screen. So I first tried the famous MessageBox.Show() but I quickly realized the API has changed…
If you want to display a message box, you must use the MessageDialog
class:
MessageDialog dialog = new MessageDialog("Content", "Title");
dialog.ShowAsync();
As you can see, displaying the dialog is actually an asynchronous operation. If we want to perform an action when the dialog closed, we must
await
that call:
MessageDialog dialog = new MessageDialog("Content", "Title");
await dialog.ShowAsync();
If you want to display additional buttons, you can add commands to the dialog:
MessageDialog dialog = new MessageDialog("Content", "Title");
dialog.Commands.Add(new UICommand { Label = "test" });
IUICommand result = await dialog.ShowAsync();
Namespace changes
Many namespace has changed between Windows Phone and WinRT, you can use pre-processor directives like the following:
#if WINDOWS_PHONE
using System.Windows.Data;
#else
using Windows.UI.Xaml.Data;
#endif
IValueConverter
Another thing I noticed is the fact that the IValueConverter
interface has changed (notice the last parameter…)
WPF/Silverlight/WindowsPhone version (documentation):
public interface IValueConverter
{
object Convert(object value, Type targetType, object parameter, CultureInfo culture);
object ConvertBack(object value, Type targetType, object parameter, CultureInfo culture);
}
WinRT version (documentation):
public interface IValueConverter
{
object Convert(object value, Type targetType, object parameter, string language);
object ConvertBack(object value, Type targetType, object parameter, string language);
}
Storage
The storage story in WinRT can be summarized by the following:
- file system access is heavily restricted (this was already the case for Silverlight and Windows Phone)
- most storage API are asynchronous
Here is an example taken from the WinRT documentation:
async void WriteTimestamp()
{
StorageFolder localFolder = ApplicationData.Current.LocalFolder;
StorageFile sampleFile = await localFolder.CreateFileAsync("dataFile.txt",
CreationCollisionOption.OpenIfExists);
await FileIO.WriteTextAsync(sampleFile, DateTime.Now.ToString());
}
async Task ReadTimestamp()
{
try
{
StorageFolder localFolder = ApplicationData.Current.LocalFolder;
StorageFile sampleFile = await localFolder.GetFileAsync("dataFile.txt");
String timestamp = await FileIO.ReadTextAsync(sampleFile);
}
catch (Exception)
{
}
}
Resources
The WP7 app contains several resource files (.resx). The resources are available in the XAML (using a binding to a static resource) and in C# using the static types that are automatically generated with the resx file. Well, it looks like those static types do not exist anymore in WinRT (also, the extension of the resource file has changed to .resw).
The resources can now be accessed using the ResourceLoader
type:
res = new ResourceLoader("PrototypeZero/AppResources");
string value = res.GetString("StringKey");
Conclusion
I think .Net developers should not be afraid by WinRT. If you already start playing with C# Async you will be familiar with the new asynchronous API. As far as I’ve gone with the comparison I think we can reasonably imagine having a good code base shared between WinRT and Windows Phone. I can safely continue to use the XAML knowledge I got about 5 years ago on WinRT
Of course there are many other things we can compare between WinRT and Windows Phone… This first post is just the beginning