Modern programming: A tale of four frameworks

After starting my new job in Core OS, it became clear that I would need to brush up on my old COM-programming skills, which I haven’t used in about, oh, eight years. It’s been all .NET Framework since I hired on as a full-time employee at MSFT.

A good place to get acquainted with the COM world is the excellent ATL Tutorial topic on MSDN, which shows how to build a simple ActiveX control and host it in a web page. It comprises seven hefty steps and a fair amount of C++ code. I have to admit that it was a bit of a shock to revisit the old skool world of native Windows programming after being spoon-fed .NET Framework sugar for so many years.

My idea is to perform the same task in other frameworks and compare the ease of implementation. I hear people claim that Microsoft doesn’t know what “modern programming” is about, so let’s put this claim to the test.

For reference, here’s what the project looks like once you’ve performed all the steps in the ATL Tutorial topic.

Solution Explorer view of the completed ATL Tutorial project, in Visual Studio 2010.

Here’s the Polygon ActiveX control, hosted in Internet Explorer 8.

The completed Polygon ActiveX control from the ATL Tutorial project, hosted in Internet Explorer 8.

The overall experience for implementing the Polygon ActiveX control isn’t too bad, although I found myself getting lost among the .h, .cpp, and .idl files, especially when connection points entered the picture – all that IDispatch business feels needlessly complicated nowadays. In fact, the experience is completely unchanged since the last time I implemented COM objects in the previous millennium; the ATL dialogs in Visual Studio 2010 appear to be identical to those used in Visual Studio 6.

The ATL Control Wizard in Visual Studio 2010.

Because Visual Studio 2010 is a managed application with a WPF user interface, I wouldn’t be at all surprised if these are, in fact, the original comctl32.dll-based dialogs running in an HwndHost control. This is both comforting and disturbing, as if ATL development had been frozen in amber for the last decade.

Debugging was not entirely convenient, requiring the discovery, download, and build of a semi-supported external test application, named TstCon. I was reduced to message-box debugging when the control was running on the web page. UPDATE: Franci Penov points out in comments: “You don't have to use external tools to debug the ATL ActiveX. You can use WinDbg to start IE and debug your code as it is executed on the page; with all the bells and whistles the debugger gives you - full symbols and source code support, breakpoints and stepping through the code, memory inspection and so on. In fact, you can even use Visual Studio for that, though setting it up is a little bit tricky and it's a bit slower.” Thanks, Franci!

From the perspective of “modern” software development, here are the important observations:

• The ATL/COM implementation has a large ratio of framework files to user files. Depending on how you count, it’s about 5 or 6 to 1.
• The implementation is distributed across 3 files with arbitrary locations for code in .h or .cpp.
• There is no support for declarative layout.
• There is no visual designer support.
• The implementation uses lower-level abstractions, such as HDC and WPARAM.
• Analysis tools are not readily available.
• Several hours to implement and debug.

With the unmanaged ActiveX implementation in hand, I turned to Silverlight for a comparison to a “modern” framework. This turned out to be immensely simpler to implement; the hardest part was converting the core C++ code to C#.

Here’s what the Silverlight project looks like.

Solution Explorer view of the completed Silverlight control project in Visual Studio 2010, adapted from the ATL Tutorial topic.

Here’s the PolygonControl implementation in Silverlight, hosted in an autogenerated page on Internet Explorer 8.

The completed Polygon Silverlight control, adapted from the ATL Tutorial project, hosted in Internet Explorer 8.

I added a slider control to change the number of sides in the polygon, just because it was easy. I briefly considered doing the same thing with a comctl32 slider in the ATL/COM implementation, but the thought made me hyperventilate.

From the perspective of “modern” software development, here are the important observations:

• The Silverlight implementation has a small ratio of framework files to user files, about 1 to 2.
• The implementation is in 1 or 2 files (code-behind plus optional XAML). 
• Declarative and imperative layout are supported.
• There is full visual designer support.
• Silverlight provides free graphics and layout sugar.
• The implementation uses high-level abstractions, such as data binding and events.
• The debugging environment is fully integrated.
• Analysis tools are fully supported.
• Two hours to implement and debug.

For the modern programmer, Silverlight is the clear winner. But what of other frameworks? In particular, modern programmers want to author mobile apps. I happen to own an HTC Droid Eris, which I like very much, so it seemed natural to explore the Android Development Tools (ADT). 

It’s been awhile since I’ve done any serious Java programming, so it took a few hours to install Eclipse and get the ADT to play with it. Once that was done, it was a simple matter to port the C# code to Java and run it in the device emulator. Happily, the core code that calculates the polygon vertices ported from C# to Java with no tweaking necessary.

Here’s what the Android project looks like in the Eclipse IDE.

Package Navigator view of the completed Android control project in Eclipse, adapted from the ATL Tutorial topic.

