- Understanding the Role of XAP Files
- The Windows Phone Capabilities Model
- The Threading Model for XAML-Based Graphics and Animation in Windows Phone
- Understanding the Frame Rate Counter
- The Windows Phone Application Analysis Tool
- Reading Device Information
- Applying the Model-View-ViewModel Pattern to a Windows Phone App
- Property Change Notification
- Using Commands
- Argument Validation
- A Platform-Agnostic Dialog Service
- Consuming Local Web Applications
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Applying the Model-View-ViewModel Pattern to a Windows Phone App
A dominant pattern that has emerged in XAML UI based technologies, in particular WPF and Silverlight, is the Model-View-ViewModel (MVVM) pattern. MVVM is an architectural pattern largely based on the Model-View-Controller (MVC) pattern, which, like the MVC pattern, serves to isolate the domain logic from the user interface logic. In addition, MVVM leverages the strong data binding capabilities of XAML based technologies, which allows loose coupling between the view and the viewmodel so that the viewmodel does not need to directly manipulate the view. This eliminates the need for almost all code-beside, which has a number of benefits, including freeing interactive designers from writing view specific code.
The following are the principal elements of the MVVM pattern:
- Model—The model is responsible for managing and delivering data.
- View—The view is responsible for displaying data. The view is ordinarily a UI element, and, in the case of XAML-based Windows Phone apps, it is a UserControl such as a PhoneApplicationPage.
- ViewModel—A bridge or intermediary between the model and the view, which commonly retrieves model objects and exposes them to the view. Often the viewmodel is designed to respond to commands that are bound to UI elements in the view. The viewmodel can be thought of as the model of the view.
With the release of the Windows Phone 7.1 SDK came Silverlight 4 and support for ICommands. The use of commands is discussed in the section “Using Commands” later in the chapter.
There are numerous benefits to using MVVM in your apps. MVVM can improve an app’s testability because it is easier to test code from a unit test that does not rely on surfacing UI objects. Testing apps is discussed further in Chapter 24, “Unit Testing Apps.”
Placing application interaction logic in a viewmodel also makes it easier to redesign your app while reducing the need to refactor interaction logic. Occasionally you may like to reuse some of your UI logic in different apps or, to a lesser extent, you might want to target different UI technologies, such as WPF, Silverlight, or Windows Store XAML applications. Decoupling interaction logic from any particular UI technology makes it easier to target multiple platforms.
Implementing the MVVM Pattern
There are two general approaches to MVVM viewmodel and view creation: view-first and viewmodel-first. The first approach sees the creation of the view before the viewmodel. Conversely, in the viewmodel-first approach, it is the viewmodel that creates the view. Both approaches have their pros and cons. Viewmodel-first potentially offers complete independence from the UI, allowing an app to be executed entirely without a UI; yet it suffers from various implementation challenges. View-first is far simpler to implement when page navigation is used, as is the case in a Silverlight for Windows Phone app.
This book uses the view-first approach exclusively.
MVVM in a XAML app relies on the assignment of a viewmodel to the view’s DataContext property. There are a number of commonly used techniques for marrying a viewmodel to its view. Some offer a high degree of flexibility at the cost of greater complexity and decreased visibility. The technique employed throughout this book, and the one I find to be adequate in most cases, has the viewmodel instantiated in the view’s constructor. In the following example a viewmodel is assigned to the view’s DataContext property:
publicpartialclassFooView:PhoneApplicationPage{publicFooView() { InitializeComponent(); DataContext =newFooViewModel(); } ... }
With the DataContext set to the viewmodel, properties of the viewmodel can be used in data binding expression in the view’s XAML.
ViewModelBase Class
Windows Phone apps often consist of many pages and, in turn, many viewmodels. It is useful to employ a viewmodel base class to share common infrastructure across all viewmodels in your app.
In the samples throughout this book, most viewmodels subclass a custom ViewModelBase class that provides, among other things, navigation support, error validation, state preservation, and property change notification (see Figure 2.9). Each of these capabilities is discussed alongside related topics in subsequent chapters.
)
FIGURE 2.9. ViewModelBase class diagram.
ViewModelBase inherits from a custom NotifyPropertyChangeBase class, which provides for property change notification, discussed in the next section.