1. The Motivation Behind WPF
Over the years,
Microsoft has created numerous graphical user interface toolkits (raw
C/C++/Windows API development, VB6, MFC, etc.) to build desktop
executables. Each of these APIs provided a code base to represent the
basic aspects of a GUI application, including main windows, dialog
boxes, controls, menu systems, and other basic necessities. With the
initial release of the .NET platform, the Windows Forms API quickly
became the preferred model for UI development, given its simple yet very
powerful object model.
While many full-featured
desktop applications have been successfully created using Windows Forms,
the fact of the matter is that this programming model is rather asymmetrical. Simply put, System.Windows.Forms.dll and System.Drawing.dll
do not provide direct support for many additional technologies required
to build a feature-rich desktop application. To illustrate this point,
consider the ad hoc nature of GUI development before the release of WPF
(e.g., .NET 2.0; see Table 1).
Table 1. .NET 2.0 Solutions to Desired Functionalities
| Desired Functionality | .NET 2.0 Solution |
|---|
| Building windows with controls | Windows Forms |
| 2D graphics support | GDI+ (System.Drawing.dll) |
| 3D graphics support | DirectX APIs |
| Support for streaming video | Windows Media Player APIs |
| Support for flow-style documents | Programmatic manipulation of PDF files |
As you can see, a Windows
Forms developer must pull in types from a number of unrelated APIs and
object models. While it is true that making use of these diverse APIs
may look similar syntactically (it is just C# code, after all), you may
also agree that each technology requires a radically different mind-set.
For example, the skills required to create a 3D rendered animation
using DirectX are completely different from those used to bind data to a
grid. To be sure, it is very difficult for a Windows Forms programmer
to master the diverse nature of each API.
1.1. Unifying Diverse APIs
WPF (introduced
with .NET 3.0) was purposely created to merge these previously unrelated
programming tasks into a single unified object model. Thus, if you need
to author a 3D animation, you have no need to manually program against
the DirectX API (although you could), as 3D functionality is baked
directly into WPF. To see how well things have cleaned up, consider Table 2, which illustrates the desktop development model ushered in as of .NET 3.0.
Table 2. .NET 3.0 Solutions to Desired Functionalities
| Desired Functionality | .NET 3.0 and Higher Solution |
|---|
| Building forms with controls | WPF |
| 2D graphics support | WPF |
| 3D graphics support | WPF |
| Support for streaming video | WPF |
| Support for flow-style documents | WPF |
The obvious benefit here is
that .NET programmers now have a single, symmetrical API for all common
GUI programming needs. Once you become comfortable with the
functionality of the key WPF assemblies and the grammar of XAML, you'll
be amazed how quickly you can create very sophisticated UIs.
1.2. Providing a Separation of Concerns via XAML
Perhaps one of the most
compelling benefits is that WPF provides a way to cleanly separate the
look and feel of a Windows application from the programming logic that
drives it. Using XAML, it is possible to define the UI of an application
via XML markup.
This markup (ideally generated using tools such as Microsoft Expression
Blend) can then be connected to a managed code base to provide the guts
of the program's functionality.
NOTE
XAML is not limited to
WPF applications! Any application can use XAML to describe a tree of
.NET objects, even if they have nothing to do with a visible user
interface. For example, the Windows Workflow Foundation API uses a
XAML-based grammar to define business processes and custom activities.
As you dig into WPF, you may
be surprised how much flexibility "desktop markup" provides. XAML allows
you to define not only simple UI elements (buttons, grids, list boxes,
etc.) in markup, but also 2D and 3D graphical data, animations, data
binding logic, and multimedia functionality (such as video playback).
For example, defining a circular button control that animates a company
logo requires just a few lines of markup.
WPF controls can be modified through styles and templates, which allow
you to change the overall look and feel of an application with minimum
fuss and bother. Unlike Windows Forms development, the only compelling
reason to build a custom WPF control library is if you need to change
the behaviors
of a control (e.g., add custom methods, properties, or events; subclass
an existing control to override virtual members). If you simply need to
change the look and feel of a control (again, such as a circular animated button), you can do so entirely through markup.
1.3. Providing an Optimized Rendering Model
GUI toolkits such as Windows
Forms, MFC or VB6 preformed all graphical rendering requests (including
the rendering of UI elements such as buttons and list boxes) using a low
level, C-based API (GDI) which has been part of the Windows OS for
years. GDI provides adequate performance for typical business
applications or simple graphical programs; however, if a UI application
needed to tap into high performance graphics, DirectX was required.
The WPF programming model is quite different in that GDI is not
used when rendering graphical data. All rendering operations (e.g., 2D
graphics, 3D graphics, animations, UI widget renderings buttons, list
boxes) now make use of the DirectX API. The first obvious benefit is
that your WPF applications will automatically take advantage of hardware
and software optimizations. As well, WPF applications can tap into very
rich graphical services (blur effects, anti-aliasing, transparency,
etc.) without the complexity of programming directly against the DirectX
API.
NOTE
Although WPF does push all
rendering requests to the DirectX layer, I don't want to suggest that a
WPF application will perform as fast as building an application using
unmanaged C++ and DirectX directly. If you are build a desktop
application that requires the fastest possible execution speed (such as a
3D video game), unmanaged C++ and DirectX are still the best approach.
1.4. Simplifying Complex UI Programming
To recap the story thus far,
Windows Presentation Foundation (WPF) is an API to build desktop
applications that integrates various desktop APIs into a single object
model and provides a clean separation of concerns via XAML. In addition
to these major points, WPF applications also benefit from a very simple
way to integrate services into your programs, which historically were
quite complex to account for. Here is a quick rundown of the core WPF
features:
A number of
layout managers (far more than Windows Forms) to provide extremely
flexible control over placement and reposition of content.
Use of an enhanced data-binding engine to bind content to UI elements in a variety of ways.
A built-in style engine, which allows you to define "themes" for a WPF application.
Use
of vector graphics, which allows content to be automatically resized to
fit the size and resolution of the screen hosting the application.
Support for 2D and 3D graphics, animations, and video and audio playback.
A
rich typography API, such as support for XML Paper Specification (XPS)
documents, fixeddocuments (WYSIWYG), flow documents, and document
annotations (e.g., a Sticky Notes API).
Support
for interoperating with legacy GUI models (e.g., Windows Forms,
ActiveX, and Win32 HWNDs). For example, you can incorporate custom
Windows Forms controls into a WPF application, and vice versa.
Now that you have some idea
of what WPF brings to the table, let's turn our attention to the various
types of applications that can be created using this API.
2. The Various Flavors of WPF
The WPF API can be used to
build a variety of GUI-centric applications that basically differ in
their navigational structure and deployment models. The sections that
follow present a high-level walk through each option.
2.1. Traditional Desktop Applications
The first (and most familiar)
option is to use WPF to build a traditional executable assembly that
runs on a local machine. For example, you could use WPF to build a text
editor, painting program, or multimedia program such as a digital music
player, photo viewer, and so forth. Like any other desktop applications,
these *.exe files can be
installed using traditional means (setup programs, Windows Installer
packages, etc.) or via ClickOnce technology to allow desktop
applications to be distributed and installed via a remote web server.
Programmatically speaking, this type of WPF application will make use (at a minimum) of the Window and Application types, in addition to the expected set of dialog boxes, toolbars, status bars, menu systems, and other UI elements.
Now, you can certainly use WPF to build your basic, bland business
application that does not support any bells and whistles, but WPF really
shines when you do incorporate such features. Consider Figure 1, which shows a WPF sample desktop application for viewing patient records in a medical environment.
Sadly, the printed page does
not show the full feature set of this window. Note that the upper right
of the main window is displaying a real time graph of the patient's
sinus rhythm. If you click on Patient Details button on the lower right,
several animations take place to flip, rotate and transform the UI to
the following look and feel (Figure 2).
Could you build this same
application without WPF? Absolutely. However, the amount of code—and the
complexity of the code—would be much higher.
NOTE
This example application can be downloaded (with source code) from the office WPF web site, http://windowsclient.net. Here you will find numerous WPF (and Windows Forms) sample projects, technology walkthroughs and forums.
2.2. Navigation-Based WPF Applications
WPF applications can
optionally choose to make use of a navigation-based structure, which
makes a traditional desktop application take on the basic behavior of a
web browser application. Using this model, you can build a desktop *.exe that provides a "forward" and "back" button that allows the end user to move back and forth between various UI displays called pages.
The application itself
maintains a list of each page and provides the necessary infrastructure
to navigate between them, pass data across pages (similar to a web-based
application variable), and maintain a history list. By way of a
concrete example, consider Windows Explorer (see Figure 3),
which makes use ofsuch functionality. Notice the navigation buttons
(and history list) mounted on the upper-left corner of the window.
Regardless of the fact that a
WPF desktop application can take on a weblike navigational structure,
understand that this is simply a UI design issue. The application itself
is still little more than a local executable assembly running on a
desktop machine, and it has little to do with a web application beyond a
slightly similar look and feel. Programmatically speaking, this type of
WPF application is constructed using classes such as Application, Page, NavigationWindow, and Frame.
2.3. XBAP Applications
WPF also allows you to build applications that can be hosted within
a web browser. This flavor of WPF application is termed an XAML browser
application, or XBAP. Under this model, the end user navigates to a
given URL, at which point the XBAP (which is essentially a collection of
Page objects) is transparently
downloaded and installed to the local machine. Unlike a traditional
ClickOnce installation for an executable application, however, the XBAP
program is hosted directly within the browser and adopts the browser's
intrinsic navigational system. Figure 4
illustrates an XBAP program in action (specifically, the ExpenseIt WPF
sample program that ships with the .NET Framework 4.0 SDK).
The benefit of an XBAP is that
it allows you to create sophisticated UIs which are much more expressive
than a typical web page built with HTML and JavaScript. An XBAP Page
object can make use of the same WPF services as a desktop WPF
application, including animations, 2D and 3D graphics, themes and
whatnot. In effect, the web browser is just a container for WPF Page objects, and is not displaying ASP.NET web pages.
However, given that these Page
objects are deployed to a remote web server, XBAPs can be easily
versioned and updated without the need to redeploy executables to the
user's desktop. Like a traditional web program, you can simply update
the Page objects in the web server, and the user will get the 'latest and greatest' when they access the URL.
One downside to this flavor
of WPF is that XBAPs must be hosted within Microsoft Internet Explorer
or Firefox web browsers. If you are deploying XBAPs across a company
intranet, browser compatibility should not be a problem, given that
system administrators can play dictator regarding which browser should
be installed on users' machines. However, if you want the outside world
to make use of your XBAP, it is not possible to ensure each end user is
making use of Internet Explorer/Firefox, and therefore some external
users may not be able to view your WPF XBAP.
Another issue to be aware of
is the machine which is viewing an XBAP must have a local installation
of the .NET framework, as the Page objects
will be using the same .NET assemblies as an application running
natively on the machine. Given this particular point, XBAPs are limited
to Windows operating systems and thus cannot be viewed on a system
running Mac OS X or Linux.
2.4. The WPF/Silverlight Relationship
WPF and XAML also provide the
foundation for a cross-platform, cross-browser WPF-based technology
termed Silverlight. From a high level, you can consider Silverlight as a
competitor to Adobe Flash, with the benefit of using C# and XAML rather
than a new set of tools and languages. Silverlight is a subset of WPF
functionality, which is used to build highly interactive plug-ins for a
larger HTML-based web page. In reality, however, Silverlight is a
completely unique distribution of the .NET platform, which ships with a
"mini" CLR and "mini" version of the .NET base class libraries.
Unlike an XBAP, the user's
machine does not need a full installation of the .NET Framework. As
long as the target machine has the Silverlight runtime installed, the
browser will load the Silverlight runtime and display the Silverlight
application automatically. Best of all, Silverlight plug-ins are not
limited to the Windows operating systems! Microsoft has also created a
Silverlight runtime for Mac OS X.
With Silverlight, you are able
to build extremely feature-rich (and interactive) web applications. For
example, like WPF, Silverlight has a vector-based graphical system,
animation support, and multimedia support. Furthermore, you are able to
incorporate a subset of the .NET base class library into your
applications. This subset includes a number of WPF controls, LINQ
support, generic collection types, web service support, and a healthy
subset of mscorlib.dll (file I/O, XML manipulation, etc.).
NOTE
This edition of the text
does not address Silverlight; however, a majority of your WPF knowledge
will map directly to the construction of Silverlight web plug-ins. If
you are interested in learning more about this API, check out http://www.silverlight.net.
