Super Productivity: Using WPF and Silverlight’s Automatic Layout Features in Business Applications

Silverlight and WPF both are User Interface technologies that allow developers and designers to create amazing user interface experiences.

This apparently leads a lot of people to the conclusion that UI creation in these environments must be a complex and time consuming undertaking. I often hear, “I can do things so much faster in WinForms.” Yet nothing could be further from the truth! Using appropriate techniques, UI development should be much faster in WPF and Silverlight. Unfortunately, many such techniques often are overlooked as developers have settled into old UI paradigms, and new paradigms are misunderstood. This article discusses one such technique that can be used with equal success both in WPF and Silverlight. When applied properly, this technique allows for user interface development not just much faster, but also in a much more reusable and maintainable and yet less error prone way. I challenge anyone to come up with a faster UI development approach than outlined here, regardless of the utilized technology or platform!

WPF and Silverlight (which I will use interchangeably, as the techniques discussed in this article apply to both) introduce some very intriguing user interface paradigms. Unfortunately, many of these paradigms often go dismissed as “not applicable to my development effort,” or “not applicable to business applications.” Styling comes to mind as a primary example. Developers generally tend to think of styling as a way to create a graphically designed consumer experience. In reality, however, styling is a technique that allows for generic and interchangeable external definition of property settings. Of course, developers set a lot of properties, so why would styling, which is all about setting properties productively, not be applicable to development and only be thought of as a designer task? I suppose the word “style” is a poor choice of terms in this sense, as it carries a graphical connotation, but whoever is “in the know” about styles understands that this is a very useful feature for business application development.

Another example of a misunderstood WPF/SL paradigm is “layout elements.” Both WPF and Silverlight support an interesting list of layout options (with “layout” being the task of positioning UI elements on a window or other surface). Layout elements allow the developer to position controls inside of a “layout container” (such as a Grid, among many others) and have the system perform automatic arrangements of elements. Concepts such as “fixed positioning of controls” or “flow layout” or “stacks of elements” and much more are supported natively, and new layout elements can be created with ease. However, most developers stick to one or two of those elements (commonly the Grid and StackPanel elements) and ignore the vast potential custom layout can provide.

A Naïve Example

Let’s start with some layout basics. Let’s say we want to create a typical data entry form. The second most naïve approach (I am deliberately ignoring the most naïve approach of putting things into a Canvas, in the hope the world has moved beyond that pitfall) is to put elements inside a Grid and position the elements using margins and alignment. Listing 1 shows a simple user control (or Window) for a data interface. This code, in fact, is not entirely unlike the paradigm used in WinForms and many other rich-client UI environments: We put controls into some sort of UI container and position them by defining left and top positions as well as control height and width. (Left and top positions are expressed as margins in the case of a Grid layout element, but the idea remains the same.) Note that sometimes, default values work and do not have to be explicitly specified, as in the case of the height and width of text blocks (which simply means that these values are still there but the system handled them for us).

You may have never really thought about what happens here, but let’s take a minute to reflect on how this code results in the UI shown in Figure 1. There really are at least three completely different types of information carried in this interface definition. First, XAML is used to define which controls we desire (text blocks and text boxes in this simple example). This provides quite a bit of business value and is part of the core problem we are trying to solve when we define an interface (“which controls should be used to show different elements of information?”). The second part of interest is that we bind elements to data. This is also a core business value we provide (“which data should be displayed and manipulated?”). Third, we are defining the details of the layout of the UI. In this example, I do this by setting margins as well as alignments. The alignments ensure that WPF understands that all control positions are to be relative to the top left edge, and no automatic resource logic of any kind is desired. (I took a shortcut of putting the alignment information into local resources as styles, since I didn’t feel like typing it for every control.)

This, of course, begs the question “What business value was delivered by defining layout information (the third aspect)?” And frankly, the answer is “very little.” This simply is an annoying detail we must deal with in order to create any kind of useful UI. It is time consuming (setting the right positions was by far the part that took me the longest in this example) and it is annoying (most developers hate it, and are not good at creating good looking UI layouts). It is also error prone. Furthermore, the UI we created so far is not very “WPF-ish” in the sense that it can’t do any resizing or any other fancy WPF stuff. Change the style of text elements to use a larger font throughout the app, and all of a sudden, our labels overlap the textboxes! It is also not very reusable. Try moving this UI to Windows Phone 7 and you will probably notice that although it works, it isn’t very useful and probably doesn’t fit on the screen at all.

So that’s a bit of a bummer, isn’t it? The majority of the time I spent creating this example went towards an annoying task that provided practically no business value, and created a result that is not very reusable and not very functional. Furthermore, I created this entire UI entirely by hand. Most people would probably want to use some sort of visual designer. If you do that, your XAML will probably contain a lot more code than shown in Listing 1. Most of it probably not being what you really want (changes are the controls towards the bottom of the UI are aligned relative to the bottom - a choice automatically made by the design tool - creating very odd results when the user resizes the screen). I often have people tell me that this is one of the greatest frustrations they face when working with WPF. Clearly, this needs to be fixed!

By: Markus Egger

Markus is the founder and publisher of CODE Magazine and EPS' President and Chief Software Architect. He is also a Microsoft RD (Regional Director) and the one of the longest (if not THE longest) running Microsoft MVPs (Most Valuable Professionals). Markus is also a renowned speaker and author.

Markus' spends most of his time writing production code. The projects Markus has worked on include efforts for some of the world's largest companies including many Fortune 500 companies. Markus has also worked as a contractor for Microsoft (including the Visual Studio team). Markus has presented at many industry events, ranging from local user groups to major events such as MS TechEd. Markus' written work has been published extensively and in magazine ranging from MSDN Magazine, to Visual Studio Magazine, and of course in Markus' own CODE Magazine and much more. Markus is a supporter of communities in North America, Europe, and sometimes even beyond.

Markus currently focuses on development in .NET (Windows, Web, Windows Phone, and WinRT) as well as Android and iOS. He is passionate about overall application architecture, SOA, user interfaces and general development productivity and building maintainable and reusable systems.

In his spare time, Markus is an avid windsurfer, scuba diver, ice hockey player and world traveler. On a rainy day, he is known to enjoy a good game on his PC or Xbox.

megger@eps-software.com