Simple Code Makes Good Software

I just ran my first homebrewn application on my HTC 7 Trophy. It was easy! I started on this app several months ago when Mango was not available yet. At that time there were problems joining the Windows Phone Marketplace developer program from Finland so I could only run the app on the phone emulator. If an application is supposed to send SMS’s, it’s not very useful when running on the emulator that only mocks sending an SMS.

After Mango was out, I managed to join the Marketplace, and today I finally had the time to register my phone as a development and debugging device. In just a minute I had the application running on my phone, picking phone numbers from my contacts and sending real SMS’s. Painless, I would say!

My application is very simple, but it’s genuinely useful. It is very likely it will be available on the Windows Phone Marketplace after some polishing. I’ll drop a note here when you will be able to enjoy it, too

Yesterday was my lucky day: I got Spotify on my HTC 7 Trophy. This was the final point to convince me that Windows Phone 7.5 will be *the* platform I’m going to use in my daily mobile life.

I have been using Windows Phone 7.5 aka Mango for more than a month now. When I bought my HTC in last December, I was a bit disappointed with the features Windows Phone 7.1 had. Mango made a big difference and placed Microsoft into the lead of the competition. Mango is elegant, responsive, and packed with creative usability ideas.

What I especially like in Mango is the People Hub. Updating my Facebook status and checking my friends’ status updates goes in a snap and is even easier than using the dedicated Facebook application. The idea of integration goes through all the PIM apps including the Linked Inbox and combined Calendar.

And yes, I just love the Office suite and how it integrates with SkyDrive, the cloud data storage of Windows Live. For instance, I can write a shopping list on my home or work PC using OneNote and then open it on my phone checkmarking bought items, adding new items etc. Or I can start a Word document on my phone and finish it off on my PC without having to take any additional steps to synchronize or copy it from one platform to another.

Before I got Mango I was using another HTC phone, namely HTC Desire running Android. I kind of liked Android, but it hasn’t got the style and simplicity of Windows Phone. I have been saying that Android is for geeks but Windows Phone is for people, and even if I sometimes count myself a geek, I prefer the Windows approach where functionality and ease matter more than the abundance of options.

So Mango fulfills all my mobile communication needs – almost. What I miss is the ability to share the Internet connection with my laptop which would mean USB tethering or setting up a WiFi hotspot. I know that Mango has got this feature, but the phone manufacturer has to support it, presumably with some kind of hardware solution. Having this feature on Desire, it’s too bad HTC doesn’t support it on Trophy, but things will be even worse if none of the Nokia Lumia models won’t support it – I have not seen any mention of this feature in Nokia’s pre-release material yet. I was planning to buy a Lumia 800 when it’s available, but maybe I’ll have to keep my Trophy and buy a 3G dongle with a cheap data plan in stead.

Anyway, providing an Internet connection for my laptop is not a major issue compared to what I find most exciting with Windows Phone, and that is, of course, programming for it. Being quite fluent with Microsoft programming tools I’m looking forward to being able to produce innovative solutions with reasonable pain, but that should be the subject of another post or rather a series of posts. Stay tuned!

After writing my previous post, I happened to pass by my archival bookshelf, and an opus caught my eye: Programming Windows by Charles Petzold from 1988. It has been ages since I last opened this classic, and yet, if I narrow my eyes a bit, it looks like it was written yesterday. What we call Win32 API today was just Windows API in 1988, but the 16-bit ancestor is amazingly similar to its 32-bit offspring. Even if we program in a high-level language like C# and use the .NET Framework, this ancient API dictates a lot we do with managed classes. Especially this goes for GDI (in Windows API) and GD I+ (in .NET Framework).

When Graphics Device Interface (GDI) was introduced, there were no hardware-accelerated display adapters. All the grunt work of calculating logical coordinates to physical pixels had to be done by the main processor, either in the application program or in Windows (i.e. GDI). Because performance was rationed, optimizing graphics performance was a joint venture between Windows and the application. Windows tried to be as helpful as possible, but the decisions were left to the application that knew what had to be done and was able to choose the right strategy.

This strategy was known as the “mapping mode” that is still present in GDI+ as the GraphicsUnit property of the Graphics class. In fact all major structures and functions in GDI find their counterparts in GDI+ as properties and methods of Graphics: hDC -> Graphics, SetViewportExt() -> PageScale, SetViewportOrg() -> TranslateTransform(), MoveTo()/LineTo() -> DrawLine(), Ellipse() -> DrawEllipse(), etc. to name just a few. This is all logical because GDI+ has to call GDI to get the pixels all the way to the display device.

Now enter Windows Presentation Foundation! WPF is different because it does not use GDI but gets its message to the display surface through DirectX. Game developers and enthusiasts have known for years that DirectX can use hardware acceleration, which GDI can’t. The mapping mode is gone: WPF uses device-independent pixels, each of which is defined to be 1/96th of an inch. Mapping to physical pixels is done by DirectX assisted by display adapter hardware, which the application can be totally agnostic of.

Drawing methods like DrawEllipse() are also gone – you just place graphic elements like Ellipse or LinearGradientBrush inside other graphic elements, and WPF gets them painted. I would see this as a significant move from imperative to declarative programming, which becomes more obvious if you create these elements in markup (XAML) rather than code (C#). In plain English this means that you tell WPF what you want, not how to do it. I like declarative programming!

I now place Programming Windows back in my shelf next to Kernighan & Ritchie and The MS-DOS Encyclopedia. Sleep well, my friend!