Getting ready for .NET 3.0

I've spent some time tooling around what was formerly known as Avalon and Indigo, then renamed to WinFX, and finally baptized as .NET 3.0, a move that positioned the development framework as the next step in .NET's evolution (which makes a certain amount of sense). By "tooling around," however, I don't mean I explored every nook and cranny of the large new API Microsoft had built for its new Vista operating system (and ported back to Windows XP and Windows 2003).

I'll swim around a bit with pre-release technology, but I don't usually take the deep dive until a few months before wide release. That was the case with Java, when I started getting more intense with a pre-release version (and reading a bunch of pre-release books) about six months before the initial release of the product back in...1996 (I think). I spent many years working as a Java programmer, but I have a certain reluctance to get too crazy with pre-release technology given the inevitable bugs, flaws and flux due to API changes which of necessity will occur.

Well, my deep dive into .NET 3.0 is well underway. Back in 1996, learning a new API took a lot more work. Java was my first real exposure to object orientation. In 2006, I know what kinds of things should be there, and the stuff that I tend to look for is the stuff that makes a new environment stand out.

I liked the Avalon API before. I really like it now that I'm taking the time to really learn its ins and outs. It's an extremely flexible, well-designed and elegant API with which to write visual applications.

Unfortunately, it's harder to put my finger on what, exactly, makes the WPF such an elegant framework for UI design. Then again, I'd have equal trouble describing what it is about a Rembrandt painting that makes it stand out (and yes, I do think that is an apt comparison). You know an elegant design when you see it, and I can't say I feel that way about every Microsoft API.

Maybe it's the simple structure by which applications are composed of UIElement-based "lego" blocks. Maybe its the dazzling array of ways to customize backgrounds and borders, or the ease with which formerly complex issues related to 2D and 3D graphics and animations have been solved in the WPF. Maybe it's the extreme adherence to principles of object orientation, the mark to my mind of a well designed framework. Maybe it's the small things, like ToolTip objects the contents of which can contain any combination of controls and layout panels, property binding that takes a lot of the work out data management, or "bubble" event routing that makes it easy to create an event handler for common classes of events. Maybe it's the fact that the whole thing can get distilled to an XML file (XAML) that maps directly to objects and makes desktop UI programming as easy to do as web page development (but more structured).

I can't point out one thing today, but I'm only a third of the way through "Applications = Code + Markup, Charles Petzold's definitive tour of the WPF, so maybe that will change. Anyone who has ever done Windows programming knows that Petzold is "the man" when it comes to programming Windows. I'd still have his WIN32 programming book if it hadn't gotten lost between Ireland and the United States (along with a bunch of my CDs, which probably didn't do the person who stole them a heck of a lot of good unless they are into a bunch of bands nobody has ever heard of).

Microsoft's plan is to create a bunch of advanced user interface tools that manage the intricacies of XAML for you. This is part of their drive to create a clean separation between UI and business logic, allowing graphic artists to do their thing irrespective of how the final product is going to do what it is supposed to do.

That doesn't mean understanding what those tools do isn't essential to being a good programmer. Understanding HTML, CSS and Javascript is a good idea, too, even though there are heaps of tools that hide its intricacies. I tend to prefer to understand everything about the languages and APIs I am using on a regular basis. That might bother some when I use less common language features (where they make sense), but I like to find the BEST way to do things using whatever tools I am using. I can be quite stubborn when I think the BEST way to do something is blocked.

Stubborness in programming, however, is a virtue. I mastered XmlSerializer because I wasn't willing to be forced into certain XML syntax structures just because generating - and consuming them - with XmlSerializer wasn't obvious (at first). Now, however, XmlSerializer is one of the more versatile - if always "under the covers" - tools in my programming arsenal.

On that note, I have had something I wrote on XmlSerializer that I intended to post over a month ago, but never did. So, I'll dig it up and post it this week, because, frankly, that's where my head is. Issues that incense the computing body politic be damned. I've been programming...a lot...and that's all I can think about right now.