Ever since Windows Vista (sorry Microsoft, for reminding you of that product again) and .NET Framework 3.0 were released, the Windows client developer (the one who is intentionally unaware and exceedingly pleasured by ignoring JS, HTML, DHTML and other useless irrelevant terms in technology) was puzzled with an (frankly) unwanted choice that never existed for him before: continue using the ultimately productive Windows Forms framework, that has been the cornerstone of Windows client applications ever since Visual Basic (classic), or learn, explore and rewrite the apps in the WPF framework for building (what’s now become an overly exploited term in software development) next generation user experiences.
Microsoft has always assured (many consider it a curse) its developers of continued abundance of options and tooling support for all the major line of business applications that one develops. While this has obvious and much desired advantages, the real problem comes in at the start of the adoption phase of the new technology or framework. The earlier releases of the framework don’t (in almost all cases) provide a complete replacement of the previous technology and there is a very steep learning curve involved, with an exceedingly high cost and risk factor in recreating the missing bits, by extending the not so feature complete releases.
My personal approach while dealing with this new-technology-every-PDC kind of releases is fairly simple:
| Version | Action |
|---|---|
| Alpha/Beta/CTP or | Just be aware, a new (yet again awesome, silver bullet kind of) technology has arrived! |
| v2.0 | Seems interesting, lets look at the real benefits. |
| v3.0+ | Use it (OMG, its actually awesome and the silver bullet for everything a MS developer ever needed) |
WPF (codename Avalon) was launched with .NET Framework 3.0 and at its time of release, had a substandard support in terms of tooling. Mr. Reader, be informed, that this is not a WPF tutorial series on how to get started with WPF. The attempt is to dive (as deep as possible) into the architecture of WPF and to understand why things are the way they are in WPF.
Windows & Graphics: The primary technologies behind many Windows-based user interfaces, GDI (graphics device interface) and USER subsystems, were introduced with Windows 1.0 in 1985. The next major support for graphics came with OpenGL (created by Silicon Graphics) in early 1990s for doing advanced 2-D and 3-D graphics on both Windows and non-Windows based systems. In 1995, Microsoft introduced DirectX, for providing a new high performance alternative for 2-D graphics, input, sound, communications and eventually 3-D (with DirectX 2 in 1996). With Windows XP, GDI+ was introduced by adding support for alpha blending and gradient brushes, but ended up being slower due to its complexity and lack of hardware acceleration.
With the release of .NET (and the managed world) in 2002, Windows Forms (built on top of GDI+) became the primary way for a C# or Visual Basic developer, to create rich and compelling user interfaces for Windows based systems. Windows Forms has proved itself as a productive and successful technology, but it still suffers from the limitations of GDI+ and USER subsystems, when it comes to graphics, layouts and rendering.
In the adjoining image, the major code for WPF are highlighted in red, and its interesting to note, that out of the three components (PresentationFramework, PresentationCore and MilCore), only MilCore is unmanaged. Milcore is written in unmanaged code in order to enable tight integration with DirectX. All display in WPF is done through the DirectX engine, allowing for efficient hardware and software rendering. WPF also required fine control over memory and execution. The composition engine in milcore is extremely performance sensitive, and required giving up many advantages of the CLR to gain performance.
The Dispatcher:The DispatcherObject acts as a base class for most objects in WPF and encapsulates the basic constructs for concurrency and threading. The Dispatcher is the messaging system of WPF, which acts similar to the Win32 message pump and uses User32 messages for performing cross thread calls.
Dependency Object and richer Property system: In WPF, properties are preferred over methods or events and this constitutes one of the primary philosophies of the WPF architecture. The property system in WPF is based on the DependencyObject which enables tracking of dependency properties and revalidating values when changes occur. Another feature of properties in WPF is the notion of “attached properties”, which enables composition and component reuse, one of the primary goals of WPF. With attached properties, any object can now specify the properties of other objects, enabling tighter composition.
Routed Events: WPF introduces Routed Events, which from an implementation perspective, is an object backed by an instance of the RoutedEvent class and processed by the event system. From a functional perspective, it is a type of event that can invoke handlers on multiple listeners in an element tree, rather than just on the object that raised the event. Since WPF enables richer composition model, it was essential for the event system to be able to “bubble up” events, generally upward through the element tree, until it reaches the root. It is to be noted that in WPF, literally any control can act as a container control, unlike Windows Forms where container controls inherited from a different base class. To enable routed events, or event bubbling in Windows Forms, you would have to attach the same event to multiple elements, while in WPF, you could do that by attaching them to a single element.
XAML (Xml Application Markup Language): The current trend in programming languages (specifically Microsoft technologies) has been towards declarative rather than imperative, and there are underlying benefits to it. XAML typically allows you to create the entire application declaratively, enabling the decoupling of the UI with the logic, supporting unprecedented designer-developer collaboration.
“XAML directly represents the instantiation of objects in a specific set of backing types defined in assemblies. This is unlike most other markup languages, which are typically an interpreted language without such a direct tie to a backing type system. XAML enables a workflow where separate parties can work on the UI and the logic of an application, using potentially different tools.” – MSDN
The intent of this post is to provide a starting point in understanding the complexities and terminologies associated with the WPF architecture. I wish and hope, the initial hesitation associated with moving to and understanding WPF, is eased after going through this post. As with any framework, the best way to learn and leverage it still remains to be writing applications using it!
Dispatch!
