Now that Aeon Timeline has been shipped off to the Mac AppStore folk for review, I have a bit of dead time while I wait for their approval. Since I say on my website that I am considering a Windows version, and I am now getting several emails a day asking for one, I have spent the evening researching my options.
The results is not pretty: Microsoft has created a mess of half-finished technologies, with no clear path to move forward. If I am wrong in this, I would dearly love for a more experienced Windows developer to come along and point this out.
What follows will be somewhat more technical and developer-oriented than my usual blog posts. I have tried to keep it simple, but apologies if I lose any non-developers along the way. The implications, in turns of support for different operating systems, may still be relevant to you.
– I am not an evangelist: I welcome superior knowledge.
– Starting out in Mac OS X
– Starting out in Windows
– Will anyone other than Microsoft bet on Windows 8?
– WPF: Best of the rest or lame duck?
– Why does Microsoft make it so hard?
– An appeal: which path should I take?
In full knowledge there are many developers on both platforms with far more knowledge than me, and not wanting to start a flame war due to my own ignorance, I will lay my background bare so that readers can decide the value of my comments and correct/criticise me accordingly:
- In my regular job, I use and develop in Windows, but we develop specialised computer vision applications in C++ (.NET is far too slow for the purpose), which is far removed from this consumer-targeted GUI project.
- I have used Macs as my home computers since 2006. Yes, there are negatives and downsides to either OS, and either parent company, it is just a personal preference.
- Around four years ago, I started working on Aeon Timeline for Mac OS X. I do not consider myself to be an expert Cocoa programmer, but I am comfortable that I have the knowledge to implement anything I need, or the ability to find and learn anything I am lacking when it becomes required.
In short, I believe I am a good developer, but my knowledge of particular frameworks and methodologies is always as shallow as I can get away with to do my job well.
In order to explain how Microsoft is making it difficult, let me first explain my first experiences programming for Macs.
At the time I began, there were two frameworks provided by Apple: Carbon, which was used for legacy applications, but was being phased out; and Cocoa, recommended for any new Mac OS X app moving forward.
If you wanted to develop for Mac OS X, it meant using the Cocoa framework, and learning to write in Objective C. I bought a book, worked through one or two of the most basic examples, and started writing my application within a week, learning more as required. Aeon Timeline is the result, and I am pretty proud of it.
If I wanted to switch to writing a version for the iPad, I would be using much the same technology: Objective-C and a slightly different Cocoa framework for iOS.
Everything is unified. It may not be perfect, you may not agree with Apple’s totalitarian stance on the AppStore and their 30% cut, but as a developer, at least you have confidence: Mac OS / iOS programming is Cocoa programming. You know that you are going to be supported.
Unlike my start with Cocoa, I actually have Windows programming experience, so you would hope that my experience of returning to Windows would be better. Instead, Microsoft has created a complete mess that divides and dismays even seasoned Windows programmers. Even finding out the trade-offs between the approaches is hard, since Google turns up more posts from 2008 than 2012.
Bearing in mind that I will be developing an application from scratch to be released a year from now and supported for years down the track, Microsoft presents me with the following options:
- Create a Windows Forms Application using .NET. My own experience is that .NET’s memory management is too slow, but that was for specialised, intensive video processing, so that experience may be largely irrelevant.
Still, this is the old technology. It is still supported, and probably will be for some time, and it could probably be bent to my needs, but the message from Microsoft is to use the newer technologies that will be better supported into the future.
- Use Windows Presentation Foundation (WPF). This was to be Windows Form’s replacement, first introduced in Vista, and carried on into Windows 7, but XP support was possible. Skipping over the technicalities, it was a modern framework encouraging better design principles, and seemingly exactly suited to the kind of clean, attractive user-friendly application that I wish to make.
From what I can tell, the general consensus among its adopters was that it showed a lot of promise, but was never given the time and effort by Microsoft to mature to the level of Windows Forms. And Microsoft seems to have moved on again.
I haven’t downloaded a Windows 8 preview yet, but most feedback I have read implies it is a pre-beta level step backwards from WPF, attempting to do much the same thing from scratch.
Naturally, Microsoft is pushing WinRT as the latest must-learn technology. Having invested heavily in Windows 8, much of its success will depend on developers taking up WinRT to create the apps to entice consumers onto the platform.
But where is the incentive for the developer? Windows 8 isn’t out yet, and there is already a lot of conjecture that consumers may ignore it the way they ignored Vista or Windows Phone.
Even allowing for the fact it may take a year before I release, why would I risk developing for a Windows 8 market that may not exist, and at the same time ignore backwards compatibility for XP and Win7 users that are asking for a Windows version now?
There will be plenty of developers waiting for customers to make the first move, just take a look at the comments and links in this thread: http://joshsmithonwpf.wordpress.com/2012/03/20/does-anyone-actually-care-about-winrt/
And given Microsoft’s treatment of WPF, their previous must-learn technology, is there any reason to believe this incarnation is going to last any longer? Will it too be superseded by another half-baked replacement within 3 years?
Depending on which blog post or comment you read, WPF is either dead in the water, or still the best technology that is available for development right now.
Further development seems unlikely, and while WPF is supported on XP, Win7, and Win8’s desktop mode, I am not sure that I can rely on its continued existence if Windows 9 is hastily released in two years time.
Windows Forms, at least, is a 10+ year old, mature technology, and there are so many business applications built with it that Microsoft won’t risk dropping the technology completely. But it seems such a shame not to embrace something more modern and design for the future.
I really would like to know.
I already have the User Interface design. I already have the complex date and layout algorithms done. I have already gone through alphas and betas and three years of customer feedback to reach an application I am happy with.
The hardest part of developing a Windows version should already be behind me. If Microsoft was Apple, I would have picked up Cocoa and knocked out a tiny prototype of the basic interface functionality in the time it has taken me to write this blog post. If I was porting the other way, I would already be sketching class structures and writing code.
Instead, I am stuck at the starting line, crippled with doubt. Any of the technologies could have the best long term future. Any of them could force me to abandon them and start again from scratch with a different framework 3 years from now. As a single developer working on a niche product, that is a big risk to take.
If Microsoft had a single clear direction, they wouldn’t be forced to support so many disparate technologies. It could be so much smoother for everyone.
If there are any Windows developers who have made it this far into the post, I would welcome your suggestions.
In brief, I have created a timeline application. From a technical standpoint, this means drawing potentially hundreds, or even thousands, of events and other data onto a large scrollable area. This involves drawing a lot of lines, a lot of rounded rectangles, and a lot of text next to or inside those rectangles.
The user can click and drag around events to different locations, they can zoom in or out of the timeline to adjust the time scale (modifying the width of the scrollable area, and the placement of the lines etc).
It means that I need a framework where I can perform hundreds/thousands of drawing operations inside a Canvas/View, drop that inside a Scroll View, using a framework that can handle it efficiently so that the display remains fast and responsive as all the scrolling and zooming takes place (eg. it would need some way for me to only perform the drawing inside the visible portion of the scroll view, if that doesn’t come as default behaviour).
Various split views, text fields, additional windows and toolbars etc. will go along with this, but I am assuming that the fast, efficient drawing will probably be the most likely deciding factor.
So, which framework would you suggest?
Is WPF, with its focus on user interfaces, the best option, or is it too slow? Do .NET forms provide the drawing capability required? Would it be fast enough? Am I better off dodging the Microsoft frameworks altogether and using wxWidgets or Qt instead?
Even links to good, up-to-date resources on the trade offs would be appreciated.