Porting a Windows Phone Silverlight app to a XAML WinRT app
When porting a Windows Phone Silverlight app to the model for XAML Windows Runtime apps, most of your knowledge and experience will transfer, as will much of your source code and the software patterns you use. Even your UI markup and design can port over readily. You may be surprised at how relatively easy the process is, even if there is a challenge or two along the way.
As you read this porting guide, you can refer to the topic before this one: Windows Phone Silverlight to Windows Runtime namespace and class mappings. Fairly straightforward mapping is the general rule, but there are a few exceptions. The namespace and class mappings table describes any exceptions, but also see the few exceptions at the feature level listed in this topic's parent.
Additional info about Windows Store apps with XAML in general can be found at Roadmap for Windows Runtime apps using C# or Visual Basic.
- View. The view (together with the view model) makes up your app's UI. Ideally, the view consists of markup bound to observable properties of a view model. Another pattern (common and convenient, but only in the short term) is for imperative code in a code-behind file to directly manipulate UI elements. In either case, much of your UI markup and design—and even imperative code that manipulates UI elements—will be straightforward to port.
- View models and data models. Even if you don't formally embrace separation-of-concerns patterns (such as MVVM), there is inevitably code present in your app that performs the function of view model and data model. View model code makes use of types in the UI framework namespaces. Both view model and data model code also use non-visual operating system and .NET Framework APIs (including APIs for data-access). And 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. Remember, though: a view model is a model, or abstraction, of a view. A view model provides the state and behavior of UI, while the view itself provides the visuals. For this reason, any UI you adapt to the different form factors that the Windows Runtime allows you to run on will likely need corresponding view model changes.
- Cloud services. It's likely that some of your app (perhaps a great deal of it) runs in the cloud in the form of services. The part of the app running on the client device connects to those. This is the part of a distributed app most likely to remain unchanged when porting the client part.
Before or during the porting, consider whether your app could be improved by refactoring it so that code with a similar purpose is gathered together in layers and not scattered arbitrarily. Factoring your universal Windows app into layers like those described above makes it easier for you to make your app correct, to test it, and then subsequently to read and maintain it. You can make functionality more reusable—and avoid some issues of UI API differences between platforms—by following the Model-View-ViewModel (MVVM) pattern. This pattern keeps the data, business, and UI parts of your app separate from one another. Even within the UI it can keep state and behavior separate, and separately testable, from the visuals. With MVVM, you can write your data and business logic once and use it on all platforms. It's also very likely that much of the view model and view parts can be reused across platforms, too, although that varies between apps.
You begin the porting process by creating a new Windows Runtime project (a type of Store project) in Visual Studio and copying your files into it. If you choose to create a Universal App project then you'll be able to support PCs, tablets, and phones from one code base.
The practice of defining UI in the form of declarative XAML markup translates extremely well from Windows Phone Silverlight to Windows Runtime apps. You'll find that large sections of your markup are compatible once you've updated system Resource key references, changed some element type names, and changed "clr-namespace" to "using".
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.
Windows apps share a common look-and-feel across PCs, tablets, and phones. The user interface, input, and interaction patterns are very similar, and a user moving between devices will welcome the familiar experience. But practical differences between devices such as physical size, default orientation, and effective pixel resolution factor into the design of a universal Windows app.
- Windows Phone Silverlight to Windows Runtime namespace and class mappings.
- Windows Runtime reference
- .NET for Windows Store apps overview
- .NET for Windows Store apps
- Designing UX for apps