In earlier posts on BuildIt.Lifecycle I’ve covered how changing state via the StateManager can trigger events that will cause changes in visual states on the corresponding page. With the Universal Windows Platform (UWP) we have visual state triggers which can be used to invoke state changes from within the view. For example an AdaptiveTrigger can cause a change in visual state based on the size of the window, which I covered in the post, Using the Universal Windows Platform SplitView Control with Visual States and BuildIt.Lifecycle. These two mechanisms of changing visual states are independent and thus would lead to an inconsistent experience when it comes to maintaining state. For example, if I update the AboutViewModel to include state definitions that modify a Data property, then when the state changes the value of Data will change between “Minimised” and “Expanded”
private string data;
public string Data
{
get { return data; }
set
{
data = value;
OnPropertyChanged();
}
}
public AboutViewModel()
{
StateManager
.Group<AboutExpandStates>()
.DefineState(AboutExpandStates.Minimised)
.Target(this)
.Change(x => x.Data, (x, c) => x.Data = c)
.ToValue(“Minimised”)
.DefineState(AboutExpandStates.Expanded)
.Target(this)
.Change(x => x.Data, (x, c) => x.Data = c)
.ToValue(“Expanded”);
}
If the application was to change state by invoking ChangeState on the StateManager, this would trigger the appropriate change in Visual State on the page. If the user were to resize the page, the AdaptiveTriggers would kick in, causing a change in the Visual State. However, this change wouldn’t be reflected in the StateManager, thus not updating the value of Data (ie would say “Minimised” when the SplitView was expanded, or saying “Expanded” when the SplitView was collapsed). Luckily the VisualStateGroup class in UWP raises a CurrentStateChanged event, which can be intercepted and used to route the update back in the StateManager. This has been added to BuildIt.Lifecycle to ensure consistence between the state of the StateManager and the corresponding visual states. In the same way as the name of each VisualState has to match the enumeration value, the name of the VisualStateGroup has to match the name of the enumeration itself.