TPA - Windows Phone

Data binding, MVVM

Prepared by: Kamil Kowalski

Agenda
Data binding
Dependency Property, INotifyPropertyChanged Data flow, Converters

Model View-Model View design pattern

MVVM structure Commands, Behaviors Advantages & Pitfalls

Some Useful MVVM Frameworks Q&A

Data binding
Almost every application has some kind of data, and the ability to connect that data to elements in the UI (the view) is absolutely essential. Connection between data and UI can be done:
Programmatically - in various ways to, for example: assigning values as you go bind data to controls - powerful and essential features of XAML programming. Note: Data binding is present in WinForms and ASP.NET, but its hard to say, that this feature is powerful in those frameworks.

Data binding
What Is Data Binding?
Data binding is the process that establishes a connection between the application UI and business logic. If the binding has the correct settings and the data provides the proper notifications, then, when the data changes its value, the elements that are bound to the data reflect changes automatically. Data binding can also mean that if an outer representation of the data in an element changes, then the underlying data can be automatically updated to reflect the change.

Binding always follows the model:

Data binding
Data binding is essentially the bridge between your binding target and your binding source.
Each binding has these four components: a binding target object, a target property, a binding source and a path to the value in the binding source to use. The target property must be a dependency property. Binding source object is not restricted to being a custom CLR object. XAML based data binding supports data in the form of CLR objects and XML (see Binding Sources Overview).

Data binding
dependency properties The purpose of dependency properties is to provide a way to compute the value of a property based on the value of other inputs (see Dependency Properties Overview). Dependency properties are just like normal CLR properties, but with a X-factor.
The X-factor is that these properties have inbuilt support for data binding, animation, styling, value expressions, property validation, per-type default values.

Dependency properties are needed to be able to save state of UI Elements.

Data binding
data flow
The data flow of a binding can go from the binding target to the binding source.

OneWay binding causes changes to the source property to automatically update the target property, but changes to the target property are not propagated back to the source property. TwoWay binding causes changes to either the source property or the target property to automatically update the other. OneWayToSource is the reverse of OneWay binding; it updates the source property when the target property changes. OneTime binding, which causes the source property to initialize the target property, but subsequent changes do not propagate.

Data binding
INotifyPropertyChanged
To detect source changes the source must implement a suitable property change notification mechanism such as INotifyPropertyChanged. INotifyPropertyChanged - a simple interface that allows each property to notify the UI when its value changes.
Its common to create a helper method that checks to make sure the event has at least one method registered to it. If so, the helper method raises the event, passing in the name of the property that updated.

The UpdateSourceTrigger property of the binding determines what triggers the update of the source.
If the UpdateSourceTrigger value is PropertyChanged, then binding source gets updated as soon as the target property changes. If the UpdateSourceTrigger value is LostFocus, then that value only gets updated with the new value when the target property loses focus.

Data binding
converters
Data Conversion or Value Conversion is required when binding target needs data to be slightly tweaked from what it is currently. Value converters are purely part of binding target. Value converter must derive from IValueConverter or IMultiValueConverter.

Data binding
converters
Typical scenarios where it makes sense to implement a data converter:
Your data should be displayed differently, depending on culture. The data being used is not necessarily intended to change the text value of a property, but is instead intended to change some other value, such as the source for an image, or the color or style of the display text. More than one control or to multiple properties of controls are bound to the same data. In this case, the primary binding might just display the text, whereas other bindings handle specific display issues but still use the same binding as source information.

Model View-Model View

structure
Model-View-ViewModel (MVVM) pattern splits the User Interface code into 3 conceptual parts - Model, View and ViewModel.

Model - set of classes representing the data coming from the services or the database. View - code corresponding to the visual representation of the data the way it is seen and interacted with by the user. ViewModel - serves as the glue between the View and the Model. It wraps the data from the Model and makes it friendly for being presented and modified by the view. ViewModel also controls the View's interactions with the rest of the application (including any other Views).

Model View-Model View

structure
ViewModel code can (and should) refer to the Model, but the Model classes (if separate from the ViewModel) should not be aware of the ViewModel. View should be aware of the ViewModel, but ViewModel should be not aware of the View.

Model View-Model View

