Editor's Note
Rich Clients Count Too
It's the dead of winter here at the MSDN Magazine offices, and we're having a blast. Temperatures are making their daily struggle to stay above zero. The tempting aroma of chestnuts roasting on an open subway ventilation grate fills the city with a wintry mix of excitement and anticipation. The last of the rampaging hordes of malevolent Santas have finally been brought to justice, and the city is looking to move past the Kris Kringle incidents into a new spirit of community.
Since we're sharing in this new spirit, we felt it was time for a heart-to-heart with our readers. For over two years now, we've listed a few of the swell things that the Microsoft .NET Framework can bring to your coding efforts. (Okay, so "a few" has turned into over 100 articles.) There's a reason the name ".NET" was coined for these services—.NET is packed with features designed to make it easier to write interconnected, networked code. Whether you're writing a program that connects to the Internet reliably or you're creating an XML Web Service, the classes in the .NET Framework have been designed to make formerly daunting tasks easier.
However, there's still a universe of programs that aren't about to become Web Services and which aren't centered around the Internet. Maybe these apps only feature a networked connection for sending help requests. Perhaps they never really need a connection at all. These are the types of applications that people have designed for the past 15 years for the Windows platform—there are probably tens of thousands of apps out there now that take advantage of the underlying operating system.
As we've discussed in previous Editor's Notes, the world of development has moved back and forth for years, from dumb clients and servers to PC-centric computing, then back to the client/server model with the rise of the Internet. We're now in the age of two-way computing, where machines can interact with each other as peers, as well as acting as standalones. With functionality that wouldn't have been dreamed of even 20 years ago, these desktop-centric products are often called "smart clients" or "rich clients."
If you're looking at your app's design, it's relatively easy to figure out what sort of model you should adopt during the design phase. Just ask what your app is going to be doing. Is its functionality based around the messages returned by another service? Are the only initial menu options going to be File | Connect and File | Exit? If so, you're looking at a networked thin client.
But much as the pundits (including us, at times) would have you believe, there's plenty of room for rich clients in a thin-client world. Be proud of what your program is! Celebrate your diversity! Desktop-centric apps are back, and with Windows Forms they're better than ever! A couple of months ago in Redmond, we talked to several people who were focused on making the client-side user experience as fabulous as possible. These chats inspired us to investigate some topics that might be helpful to the myriad programmers who are working on programs that might not need to be connected to the Internet at all times.
For instance, printing is a sometimes unglamorous, yet always important topic. The ability to print polished output is one of those little touches that turns a project into a real application. Threading, on the other hand, is never going to be a "feature" of an app, but at the same time it affects what users think of your program more than any other factor except UI design. Of course, threading is a big concern when you're working with data that's carried over the Internet. With multisecond latency, even the best-coded apps will appear to be frozen if you don't take advantage of asynchronous features like BeginRead/EndRead.
This concern isn't unique to networked client/server apps. When you're reading large disk files, you run into the same problems—but most programs treat disk access and other lengthy tasks as synchronous actions. This freezes the UI while a file loads. In this issue, we'll show you how to use multiple threads with Windows Forms to make your app snappier and more responsive.
Even rich desktop apps can benefit from behind-the-scenes networking, however. One of the grooviest features of Windows is Windows Update. Without bothering the user, it automatically checks for new downloadable patches and updates, and it's smart enough to figure out the machine's connection status first. What's the magic behind this feature? It's the little-known Background Intelligent Transfer Service API—a.k.a. BITS. In this issue, we'll show you how to give your application the auto-update feature you've always dreamed of implementing. Yes, in the spirit of the season, we're making your auto-update dreams come true.
ActiveX, JScript, Microsoft, MSDN, PowerPoint, Visual Basic, Visual C++, Visual Studio, Windows, Windows NT, and Win32 are registered trademarks of Microsoft Corporation. Visual J# is a trademark of Microsoft Corporation. Other trademarks or tradenames mentioned herein are the property of their respective owners.
MSDN Magazine does not make any representation or warranty, express or implied with respect to any code or other information herein. MSDN Magazine disclaims any liability whatsoever for any use of such code or other information.