Page 33 - MSDN Magazine, May 2019

elements may be required only during edge cases. In WPF, you have TemplatePartAttribute:
[TemplatePart (
Name = "EulaTextBlock", Type = typeof(TextBlock))]
public sealed class MyControl : Control { }
This syntax shows how the control can communicate internal dependencies to external developers. In this case, I expect a Text- Block with the name EulaTextBlock in my ControlTemplate. I can also specify the visual states I expect in my custom control:
[TemplateVisualState( GroupName = "Visual", Name = "Mouseover")]
public sealed class MyControl : Control { }
TemplatePart is used by Blend with TemplateVisualState to guide developers against expectations while creating custom templates. A ControlTemplate can be validated against these attributions. Since 10240, WinRT has included these attributes. UWP can use them, but Blend for Visual Studio doesn’t. These remain a good, forward- looking practice, but documentation is still the best approach.
Accessibility First-party XAML controls are meticulously designed and tested to be beautiful, compatible and accessible. Accessibility requirements are now first-class citizens and are release require- ments for every control.
Developers around the world love XAML because it’s so productive and flexible.
When you re-template a first-party control, you put at risk the accessibility features thoughtfully added by the development teams. These are difficult to get right, and simple to get wrong. When choosing to re-template a control, you should be well-versed in the accessibility capabilities of the framework and in the tech- niques to implement them. Otherwise, you lose a considerable portion of their value.
Adding accessibility as a release requirement helps not only those with permanent disabilities, but also those who are tem- porarily incapacitated. It also reduces risk when re-templating first-party controls.
You Did It!
After upgrading from a user control to a templated control, I intro- duced very little new code. But I’ve added a lot of functionality. Let’s consider what’s been accomplished overall.
Encapsulation. The control is a collection of several controls, bundled with custom visuals and behaviors that consuming devel- opers can reuse with ease across an application.
Business logic. The control incorporates business rules that ful- fill the acceptance criteria of the user story. I’ve put immutable rules close to the control and supported a rich design-time experience, too.
Custom events. The control exposes control-specific custom events like “click” that help developers interoperate with the control, without requiring them to understand the internal structure of the layout. msdnmagazine.com
Custom properties. The control exposes properties to allow the consuming developer to influence the content of the layout. This has been done in a way to fully support XAML data binding.
API syntax. The control supports an intuitive approach that allows developers to declare their content with literal strings and in a straightforward way. I leveraged the ContentProperty attri- bute to do this.
Templates. The control ships with a default ControlTemplate that lays out an intuitive interface. However, XAML re-templating is supported to allow consumer developers to customize the visuals as needed.
There’s More to Do
My control needs more, but not much more— just a little attention to layout (like the need to scroll large text) and a few properties (like the content of the checkbox). I’m amazingly close.
Controls can support Visual State Management, a native fea- ture of XAML that allows properties to change based on sizing events or framework events (like mouseover). Mature controls have visual states.
Controls can support localization; the native capability in UWP uses the x:Uid directive associating controls with RESW strings that are filtered by the active locale. Mature controls support localization.
Controls can support external-style definitions to help update their visuals without requiring a new template; this can involve shared visuals and leverage themes and BasedOn styles. Mature controls share and reuse styles.
Wrapping Up
Prototyping a UI in XAML is fast. User controls create simple, reusable layouts easily. Templated controls require a bit more work to create simple, reusable layouts with more sophisticated capa- bilities. The right approach is up to the developer, based on a little knowledge and a lot of experience. Experiment. The more you learn the tooling, the more productive you’ll become.
Windows Forms succeeded Visual Basic 6 in 2002, just as WPF succeeded Windows Forms in 2006. WPF brought with it XAML: a declarative language for UI. Microsoft developers had never seen anything like XAML. Today, Xamarin and UWP bring XAML to iOS, Android, HoloLens, Surface Hub, Xbox, IoT and the modern desktop. In fact, XAML is now the technology building the Windows OS itself.
Developers around the world love XAML because it’s so productive and flexible. Microsoft engineers feel the same; we’re building our own apps and even Windows 10 with XAML. The future is bright, the tooling is powerful and the technology is more approachable than ever. n
Jerry NixoN is a senior software engineer & lead architect in Commercial Software Engineering at Microsoft. He has developed and designed software for two decades. Speaker, organizer, teacher and author, Nixon is also the host of DevRadio. Most of his days are spent teaching his three daughters “Star Trek” backstories and episode plots.
ThaNks to the following Microsoft technical experts for reviewing this article: Daniel Jacobson, Dmitry Lyalin, Daren May, Ricardo Minguez Pablos
May 2019 27