Windows Phone 7 may not be available yet, but it is a great talking point. Following the collapsing market share of Window Mobile and the Kin debacle, will Microsoft be able to claw its way back into the SmartPhone market? With mobile apps increasingly important in both the consumer and business world, what would be the consequences of failure?
The strategic importance of the platform makes it interesting even if you think that there is little room for Microsoft's phone in a market dominated at the high end by the two As: Apple and Android.
There is even fierce competition among the also-rans, with Nokia pitching Symbian 3 and Maemo/Meego, and HP presumably about to do something with Palm WebOS. And what about Samsung's bada? There will be blood on the carpet; not all these operating systems will survive - and while that will be a shame from the point of view of diversity, it will be a relief to developers attempting to support the broadest number of devices.
So why even bother with Windows Phone 7? Well, there are a couple of obvious reasons. One is the possibility that Microsoft will deliver an excellent and delightful device. Likely? Past form says no; but the company knows what it is up against so you never know; early reviews of preview devices have been generally favourable.
The second reason is less speculative, which is the way Windows Phone 7 fits in with the rest of Microsoft's platform. If you are used to coding in Visual Studio with C#, then creating apps for Microsoft's new phone will be less challenging than doing so for iPhone or Android. A Windows Phone 7 app is essentially a .NET and Silverlight app, or for games XNA, and from what I have seen so far Microsoft has done a good job with the emulator and developer tools.
The disconnect here is that Microsoft's primary target for Windows Phone 7 is the consumer, whereas those armies of Visual Studio developers are largely building corporate apps. Some of them are also annoyed that Microsoft is not providing compatibility with existing Windows Mobile applications.
There are also significant limitations in Windows Phone 7 in its first release. There's no multi-tasking, which means you have to write code to handle your application being shut down and re-activated while giving the appearance of resuming where the user left off. There's no native code, which runs contrary to the instinct of experienced mobile developers, some of whome tried and failed to wrest acceptable performance from the Compact Framework, the mobile .NET Framework from pre-Silverlight days. There's no copy and paste - which does not seem a big deal to me, but some people seem to care a lot about this. Another annoyance is that all apps must be deployed throught Microsoft's Apple-style Marketplace, though I hope and expect that Microsoft will come up with a way round this for corporate roll-outs.
Future iterations of Windows Phone could remove these limitations, but in this instance Microsoft does not have time to release something not very good and get it right three versions later.
I'm keen to hear from developers who have tried the preview devices or the SDK. Like what you see? Intend to support it? I look forward to comments, because the success or failure of this product is going to be significant.
I'm just back from Microsoft's Professional Developers Conference in Los Angeles, where the star of the show was the latest update to the Silverlight browser plug-in that lets you run .NET applications cross-platform and within the browser. The pace of development is remarkable. It is only 9 months ago that we were first shown the beta of Silverlight 3, at the Mix conference in March. Silverlight 3 was fully released in July; and now we have version 4.0 beta, with release promised for the first half of 2010.
It is a big release too. Many of the top Silverlight feature requests are being implemented, including printing, right-click and mouse wheel support, a rich text control with editing, clipboard support (though text-only in the beta), drag-and-drop, interaction with Webcams and microphones, multitouch control, improved just-in-time compilation for faster performance, and improved databinding for business applications.
In addition, the forthcoming Visual Studio 2010 is the first to have the kind of Silverlight development tools you would expect, with a true visual design surface and drag-and-drop data binding. On the server, WCF (Windows Communication Foundation) RIA Services simplify the effort of authentication, talking to data, and integrating with ASP.NET.
Another notable feature is the ability to run a Silverlight application out of the browser, started from a desktop shortcut and displayed in a custom window. New in version 4.0 is an HTML control, which embeds IE on Windows and WebKit (used in Safari) on the Mac. These are desktop/web application hybrids. Silverlight 4 blurs the boundaries, by adding a new trusted mode. Subject to the user passing a security dialog, a trusted out-of-browser application gets local file access to user data, cross-domain network access, and on Windows native code interop through COM automation.
The snag with this last point is that any Silverlight application which uses COM automation will only run on Windows, breaking the cross-platform compatibility which is a key reason to use Silverlight in the first place. Although Microsoft says the feature has been put in simply to meet the requirements of a few Enterprise customers, it seems to me that it goes well beyond that, making Silverlight viable in many scenarios that previously would have required a native solution.
Microsoft's ideal scenario is one where applications run everywhere, but run best on Windows, preserving its desktop lock-in. The company calls this "lighting up the platform"; but Windows is somehow the only platform that gets lit up.
I still think it is time to learn Silverlight. The reason is not only Microsoft's signposting of this as its key technology for future client development, but something else I saw last week: Google's Chrome OS. I'll be writing more about this; but I was impressed by how this forthcoming browser-based operating system promises to solve long-standing problems: cheap, lightweight computers that are secure, that start up instantly, that give us access to all our data, but can be left in the back of a taxi without compromising our secrets.
What if Chrome OS catches on? Does Microsoft become irrelevant? The real world does not move that fast; but considering the continuing popularity of the Mac along with the prospect of Chrome OS, it strikes me as brave to presume a Windows-only client for future development. Silverlight on the other hand should run in Chrome OS, either using Mono's Moonlight, or the Intel port being done for Moblin, or perhaps Microsoft itself will have to dirty its hands with Linux. Google might block Silverlight - it was non-committal on the subject at the Chrome OS press briefing - but I'm guessing that concerns over appearing excessively controlling will trump the desire to shut out a competitor.
The point here is not that Silverlight is the answer for all client development; there are plenty of other strong choices. The point rather is that for Microsoft platform developers Silverlight is the technology that makes it possible to take your C# or VB.Net skills and transition them to a new cross-platform, web-oriented world.
Concurrent programming was a major theme at Microsoft's recent Professional Developers Conference. We all know the reasoning: processors are no longer getting faster, but multiple processors are now commonplace. Even my desktop PC is a quad-core. However, having multiple processors is no guarantee that applications will run faster. For that to happen, the application has to be coded with concurrency in mind. Therefore, if we want to write fast applications, we have to learn concurrent programming.
Unfortunately concurrent programming is hard. Think deadlocks, synchronisation, non-determinant, race conditions, and so on. Fortunately, Microsoft is good at making hard things easy. The original Visual Basic transformed the coding of a graphical user interface from something intricate done in C or C++, to something anyone could do with a few clicks of the mouse.
Now Microsoft aims to do something similar for concurrency. The .NET Framework 4.0 incorporates the Parallel FX Library, which does a great job of simplifying multi-threaded development. The new Task Parallel Library is smart about how many processors it finds at runtime, and spins the right number of threads to take advantage of them. PLINQ lets you easily apply parallelism to LINQ queries. Daniel Moth does a great job of demonstrating the benefits in his session at PDC, which you can watch online; and if you work with .NET I highly recommend it.
The worrying aspect is that while Microsoft is making concurrency easy, it is not making it safe. When I was playing around with Visual Studio 2010 and .NET Framework 4.0, one of the first things I did was to look at my code for counting primes and to see how I could optimize it. I found I could do so easily by changing a For loop to use Parallel.For instead, one of the features of the new library. I got a nice speed boost on a two-core machine, not quite double, but nearly so. One snag: the result changed every time I ran it.
I soon figured out what was wrong. My code declares a numprimes variable, then increments it within the loop. Everything is fine when single-threaded, but if you have two threads running the loop in parallel, they might both increment the variable at nearly the same time. That means reading the value, incrementing it, and writing it back. Occasionally this happens:
Result: the value is one less than it should be. The fix is to lock the value first, or to find a better approach; this exact problem is discussed here (scroll down to Aggregation).
Bugs are nothing new in programming, but concurrency bugs are particularly tiresome. The code may work fine on some machines; in my example, the bug would not occur on a single-core PC. If your loop is a little less tight than a prime number calculator, it might be that the odds of the bug occurring at all are rather small. It could even pass all your unit tests. Deploy the application though, and you can bet that wrong results will soon crop up with the usual potential for calamity.
Haven't we already had, and survived, this problem with previous abstractions like BackgroundWorker, a class in .NET Framework 2.0 that makes it easy to push some code into a background thread? True to some extent, but BackgroundWorker is less dangerous because it is typically used more for keeping an application responsive, than to increase performance with parallel threads on a multi-core system.
The bottom line is that while I am full of admiration for the work Microsoft has done with the Parallel FX, I have a nagging worry that as more and less skilled programmers are encouraged to do this, we may be introducing a new wave of buggy code, as argued in detail by Edward Lee in his paper The Problem with Threads [PDF]. The hardware trend is real though, so I suspect greater concurrency in everyday business applications is coming whether we like it or not.
The other conclusion is that before using something even as apparently simple as Parallel.For, developers have a responsibility to learn about the pitfalls as well as the benefits.