basic concepts
MVVM pattern became possible because of the following concepts: Bindings - Each binding connects two properties (possibly on two different objects) so that if one of them changes, the other changes too. Data Templates, which convert non-visual data (ViewModel) into its visual representation (View). Commands or Interactivity functionality (so called behavior) serve to pass the events from the Views to the ViewModels. Bindings, Commands and Interactivity behaviors provide the necessary plumbing for communications between the View and the ViewModel.

Model View-Model View

basic rules
Try to have minimum code behind.
View - supposed to have almost no code. Not even event handlers. This does not mean absolute zero code is a must, what I mean to say is that we should have minimum code behind. An exception would be cases like where the logic is pure View oriented (and is very specific to that view only) and has nothing to do with ViewModel or Model or even other Views of same ViewModel. Sometimes you have to use third party controls which are not MVVM compliant. In such cases too, you end up having some code behind.

All Events or actions should be treated as Command. ViewModel is the DataContext of View. Design ViewModel and View independent of each other.

Model View-Model View

basic rules
The Binding and C# Events are pointing from the ViewModel to the View even though, as stated above, the ViewModel is not aware of the View. The arrows on this diagram are pointing from an MVVM part that causes a change to the part which receives the change.
The Bindings are set within the View and even though the ViewModel is not aware of the View, the changes to the ViewModel still propagate to the View via the Bindings. Event handlers on ViewModel's events should also be set within the View's code behind, so that the View functionality will trigger a change when changes occur within the ViewModel.

Model View-Model View

commands
Command object, which is the way to handle events from View, derives from ICommand interface which has two important methods:
CanExecute method controls whether the corresponding control (e.g. Button or MenuItem) that is bound to this command is enabled or disabled Execute method specifies the action to be taken once the Button or MenuItem is clicked.

Commands have a shortcoming that they can only be attached to a few visual controls that have Command property, e.g. Button or MenuItem and they only fire on Click events.

Model View-Model View

behaviors
Behavior is much more generic in a sense that it allows to trigger corresponding methods on the ViewModel for almost any event that occurred on almost any visual element within the View.
Complicated UI interaction is moved away from code-behind and/or ViewModel. Behavior offers code reusability.

Behavior allows to abstract certain functionality from implementation. Behaviors are easy to use for UI Designer (Expression Blend)

Model View-Model View

behaviors

Model View-Model View

behaviors
Behaviors are invoked by a trigger
DataStoreChangedTrigger - invoke an action based on a modification to a data store DataTrigger - invoke an action based on the value of a databound property. EventTrigger - invoke an action based on an event such as a mouse click, a page loading, or another interaction. KeyTrigger - invoke an action when a combination of keys is pressed on the keyboard. PropertyChangedTrigger - invoke an action based on a modification to an element or a data store property. StoryboardCompletedTrigger - invoke an action after a storyboard has finished. TimerTrigger - invoke an action based on a timer.

Model View-Model View

The major advantage of the MVVM pattern is that it provides the best separation of concerns.
Under MVVM, View is in charge of the visual representation while the nonvisual ViewModel is in charge of all of the interactions with the rest of the software including the Model, the Services (usually via the Model) and the rest of the ViewModels.

advantages

Flexibility and Customization - Different Views can be used with the same ViewModels allowing completely different visual representations of the same functionality depending on what different customers want. Re-use - Because of the separation of Visual and non-Visual functionality, both the Views and the ViewModels have higher potential for re-use than if the Visual and non-Visual functionality were mixed, since e.g. a non-visual functionality usually would not be able to make use of a functionality that contains a Visual part to it.

Model View-Model View

advantages
Separation of the UI design and development - MVVM makes it possible to separate the work of the developer and the designer as clearly as possible:
at first the developer can produce an application with the crudest possible GUI. the designer, using designer tools will be able to modify the GUI (the Views) without touching any non-visual code.

Testing - Writing automated tests for a Visual application is not easy. The View - ViewModel separation allows the ViewModel to be unit tested without the view.
Since the ViewModel is in charge of the interactions with the rest of the application, such unit tests would cover the most important functionality while the View tests will only have to contain testing of the visual features, e.g. colors, animations, etc.

Model View-Model View

pitfalls
Dialog windows Possible solutions custom popup control bound to ViewModel message to View requesting showing popup

Model View-Model View

Useful MVVM Frameworks
Simple MVVM Toolkit for Silverlight, WPF and Windows Phone MVVM Light Toolkit nRoute: Now, More Wholesome

Build Your Own MVVM Framework

Q&A
??