Porting Windows Phone Silverlight business and data layers to Windows Runtime 8
[This article is for Windows 8.x and Windows Phone 8.x developers writing Windows Runtime apps. If you’re developing for Windows 10, see the latest documentation]
Note For info about porting to a Universal Windows Platform (UWP) app for Windows 10, see Porting business and data layers.
The previous topic was Porting for I/O, device, and app model.
Behind your UI are your business and data layers. The code in these layers calls operating system and .NET Framework APIs (for example, background processing, location, the camera, the file system, network, and other data access). The vast majority of those are available to a Windows Runtime app, so you can expect to be able to port much of this code without change.
Application lifecycle (process lifetime management)
Your Windows Phone Silverlight app contains code to save and restore its application state and its view state in order to support being tombstoned and subsequently re-activated. The app lifecycle of Windows Runtime apps has strong parallels with that of Windows Phone Silverlight apps, since they're both designed with the same goal of maximizing the resources available to whichever app the user has chosen to have in the foreground at any moment. You'll find that your code will adapt to the new system reasonable easily.
Note Pressing the hardware Back button automatically terminates a Windows Phone Silverlight app. Pressing the hardware Back button does not automatically terminate a Windows Phone Store app. Instead, a Windows Phone Store app becomes suspended, and then it may be terminated. But those details are transparent to an app that responds appropriately to application lifecycle events.
For more info, see Application lifecycle.
Asynchronous methods
One of the priorities of the Windows Runtime is to provide a platform on which you can build apps that are truly, and consistently, responsive. Animations are always smooth, and touch interactions such as panning and swiping are instantaneous and free of lag, making it feel like the UI is glued to your finger. To achieve this, any Windows Runtime API that can't guarantee to complete within 50ms has been made asynchronous and its name suffixed with Async. Your UI thread will return immediately from calling an Async method, and the work will take place on another thread. Consuming an Async method is made very easy, syntactically, using the C# await operator, JavaScript promise objects, and C++ continuations. For more info, see Asynchronous programming.
Background processing
A Windows Phone Silverlight app can use a managed ScheduledTaskAgent object to perform a task while the app is not in the foreground. A Windows Runtime app uses the BackgroundTaskBuilder class to create and register a background task in a similar way. You define a class that implements the work of your background task. The system runs your background task periodically, calling the Run method of your class to execute the work. In a Windows Runtime app, remember to set the Background Tasks declaration in the app package manifest. For more info, see Supporting your app with background tasks.
To transfer large data files in the background, a Windows Phone Silverlight app uses the BackgroundTransferService class. A Windows Runtime app uses APIs in the Windows.Networking.BackgroundTransfer namespace to do this. The features use a similar pattern to initiate transfers, but the new API has improved capabilities and performance. For more info, see Transferring data in the background.
A Windows Phone Silverlight app uses the managed classes in the Microsoft.Phone.BackgroundAudio namespace to play audio while the app is not in the foreground. A Windows Runtime app uses the classes in the Windows.Media.Playback namespace. For more info, see How to play audio in the background and Overview: Background audio (Windows Phone Store apps).
Cloud services, and databases
Hosting data and app services in the cloud is possible using Azure. See Getting Started with Mobile Services. For solutions that require both online and offline data see: Get started with Offline Data in Mobile Services.
See Networking in this topic for the types to use to make http requests.
Windows Runtime apps do not currently include built-in support for data-intensive scenarios such as line of business (LOB) scenarios. However, you can make use SQLite for local transactional database services. For more info, see SQLite for Windows Phone.
Launchers and Choosers
With Launchers and Choosers (found in the Microsoft.Phone.Tasks namespace), a Windows Phone Silverlight app can interact with the operating system to perform common operations such as composing an email, choosing a photo, or sharing certain kinds of data with another app. Search for Microsoft.Phone.Tasks in the topic Windows Phone Silverlight to Windows Runtime namespace and class mappings to find the equivalent Windows Runtime type. These range from similar mechanisms, called launchers and pickers, to implementing a contract with the Share charm.
A Windows Phone Silverlight app can be put into a dormant state or even tombstoned when using, for example, the photo Chooser task. The same is true for the Windows Runtime FileOpenPicker class when used in a Windows Phone Store app, but not when used in a Windows Store app. For more info, see How to continue your Windows Phone app after calling a file picker.
Monetization (trial mode and in-app purchases)
A Windows Phone Silverlight app can use the Windows Runtime CurrentApp class for most of its trial mode and in-app purchase functionality, so that code doesn't need to be ported. But a Windows Phone Silverlight app calls MarketplaceDetailTask.Show to offer the app for purchase:
private void Buy()
{
MarketplaceDetailTask marketplaceDetailTask = new MarketplaceDetailTask();
marketplaceDetailTask.ContentType = MarketplaceContentType.Applications;
marketplaceDetailTask.Show();
}
Port that code to call the Windows Runtime RequestAppPurchaseAsync method:
private async void Buy()
{
await Windows.ApplicationModel.Store.CurrentApp.RequestAppPurchaseAsync(false);
}
If you have code that simulates your app purchase and in-app purchase features for testing purposes, then you can port that to use the CurrentAppSimulator class instead.
Networking
Any code you have that uses the System.Net.HttpWebRequest class will continue to compile and run in a Windows Runtime app, but code that uses the System.Net.WebClient class will not. The class you are recommended to use for http is Windows.Web.Http.HttpClient.
Notifications for tile or toast updates
Notifications are an extension of the push notification model for Windows Phone Silverlight apps. When you receive a notification from the Windows Push Notification Service (WNS), you can surface the info to the UI with a tile update or with a toast. For porting the UI side of your notification features, see Tiles and Toasts.
For more details on the use of notifications in a Windows Runtime app, see Sending toast notifications.
For info and tutorials on using tiles, toasts, badges, banners, and notifications in a Windows Runtime app using C++, C#, or Visual Basic, see Working with tiles, badges, and toast notifications.
Storage (file access)
Windows Phone Silverlight code that stores app settings as key-value pairs in isolated storage is easily ported. Here is a before-and-after example, first the Windows Phone Silverlight version:
var propertySet = IsolatedStorageSettings.ApplicationSettings;
const string key = "favoriteAuthor";
propertySet[key] = "Charles Dickens";
propertySet.Save();
string myFavoriteAuthor = propertySet.Contains(key) ? (string)propertySet[key] : "<none>";
And the Windows Runtime equivalent:
var propertySet = Windows.Storage.ApplicationData.Current.LocalSettings.Values;
const string key = "favoriteAuthor";
propertySet[key] = "Charles Dickens";
string myFavoriteAuthor = propertySet.ContainsKey(key) ? (string)propertySet[key] : "<none>";
Although a subset of the Windows.Storage namespace is available to them, many Windows Phone Silverlight apps perform file i/o with the IsolatedStorageFile class because it has been supported for longer. Assuming that IsolatedStorageFile is being used, here's a before-and-after example of writing and reading a file, first the Windows Phone Silverlight version:
const string filename = "FavoriteAuthor.txt";
using (var store = IsolatedStorageFile.GetUserStoreForApplication())
{
using (var streamWriter = new StreamWriter(store.CreateFile(filename)))
{
streamWriter.Write("Charles Dickens");
}
using (var StreamReader = new StreamReader(store.OpenFile(filename, FileMode.Open, FileAccess.Read)))
{
string myFavoriteAuthor = StreamReader.ReadToEnd();
}
}
And the same functionality using the Windows Runtime:
const string filename = "FavoriteAuthor.txt";
var store = Windows.Storage.ApplicationData.Current.LocalFolder;
Windows.Storage.StorageFile file = await store.CreateFileAsync(filename, Windows.Storage.CreationCollisionOption.ReplaceExisting);
await Windows.Storage.FileIO.WriteTextAsync(file, "Charles Dickens");
file = await store.GetFileAsync(filename);
string myFavoriteAuthor = await Windows.Storage.FileIO.ReadTextAsync(file);
A Windows Phone Silverlight app has read-only access to the optional SD card. A Windows Phone Store app has read-write access to the SD card. For more info, see Access the SD card in Windows Phone apps.
For info about accessing photos, music, and video files in a Windows Phone Store app, see Access media libraries in Windows Phone apps.
For more info, see Accessing data and files.
The next topic is Porting for form factor and UX.
Related topics
Windows Phone Silverlight to Windows Runtime namespace and class mappings