Windows Presentation Foundation (WPF): introduction & overview (useful for system administrators and engineers)
Most articles about WPF start straight away with WPF code, trying to get you started as soon as possible. The problem is those articles don’t start with some basic and sometimes even necessary theory, so readers don’t get a real grip on what exactly they’re doing. Heck, many of those articles don’t even mention those basics at all, leaving readers alone without awareness of the context they’re programming in and that’s more than a pity of course. Other readers are not interested in WPF programming itself, but would like to get an idea of what WPF is, how it works and how to deal with it; system administrators and engineers for example.
So, if you’re looking for an introduction to and overview of Windows Presentation Foundation (WPF) without real programming involved, then you’re at the right place. This article supposes you already know how .NET Framework works and what the most basic concepts are (like the Common Language Runtime (CLR) for example). If you don’t have a clue what I’m talking about, please look for an introduction to the .NET Framework first. If you do know what I’m talking about and you want a basic introduction to and overview of WPF without the focus on the programming itself, then be my guest and read on. Programming content itself is barely present in this article, except for a few examples.
Ok, a very brief introduction to the .NET Framework anyway
As you probably know the .NET Framework is a framework providing us with a virtual application platform, just like the Java framework does. This makes applications for this platform portable across different lower-level systems (well, at least within certain boundaries, but I’m not going into details here). The framework supports 2 big types of applications:
• Windows applications. There are 2 subtypes:
–> User Windows applications. This is the most traditional type of application: a “classic” Windows application interactively controlled by users and containing at least one executable (.exe file). In .NET those applications are known as the so-called Windows Forms applications. They come in two flavors:
—-> Console Windows applications. Such an application runs in a command line environment.
—-> GUI Windows applications. Such an application has a Graphical User Interface (GUI).
–> Windows services. This is a background application, typically non-interactive, and doing stuff on its own and/or waiting to offer services to consumer applications (like a GUI application for example).
• Web applications. There are 2 subtypes:
o WUI based web applications. These are web applications hosted by a web server and interactively controlled by the user through a web browser. They contain a Web User Interface (WUI) and are known in .NET as Web Forms applications. They could be considered the web edition of GUI Windows applications.
o web services: those are the web equivalent of Windows services offering services to consumer applications (GUI applications for example) and are also not meant to be used interactively by a user, well, at least not directly. A web service itself doesn’t contain a user interface (UI).
.NET web applications must be supported by the web server: the web server should know how to handle them. The sub-framework of .NET Framework taking care of this is called ASP.NET, the “.NET variant” of the server side script based Active Server Pages (ASP).
Those applications can be written in different .NET languages, like C# (pronounced C sharp) and Visual Basic (VB). Writing the source code, compiling, debugging,… can occur with different tools. Most of the time though a complete solution is used, a so-called Integrated Development Environment (IDE). The most famous and used IDE is Visual Studio (VS), the last version being 2010. Oh yeah, the last version of the .NET Framework is 4.0 by the way. Anyway, software like VS doesn’t limit developing to the basic tasks, but also provides us with many, many extra utilities and shortcuts. For example, VS contains a designer to assemble your GUI instead of programming every bit of it directly with code. This designer isn’t part of a language or framework, but is a feature VS itself.
Every type of application must be created by following certain rules defined by the .NET Framework. The framework also contains classes specific to certain of these application types to make development of the different application types more straightforward.
Starting with .NET Framework 3.0 things started to change a little bit. Three big new .NET technologies were introduced:
• Windows Presentation Foundation (WPF)
• Windows Communication Foundation (WCF)
• Windows Workflow Foundation (WF) (no, this isn’t a typo: it’s WF, not WWF)
Those are not new languages, tools/IDEs, main frameworks or new application types (well, not in the sense we have just categorized them). Those technologies actually describe new, alternative rules and means to create some application types in a different way, but still under the wings of the same .NET Framework and still by using the same programming languages. Some of those rules and means include new classes specific to those new technologies and also some new auxiliary languages. Windows Communication Foundation (WCF) for example gives us a new way of creating applications containing some sort of service; this is especially useful for web services of course. But let’s make myself more clear with another example: WPF.
Windows Presentation Foundation (WPF)
A classical GUI application can be coded directly by a developer from scratch or a tool/IDE can be used to bypass and ease a few of those pieces. For example, you could design your GUI with a built-in designer in Visual Studio. This shortcut is a feature of VS, not of one of the languages (like C#) or the .NET Framework itself.
That same GUI application can be coded in a different way starting with .NET Framework 3.0, i.e. with WPF (although WPF can also be used to code WUI applications in a different way, but let’s keep it with one example for now). With WPF some pieces can be implemented by different means, for example by describing some aspects with one or more configuration files. Also, some special WPF classes can be used, doing stuff slightly different than more traditional classes. Those “shortcuts” or “different means”, and they related rules, make part of the WPF technology itself and thus of the .NET Framework (this way we could see WPF as a sub-framework of the .NET Framework). Software like Visual Studio provides us with even a few more shortcuts to make the developing experience even more easier/different, while still staying within the WPF boundaries.
You see, you still make one of the forementioned application types (a GUI application for example), you still use one of the already existing languages (like C# for example) and you still use the same software (like VS for example). It’s just the way you do it that differs and this way consists of “shortcuts” and extra auxiliaries that belong to the technology itself.
Aside of the special WPF classes, the use of configuration files is probably the most important piece of WPF. Those configuration files are actually XML files (Extensible Markup Language) of the XAML type. XML is actually a language for, well, languages 🙂 One of those languages designed within the XML boundaries, called XML applications, is HTML. Another one is Extensible Application Markup Language (XAML; pronounced zammel). With XAML you describe different aspects of your application and Visual Studio processes this to make real code at compile time. Something very important you can do with XAML is declaring UI controls and describing them. XAML works in a hierarchical way (which is of course very typical for XML), so you will see a lot of XML elements containing XML child elements. Oh yeah, for traditional ASP.NET WUI applications you also use some configuration files, which are also XML based, i.e. the aspx files, where pieces of HTML are used. The difference with XAML is that XAML does go a lot further and isn’t limited to WUI applications.
The benefits of XAML are obvious: for some pieces you don’t need to write real code anymore. While writing XAML isn’t always that easy, it’s still more straightforward than writing code. It also bundles different properties and behaviors together, like it’s some administrative and summarized overview. Because writing XAML doesn’t require real developing skills and because you can separate many properties and behaviors from real code, this is an ideal system to let designers do their thing and let developers take over later to write the actual functionality in code. Perhaps this seems still a little bit too much for designers, but you should definitely change your mind if you know that software like VS, but especially Expression Blend (EB) provides us with extra shortcuts, i.e. designers. This way designers and digital artists could easily define user interfaces, graphics and the like by use of Expression Blend and finetune a little bit in XAML itself, before developers take over and finetune XAML even a little bit more and add functionality in real code.
Because this is the strength of WPF, it’s quite clear WPF is especially useful in scenarios where more graphical applications are desired, where designers should build the UI and developers add the functionality. Another benefit of WPF is WPF applications need very few adaptations to switch between GUI and WUI based applications. You could write a GUI application in WPF and with a few minor changes the same application is ready to behave as a web application. Also, when heavy graphical requirements are needed, WPF can be a huge relief: not only designing the application is much easier this way, but WPF is also able to make use of graphics card’s features through DirectX 7 or later. If the gfx chipset can’t deal with the things a WPF application asks, .NET Framework 4 can take over with some kind of fallback rendering system, although this implies a reduced performance of course. Anyway, the graphical power of WPF and especially the ease of designing and programming this leads to a much more graphical presence of GUI and WUI applications. Note that WPF is especially targeted at systems running Vista and upwards, although it’s perfectly possible to run WPF apps on older systems, with Windows XP for example.
In most cases traditional programming is very often still the choice number one though. You shouldn’t use WPF just because it’s new. Only for the following main reasons WPF should be typically preferred over traditional ways:
• Heavy graphical capabilities are required
• Designers should do as much as possible first and developers should add functionality later
• Portability between GUI and WUI environments is very important
If you think you’ve never heard of WPF before, you’re probably wrong. There is very famous light version of WPF you must certainly have heard of: Silverlight. It’s a subset of the WPF technology and targets a more broad public of designers and developers than the full WPF; a subset typically means it’s easier and more convenient, so this shouldn’t sound as a surprise. Silverlight is especially known for very graphical web content, sometimes containing some kind of application kind content too, and Silverlight creations can be found as components on several web sites. What many people don’t really realize is that Silverlight content pieces are actually real applications, even if the real functionality part can be quite limited sometimes; that’s why the term “Silverlight applications” is completely justified. Silverlight is comparable to Flash, from Adobe.
A little bit of technical information
Every configuration file is a .xaml file. Behind a XAML file there is a code file (the so-called code-behind file), which is in the case of C# a .cs file. Describing pieces of your application is done in the .xaml file and the actual direct coding happens in the code-behind file. Actually there is a 2nd code-behind file, one that is not meant for developers to use: the file that contains the code automatically derived from the XAML document. The 2 code-behind files together form the final and actual coding logic.
In a way we could say there are 3 tiers here:
• The code files: the actual and final things, the only things that really matter at the end
• The XAML files: describing higher level views for a part of the coding files
• The designer files: another “even higher”-level view wherein designers/developers drag and drop stuff, while the software automatically converts it to XAML (and later to code). Remember this tier is not part of WPF itself, but is something tools and IDEs provide as an extra “utility”.
Software designers are typically found back in the IDE, but in practice (human) designers don’t use them often, because, well, it’s part of an IDE: (human) designers don’t like to use development software That’s why extra software has been published, like Expression Blend (EB). The results can then be imported in the IDE (like VS) and used further by developers. If necessary developers can still change a few things with the IDE’s designers (or even in EB if they really want). Don’t forget though that EB’s help is far more advanced then VS’s help, which is quite logic of course.
Things that can’t be done with software designers can be changed by (human) designers and developers in the XAML document(s). The code file (tier 1) that relates to this XAML document (tier 2) is normally not touched by developers or designers. The other code file, containing the stuff that must be coded directly, which is typically the real functionality, is modified by developers though, most of the time in a later phase. Of course this way of working is quite academic, default and theoretic, but in a nutshell it describes the typical way of WPF designing/developing.
GUI applications always have a “Window” XML root element in XAML documents describing windows, while WUI applications have a “Page” XML root element in XAML documents describing “web windows” (well, pages). Each XML element represents some object, which has some properties, normally configured with XML attributes. Hierarchical “deeper” objects are put in the XAML document as XML child elements. Note that complex object properties are actually used as XML elements too; so only simple properties are described by XML attributes. You can distinguish complex properties from child objects by taking a look at the name of the XML element:
• PARENT.PROPERTY: the property name is prefixed by the object name (the name of the parent XML element) and a dot, so we’re dealing with complex properties of that object
• OBJECT: if this prefix isn’t there, then the child XML element represents a child object
This can be quite confusing in the beginning, as psychologically every lower level (every XML child element) gives us the impression we’re dealing with a new child object. Having a quick look at a XAML document can thus give us a wrong impression, we really have to read the names of XML elements well and concentrate. Don’t worry though, after a while you do this by default
Anyway, the way objects are located in a XAML document (parent/child objects through parent/child XML elements) is called the object element syntax. The way simple object properties are described in XAML (through XML attributes) is called the attribute syntax. Complex object properties are described by XML elements too, called the property element syntax. Many objects, often UI controls, can contain content, making them content presenters. Actual content is described by the content syntax. Simple content is placed between an opening and closing tag. This means we can have the following between an opening and closing tag, even at the same time:
• Simple content
• Complex object properties
Simple content must be described contiguously, but complex object properties not. This means we can do the following if both types must be present:
• All the simple content, followed by all the complex object properties
• All the complex object properties, followed by all the simple content
• A piece of complex object properties, followed by all the simple content, followed by the rest of the complex object properties
Complex content is described by still other ways, but this is outside the scope of this article.
Something very important in WPF are events (in the broad sense). Low-level events (the classical events) still exist, but extra higher-level events are introduced with WPF, making WPF very powerful to react on things. One special type of event is a routed event. Such an event takes place at multiple hierarchical levels, going down (called tunneling) and then up again (called bubbling). For example, when you click a button, a routed event could trigger an event on the window level, then on the button level, again on the button level and ultimately again on the window level. Speaking of control… Something even more higher level is a trigger. This most high level type of event is easy to create by even designers, which makes developing an application extremely powerful.
The way WPF works, is very componentized and hierarchical. This is especially the case for user interfaces. WPF provides us with several building blocks, that can be used to divide the user interface in pieces with certain properties. Those building blocks (layout controls) all derive from a class called Panel; perhaps you have already heard of some of them:
You can bundle several properties together into styles and templates. These form reusable development blocks and make design and development oh so much easier.
Another great thing in WPF is the support for animations. Those are created by so-called storyboards, containing timelines. Timelines exist with and without key frames, which divide a timeline in pieces. Key frames on their turn exist in different flavors, each with their own typical properties.
GUI WPF applications are compiled to at least one executable (.exe file), while WUI WPF applications are compiled to at least an .xbap file (pronounced ex-bap). The last extension is an acronym for XAML Browser Application.
WPF has many more strengths and much more could be said about how WPF works. A lot of those things don’t really fit in an introduction and non-programming article though: attached properties, attached events, dependency properties, static and dynamic resources, etc. I did want to stress the fact that WPF is XML based, componentized and very graphical though. With this I want to close my monologue about the somewhat more technical aspects of WPF.
I hope non-programmers know now what WPF is, why it’s around and what the typical properties of this technology are. Especially for Windows administrators, engineers and perhaps even architects this could be very important and difficult to find information. So if a developer wants you to set up new WPF application servers or publish new WPF apps again, don’t just pretend you know what he’s talking about: now you do know what he’s talking about! And if a developer says his WPF app has failed because of the Windows server team’s fault, don’t just believe him and try to discuss everything with him: you do own some basic knowledge about WPF now! Use it and control your developers 🙂