Over the years I’ve written my fair share of BooleanToVisibilityConverter classes. The are so drop dead to implement if you are bootstrapping a small project or proof-of-concept it almost doesn’t make sense to add a nugget package just to bring in a standard BooleanToVisibilityConverter. However, after using the UWP Toolkit’s implementation, I might just change my tune.
I don’t know how I didn’t know this but Converters can have state manipulated through the XAML using Dependency Properties. I guess I always assumed that because converters are typically new’d up each time they are used thanks to the StaticReference markup extension being used to inject an instance of them into the Converter object on a data binding I figured that you couldn’t really do construct-time initialization. Boy was I wrong! The implementation is so elegant I can’t believe I didn’t question my assumptions sooner!
A common pattern when using the BooleanToVisibilityConverter is to invert it. When I would roll my own, my implementation would take the crude form of type casting the ConverterParameter object to a string and then parsing a Boolean out of it. However, now that I finally realized converters can utilize Dependency Properties the implementation in the UWP toolkit just makes perfect sense.
They actually inherit from a base class called BoolToObjectConverter that provides two dependency properties of type object. One value is the object used when the Boolean value is true and one object is used when the Boolean value is false. The BoolToVisibilityConverter sub class simply specifies a Visibility value of Visible and Collapsed for the TrueValue and FalseValue dependency properties, respectfully.
What did I tell you? Super elegant.
This means that in my resources I just need to instances of the converter.
One normal one:
And another that inverts the visibility values:
This allows me to easily implement passive error message conditions to the user. I implemented this on the UWP Blob Storage Explorer app that I built and published in the store. Here I only attempt to render the list of containers if the Storage Account object’s IsConnected flag is true.
If not, I display a TextBlock that tells the user that we had trouble connecting to the storage account.
In both cases, I bind to the same StorageAccount.IsConnected property but since the visibility states are mutually exclusive, I use different converters to convert the Boolean value into the appropriate visibility.
There really isn’t any down side that I can think of to this approach. Since we’re using StaticResource anyway, using a single converter class and the Converter Parameter doesn’t reduce the number of objects constructed and stored into memory. However, using the Dependency Property approach eliminates the type casting and string parsing that I would’ve used in my old implementation to do the same job.
Here’s the final result in the UI:
Such an elegant platform. Sigh. If only more people used it. 😊