I thought I would do a little blogging on the user interfaces bindings currently exposed to .NET, and how I feel about them, their APIs, and their documentation: basically the stuff you need to know to work with the APIs, and the APIs themself. They're in no particular order, but I'll give them a rating from 1-10 based on how fluid it be, yo.
Each blog will focus on just one user interface framework. Let's get it started.
Windows Presentation Framework (WPF)
When you first look at the API, it is mindblowing -- there is shit everywhere, and the inheritance and interface definitions are off the chain. For a moment it seems like one big cluster fuck, but this is one of those situations where examining the API without using it is a Bad Thing To Do. After a few hours working with it, I began to realize the reason there were so many interfaces and inheritances trees was to keep things simple. You only implement what you need, nothing more. This is a startling contrast to most of the UIs that have .NET bindings (including Win32 itself), where there is generally a huge base class with lots of overriable methods and properties. At first glance it seems like a sweet deal, but then you run into "ok, what is the absolutely minimum number of virtual method/properties I have to override?"
I really began to appreciate the design when I started to do more complex stuff. I needed a "Icon List" control, which is basically a panel that holds a bunch of icons, with optional text beneath each icon. There's no such convience control in WPF, so I realized I had to make one by hand. It only took minutes to get the basic functionality in: the main panel, to hold all the icons, was a WrapPanel. Each of the "icon" elements was basically a Canvas with an image on it. The best part was when I realized I wanted to add "tagging," support, all I had to due was plop a text box down, anchored to the bottom of the Canvas... and I was "done" so to speak.
"Styling" controls is really easy, and in fact one of the things I really like about the WPF. One style can apply to any kind of UIElement, really, which are the building blocks of user interface controls. So you can apply the same style to a radiobutton and a textbox and achieve the same result. Really cleans things up quite a bit.
The fact that any UIElement can be placed inside of another UIElement becomes invaluable after spending a few days with it. It makes compositing controls a real killer feature. This is to be expected, though, since WinFX is a "next gen" API and isn't carrying the baggage of backwards compatibility, so it has no other choice but to be better than the current toolkits or die trying.
There's other goodies I haven't had time to jump into, like DataContext, a really sweet way of data-binding. Basically this is how you tell UIElements to interpret your class/structure. Then all you have to do is supply your object and things work like magic.
Still, there are some serious downsides: documentation, for one, is pretty much nonexistant. The API is in constant flux as well, since every CTP makes a few dozen breaking changes. I would not ship software targeting any given CTP of WPF right now, but software that doesn't have an "offical" release until sometime next year is a good canditate, in my opinion. I know that I'm using WPF right now to develop something.
Score: 9/10
No comments:
Post a Comment