| |
Articles from
December 2008
JetBrains started work on ReSharper 4.5 recently; but, more importantly, they just made nightly builds available online. I've said it before and I'll say it again: this is the best Visual Studio add-in I've seen... and I'm not the only one who thinks so. I'm a huge productivity geek and ReSharper helps feed my addiction to speed... as in quick. JetBrains won't give you drugs. Although, ReSharper may seem like it, when you work on a machine without it. Development without ReSharper is somewhat analogous to drug withdrawals... cold sweats, lots of twitching, and wondering if you'll be able to finish in time. Okay, maybe not, but I do dread life without it.
The following consists of the English DVD updates released under the MSDN Premium (Team Suite) subscription level for January 2009.
Servers
- Disc 4614 / Part X15-28400
- Microsoft Customer Care Framework 2009 (English)
- Microsoft Desktop Optimization Pack 2008 R2 (English, Portuguese-Brazil, Chinese-Simplified, Chinese-Traditional, French, German, Italian, Japanese, Korean, Russian, Spanish)
Applications
- Disc 3099.02 / Part X15-28380
- Hyper-V™ Server 2008 (Chinese-Hong Kong S.A.R., Chinese-Simplified, English, French, German, Italian, Japanese, Korean, Portuguese-Brazil, Russian, Spanish)
- Microsoft Virtual PC 2007 (English, French, German, Italian, Japanese, Spanish)
For more information, see the MSDN Subscriptions Index.
Every year, there's one underlying theme that seems to be pushed in the technology arena more than anything. This year, I feel like it's the year of the cloud. The last time I did this was five years ago, so I'll have to back-fill a few years, but here are the themes I've noticed over the past 11 years.
- 2008: Year of the Cloud
- 2007: Year of User Experience
- 2006: Year of AJAX/Web 2.0
- 2005: Year of SaaS
- 2004: Year of Offshore Outsourcing
- 2003: Year of the Architect
- 2002: Year of Web Services
- 2001: Year of XML/.NET
- 2000: Year of Enterprise Java
- 1999: Year of Linux
- 1998: Year of the Web
We've been approaching "the year of the cloud" for a while, now. You can actually look back to 1998, when the web started to really catch on. A few years later, as Java started to build momentum and then .NET hit the scenes, which is when XML as a standard communication language started to catch on. Also tied to the .NET release was a huge push for web services. As this was more and more successful, service-oriented architecture (SOA) started to boom. In my mind, that was a big boon to the outsourcing trends, which have seemingly quieted down a bit, but not completely. SOA also led to the software as a service (SaaS) trend, which triggered Microsoft's software plus services (S+S) push, but that was more of a side story. With everything moving to the web, backed by [typically open] services, asynchronous Javascript and XML (AJAX) was the next big push. This was tied to the "Web 2.0" moniker, which I'd argue wasn't quite what Tim Berners-Lee intended. Either way, this led to the big push for better user experiences, which many people confuse with user interface design. The Web 2.0 push also kept the industry on its web focus, which is where we are left today.
It's easy to look back and see how we got here. Trends show that architectural changes typically take two or three years to gain momentum in the community, so we'll probably have a couple of years before the next major architecture peaks. The trend towards distributed computing has grown more and more, but I have a feeling things are going to start coming back a little. We've been pushing out to the web for a lot of reasons; one of which is the rise of the Mac. What we've been losing out on, however, is the power of the desktop. I see the S+S push to continue, but more as an underlying theme than a strong focus. Services will continue to be the foundation, maintaining the importance of cloud computing, but the desktop will be where the processing occurs. I see Silverlight proving a huge success, which will eventually bring .NET to the Mac. This will probably bring Novell and Microsoft a little closer together, with respect to Microsoft's relationship with Mono, but this may simply be a change in focus for Mono. Oh, and when I say, "bring .NET to the Mac," I'm not talking about the scaled-down version in Silverlight. I'm talking about the real deal. I see WPF and Silverlight merging along with the smart client architecture built into .NET today. This will take more than a few years, but it seems to be inevitable. Most likely, by the time all this happens, multi-core will be a way of life, as opposed to the we-should-be-thinking-about-threading thoughts most developers have today. Armed with a strong multi-threaded foundation, which is easy to use, the combined WPF/Silverlight presentation tier will quickly overtake Flash and Air. By this time, we should also start to see more integration into our everyday lives...
Okay, I'm probably getting a little out of hand here. If I go much further, we're going to be on the USS Enterprise, so I'll stop while I'm ahead. I'll just leave it at, it'll be interesting to see what's next. My money's on the power of the desktop, which we've lost over the past 10 years.
By Michael Flanakin
@ 8:38 AM
:: 14707 Views
:: .NET
:: Digg it!
 Routed events are one of the foundational components of the WPF and Silverlight architecture. If you're not familiar with the concepts behind routed events, check out Brian Noyes'  MSDN Magazine article, Understanding Routed Events and Commands in WPF. This is a great start to understanding the architecture, but Brian doesn't tackle creating your own routed events. After seemingly endless searches, I finally whipped out Reflector to get to the bottom of it. It's pretty simple, but it is different.
