In the developer preview of Windows 8, I just noticed a breaking change in the way that data bindings react to the PropertyChanged event.
First a bit of background: Often, objects that are databound to the UI are simple data objects (also called ViewModels) that implement the INotifyPropertyChanged interface. This interface is very simple and defines just one event, the PropertyChanged event, that needs to be raised by the ViewModel when one of its property changes. It is what makes the ViewModel “observable”. If a property of another object (typically a UI element) is data bound (through a Binding object, often set declaratively in XAML), then the value of the observing property will be synchronized to the value of the observable property.
Raising the PropertyChanged event requires an instance of the PropertyChangedEventArgs class, which takes a string as sole parameter of its constructor. The string to be passed is the name of the observable property.
Raising with string.Empty or null
In WPF and Silverlight, it is possible to raise the PropertyChanged event with an instance of the PropertyChangedEventArgs class constructed with string.Empty (or null) instead of an existing property’s name. When a PropertyChanged event is raised in this manner, the UI will re-query the value of each property of the ViewModel that is data bound to the UI. This is a convenient way to raise but one event and force the UI to update itself in response to cascading changes, for example. As such, this can be a good way to increase the performance of the application.
The breaking change in WinRT
However, while unit testing the version of MVVM Light for WinRT, I found out that raising the PropertyChanged event with an empty string or null does not update the bindings. I quickly coded a repro, and then coded the exact same code in Silverlight, and indeed the two applications do not react the same at all.
Hopefully this is only an oversight and this will be fixed in a future version.