Separate UI and app logic using the Model-View-ViewModel pattern
[ This article is for Windows Phone 8 developers. If you’re developing for Windows 10, see the latest documentation. ]
The greatest potential to share code between your apps for Windows Phone 8 and Windows 8 is in your app logic. We recommend that you tailor the UI of your app for each platform so you can deliver the best possible user experience by aligning with the user experience guidelines for each platform. The design concepts and XAML controls supported in Windows Phone 8 and Windows 8 are similar, but sharing XAML is not where you should spend your investment. Instead, you’ll have much more success structuring your app logic to make it reusable. We recommend using the Model-View-ViewModel (MVVM) design pattern in your app.
This topic contains the following sections.
- Introduction to the Model-View-ViewModel (MVVM) pattern
- What to share in an MVVM-based app
- Related Topics
Introduction to the Model-View-ViewModel (MVVM) pattern
MVVM is a way to separate your data from your UI. In the MVVM design pattern, developers can code app logic, and designers can create the UI. XAML is designed to make it easy to build apps using MVVM, and they complement each other in a way that makes separation of UI and app logic a natural thing to do. The following diagram shows the basic architecture of an app built using the MVVM design pattern.
.png)
In the Model-View-ViewModel design pattern, an app is composed of three general components.
Model: This represents the data model that your app consumes. For example, in a picture sharing app, this layer might represent the set of pictures available on a device and the API used to read and write to the picture library.
View: An app typically is composed of multiple pages of UI. Each page shown to the user is a view in MVVM terminology. The view is the XAML code used to define and style what the user sees. The data from the model is displayed to the user, and it’s the job of the ViewModel to feed the UI this data based on the current state of the app. For example, in a picture sharing app, the views would be the UI that show the user the list of albums on the device, the pictures in an album, and perhaps another that shows the user a particular picture.
ViewModel: The ViewModel ties the data model, or simply the model, to the UI, or views, of the app. It contains the logic with which to manage the data from the model and exposes the data as a set of properties to which the XAML UI, or views, can bind. For example, in a picture sharing app, the ViewModel would expose a list of albums, and for each album expose a list of pictures. The UI is agnostic of where the pictures come from and how they are retrieved. It simply knows of a set of pictures as exposed by the ViewModel and shows them to the user.
To learn more about MVVM, see Implementing the Model-View-ViewModel pattern for Windows Phone 8. Many other resources that can help you understand MVVM are available, in addition to frameworks that have been built to make writing MVVM even simpler. MVVM, or any other separation pattern, is a great way to structure your app, particularly if you are considering building your app for Windows Phone 8 and Windows 8. It gives you the maximum potential to share code.
What to share in an MVVM-based app
When you build an app for Windows Phone 8 and Windows 8, the recommendation is to design and develop the UI tailored to each platform to deliver the best user experience possible. The majority of the UI, or views, of the app will be platform-specific. The rest of the app has the potential to be either portable or common between your Windows Phone 8 app and your Windows Store app. This is illustrated in the following diagram.
.png)
There is a distinction between portable and common code. Portable code is any code that can be compiled once and run on Windows Phone 8 and Windows 8. For example, most of the .NET API is portable between both platforms and can be implemented in a Portable Class Library. Common code is code that uses API that’s common to both platforms, but isn’t portable. For example, code that uses the Windows Runtime API that is common between Windows Phone 8 and Windows 8 can be considered common, but it isn’t portable because the code must be compiled for each platform. It also can’t be used in a Portable Class Library. Exactly how much your app can share code, even when using MVVM, will depend on the complexity of your app and what APIs it uses.
See Also
Other Resources
Build 2012: How to Leverage your Code across Windows Phone 8 and Windows 8
Share functionality using Portable Class Libraries
Implementing the Model-View-ViewModel pattern for Windows Phone 8
Using the MVVM pattern in Windows 8