For this scenario, I have a collection of items and I needed to raise an event when the selected item changes. Pretty basic. There are three components to this: (1) the routed event identifier, (2) accessor, and (3) event raising call. Again, not too far off what we're used to, but it is slightly different.
public static readonly RoutedEvent SelectedIndexChangedEvent = EventManager.RegisterRoutedEvent("SelectedIndexChanged", RoutingStrategy.Bubble, typeof(RoutedEventHandler), typeof(MyControl));
public event RoutedEventHandler SelectedIndexChanged
{
add { AddHandler(SelectedIndexChangedEvent, value); }
remove { RemoveHandler(SelectedIndexChangedEvent, value); }
}
This is where I got stuck. I tried the traditional method to raise the event:
protected virtual void OnSelectedIndexChanged(RoutedEventArgs args)
{
if (SelectedIndexChanged != null)
SelectedIndexChanged(this, args);
}
Obviously, we wouldn't be here if this would have worked. Luckily, all we need to do is replace the if block: RaiseEvent(args). I should also mention that, when you initialize the event arguments, you need to specify the routed event it's being triggered for. this is as simple as new RoutedEventArgs(SelectedIndexChangedEvent).
There can (and probably should) be some deeper thinking with respect to the best way to make this call, but I'm not going to cover that here. I have some half-baked ideas about this as well as what hooking up a routed event should look like, but I'll save that for another time.
If you haven't played with either WPF or Silverlight, you first need to understand the tooling we have available: Visual Studio, Blend, and Design. Most people don't consider Expression Design, but I'd argue that it's perhaps the best way to get started, depending on what you're doing. This is probably common sense, but if you haven't played with each of the tools, you may not realize how valuable each is to your end goal.
Any developer will most likely want to start with Visual Studio. Try it. You'll find yourself wondering where to start. If you're an old school web developer, like me, you'll stare at the XML code and wonder what to type and finally fall back on the toolbox. If you're a drag-and-drop type (either Win or Web Forms), you'll probably go directly to the toolbox. In either case, you'll most likely find it useful to tweak both the designer and XML... well, that's not completely true. If you're comfortable with XML, you'll eventually stop using the designer because it's just too much of a pain to deal with in Visual Studio. Visual Studio is the best environment [today] if you want to modify markup or code. Don't choose Visual Studio if you're a drag-and-drop type of developer. No matter what type of developer you are, however, you'll find yourself wondering if there's a better way because it just doesn't "feel" right. This is when you'll begin to wonder about that "Blend" thing you heard about.
If you're proficient in Flash development or claim the "designer" moniker, you'll probably start with Expression Blend. Blend is the best tool to build an interface along with some key interaction details (read: animations). The problem with blend is, there's absolutely no intellisense in XAML, which I find ridiculous. And, just to put salt in the wound, you can't even edit code (C# and VB) files with the tool. This really drives in the fact that the tool is intended for no-code applications. These don't exist. In my experience, Blend will become less and less useful over time. Why? Because you'll start to realize you can't do everything in XAML and will have to move some things to code. This, in conjunction to run-time bindings in XAML will render the Blend design-time experience useless. Visual Studio is the same in this aspect, but it just because apparent that you'll prefer the intellisense, since you'll want to work with the XAML. Unlike Visual Studio, tho, you'll find yourself tweaking the designer more than the XAML. Coding isn't the only thing that will take you out of Blend, tho.
Let's face it, most people start looking at WPF and Silverlight because they want glam. They want beautiful applications with all kinds of frou-frou animations and transitions. This drives me crazy, but I'm not surprised. Choose WPF and/or Silverlight not because it can be pretty, but because it's the next generation user interface technology. This means, if you're building a new Windows application, don't even look at Win Forms. WPF is the way to go. Microsoft hasn't said it, but Win Forms is dead to me. If you have an existing app, I'd recommend you start looking into interop scenarios. Whether you're looking at WPF and/or Silverlight as the next gen platform or not, you're still going to want that glam I mentioned. This is when you should take a look at the often ignored, red-headed step-child of the Expression suite.
Today, Expression Design is a vector graphics editor. Don't expect to switch to Design for raster images (i.e. GIF, JPG, PNG) -- which is what I was hoping to do -- you'll find yourself missing crucial capabilities. I keep Paint.NET on hand for these needs. Design is best used to build creative visual interfaces. I've used it to theorize and bring certain design elements to life. You might do this with windows, buttons, and other framing elements, for instance. I simply find Design to be a better interface for adding glam to my user interface. Note that I'm not referring to animations. Use Blend for animation; use Design for static visual elements, like rotation, embossing, and the like.
To sum it all up, here's what I believe a WPF/Silverlight project should looked like.
- Know the difference between graphic and interaction design. Essentially this is the user interface vs. user experience debate, it's important to know the difference for staffing purposes. There is a difference and it's substantial. Don't assume that a graphic designer can architect an ideal interaction or vice-versa.
- Get a graphic designer. Unless you have an eye for graphic design, you won't be getting the eye candy you're probably looking for. If you have a passion for this, but it isn't your calling (like me), you might be able to get there eventually, but your time is probably better spent elsewhere.
- Get an interaction designer. The fact that we have dialog after dialog and click after click proves how important this one is. I'd argue this is more important than a graphic designer, but I might be biased. The good news is, this can be learned a lot easier than the artistic nature of graphic design. Don't think you can get there without dedication, tho. There are some scientific guidelines, but I have yet to see a good roadmap. It's more about opening your mind and removing yourself and what you might do from the process.
- Design is the graphic designer's scratch pad. Whether you start with wire-frames or set your sights on the real deal, Design is great for slapping something together that will eventually be useful. Tweak and tweak and tweak until you get something that looks right. Then, export to XAML.
- Blend brings your design to life. Now that you have your XAML, you'll probably need to tweak it to make it slightly more human-readable and maintainable as well as do some initial bindings and animations. This is where three worlds collide. Graphic designers will feel awkward in Blend, but will still be able to be relatively production; interaction designers don't really have a tool, so it will depend on where they came from, but Blend is arguably the best place for them to get started; and, developers are typically more code-focused, so Blend will be awkward for them, too. The bottom line is, Blend isn't the perfect tool for anyone, but it does fill a need. Use it to add interactivity to your design.
- Visual Studio gets the job done. When you're ready to make your app do something real, open it in Visual Studio. Arguably the worlds best development environment -- although not without its flaws -- you know why you're here. 'Nuff said.
As a developer who is very comfortable with markup, I've found that this has changed for me over time. I still believe it's a great workflow that supports some moderate back-and-forth -- at least, between Visual Studio and Blend -- but my habits have changed over time. As I've become more and more familiar with XAML, I tend to create visual and interactive effects in Design and Blend, respectively, and then just look at the XAML to figure out how it's done. Occasionally, I'll open my app in Blend, but not too often. This just depends on how big of an effect I'm trying to implement.
The bottom line is, get some experience in all three of these tools. You'll find your own comfort zone. It may include the all-too-bloated and usability-hating Photoshop with a XAML exporter instead of Design or augmenting XAML editing with a light-weight tool like XamlPadX or Kaxaml. No matter what you grow into, know there will be growing pains. WPF and Silverlight have a huge learning curve, but you're buying into the future. The curve is there for a reason, but will hopefully be lessened as the tools improve. I'm also hoping for some major improvements in .NET 4, but I'll try to touch on that later.
|
|
|
|