The project structure is comparable to the Silverlight project in simplicity, which is nice.  Deployment to an Android Virtual Device (AVD) emulator is straightforward and supports full debugging in the IDE. Devs who are worried about Java VM performance can rest easy: starting with Android 2.2 (“Froyo”) the Dalvik runtime engine (Google’s bytecode interpreter) now supports just-in-time (JIT) compilation, like the .NET Framework.

Here’s the Java-based implementation of the PolygonApp running in an Android Virtual Device. 

The PolygonView control running in an Android Virtual Device emulator, adapted from the ATL Tutorial topic.

Touch events and gestures come free with the ADK framework. The downside is that there’s no visual designer in Eclipse. UPDATE: Spence corrects me in comments – there is visual design support in Eclipse. My bad.

Here it is:

The PolygonView implementation running in the Eclipse visual designer.

From the perspective of “modern” software development, here are the important observations:

• The Android implementation has a small ratio of framework files to user files, about 2 to 1.
• The implementation is in 1 or 2 files (code-behind plus optional XML). 
• Declarative and imperative layout are supported.
• There is no visual designer support.
• The Android framework provides free graphics and layout sugar.
• The implementation uses mid-level abstractions, such as layout views and Java graphics.
• The debugging environment is fully integrated.
• Analysis tools are supported but not as fully featured as Visual Studio 2010.
• Two hours to implement and debug.

This post was going to be a “tale of three frameworks,” but after success with Android, it seemed obvious to compare with the new Windows Phone 7 framework.

Installing the Phone 7 development environment turns out to be painless: there’s a special Express SKU of Visual Studio 2010 that you download from the Windows Phone developer site. Fortunately, the Visual Studio Express SKUs install side-by-side with the other Visual Studio SKUs, so you can have Visual Studio 2010 Express for Windows Phone on the same machine that has your main Visual Studio installation.

The biggest win for Windows Phone development is that it’s based on the .NET Framework, with Silverlight providing the user interface for your apps. I was able to lift my PolygonControl implementation and drop it directly into my Windows Phone project with zero changes – well, one: I used Visual Studio’s refactoring support to change the namespace for the control to the default namespace of the Windows Phone project, and it even refactored into the XAML. Thank you, Cider team.

Here’s what the Windows Phone 7 project looks like.

Solution Explorer view of the completed Silverlight control project in Visual Studio 2010 Express for Windows Phone, adapted from the ATL Tutorial topic.

And here’s what the Windows Phone development environment looks like.

The completed Silverlight control project in Visual Studio 2010 Express for Windows Phone, adapted from the ATL Tutorial topic.

The big win here is the visual designer support, which looks exactly like what you get with the WPF and Silverlight Designer for Visual Studio. You drag and drop controls from the Toolbox onto the design surface, which represents your target device’s display, and you set properties on controls by using the familiar Properties window. The XAML view automatically updates to reflect these changes. VS automatically added my PolygonControl to the Toolbox, so I was able to drag it from the Toolbox and drop it onto the design surface. This is what we used to call RAD – Rapid Application Development.

Here’s the Silverlight implementation of PolygonControl, hosted in the Windows Phone Emulator.

The PolygonApp running in the Windows Phone Emulator, adapted from the ATL Tutorial topic.

The most exciting feature is the Windows Phone compatibility with Silverlight – I could hardly believe my eyes when the same PolygonControl implementation ran both in the browser and in the phone emulator. Potentially, this is a huge win for Windows apps developers and may be the single strongest argument for favoring Silverlight over the other frameworks.

Here are the running apps, shown side-by-side for comparison.

The Polygon control, adapted from the ATL Tutorial topic, running as an ActiveX control (left), a Silverlight control running in Firefox, a Windows Phone control, and an Android Virtual Device emulator (right).

What’s a modern programmer to make of all this? The following table summarizes what we’ve discovered.

It’s a toss-up between Android and Silverlight, but for my money, the possibility of authoring Silverlight controls that also run – with no XAML changes – on Windows Phone makes Silverlight the more compelling story. Conceivably, modern developers can double their income from a single code base, by selling the usual desktop/browser apps as well as corresponding Windows Phone apps.

What of the claim that Microsoft is oblivious to modern programmers? To my mind, it doesn’t hold water – it’s hard to imagine a more modern framework than Silverlight. Once Windows Phones start to ship, Microsoft will have complete parity with Android in the developer story.

The code for all four projects is posted at my Code Gallery site. Check it out and tell me if you agree with my conclusion.

UPDATE: Don Burnett compares iPhone development to Windows Phone development here: iPhone versus Windows Phone 7 Coding Comparison.

Technorati Tags: Visual Studio,WPF Designer,WPF,Silverlight,Windows Phone,Android,Java,COM,C++,C#,XAML