Tim Anderson's ITWriting » silverlight

Nokia results: hope for Windows Phone?

tim — Thu, 26 Jan 2012 13:53:56 +0000

It is almost one year since Nokia’s dramatic announcement that it would transition its smartphone range to Windows Phone. Today the company released its results for the fourth quarter and for the full year 2011, the first since the release of the the Lumia range of Windows Phone devices. How it is doing?

This is one you can spin either way. The negative view: Nokia is losing money. Sales are down 21% year on year for the quarter and 9% for the full year, and the company reported an operating loss of just over a billion Euro for the year, most of which was in the last quarter.

If you look at the quarter on quarter device sales, they are down in both smart devices and mobile phones. The Symbian business has not held up as well as the company hoped:

changing market conditions are putting increased pressure on Symbian. In certain markets, there has been an acceleration of the anticipated trend towards lower-priced smartphones with specifications that are different from Symbian’s traditional strengths. As a result of the changing market conditions, combined with our increased focus on Lumia, we now believe that we will sell fewer Symbian devices than we previously anticipated.

says the press release. As for Windows Phone and Lumia, CEO Stephen Elop says that “well over 1 million Lumia devices” have been sold: a start, but still tiny relative to Apple iOS and Google Android. Elop cleverly calls it a “beachhead”, but given the energy Nokia put into the launch I suspect it is disappointed with the numbers.

Put this in context though and there are reasons for hope. First, Nokia’s speed of execution is impressive, from announcement to the first Windows Phones in nine months or so. Further, the Lumia (judging by the Lumia 800 I have been using) does not feel like a device rushed to market. The design is excellent, and within the small world of Windows Phone 7 hardware Nokia has established itself as the brand of first choice.

Second, despite the dismal sales for Windows Phone 7 since its launch, there are signs that Microsoft may yet emerge from the wreckage inflicted on the market by iOS and Android in better shape than others. WebOS has all-but gone. RIM has yet to convince us that it has a viable recovery strategy. Intel Tizen is just getting started. If Microsoft has a successful launch for Windows 8, Elop’s “third ecosystem” idea may yet come to fruition.

Third, Nokia has already shown that it is better able to market Windows Phone 7 than Microsoft itself, or its other mobile partners. Lumia made a good splash at CES in January, and the platform may gain some market share in the influential US market.

Nokia is not just Windows Phone though, and even if its smartphone strategy starts to work it has those falling Symbian sales to contend with. It will not be easy, even taking an optimistic view.

Nor will it be easy for Windows 8 to succeed in a tablet market owned by Apple at the high end and by Amazon/Android at the low end.

Why Microsoft is scrapping the MIX conference

tim — Tue, 24 Jan 2012 18:14:13 +0000

Microsoft is scrapping its MIX conference, according to General Manager Tim O’Brien:

we have decided to merge MIX, our spring web conference for developers and designers, into our next major developer conference, which we will host sometime in the coming year. I know a number of folks were wondering about MIX, given the time of year, so we wanted to make sure there’s no ambiguity, and be very clear… there will be no MIX 2012.

O’Brien says that MIX started in the aftermath of the 2005 PDC because:

there was a lot of discussion around our engagement with the web community, and how we needed a more focused effort around our upcoming plans for Internet Explorer, the roadmap for our web platform, the work we were starting on web standards (we were shipping IE6 at the time), and so on.

That is not quite how I recall it. PDC 2005 was the pre-Vista PDC, no, not the “three pillars of Longhorn” in PDC 2003, but the diluted version of Longhorn that was actually delivered as Windows Vista. One thing Microsoft really did get around this time was that design mattered. Apple had cool design, Adobe had cool design (and a strong grip on the designer community), but Microsoft did not.

Windows Presentation Foundation (WPF) was intended to win designers to the Windows platform, with its graphically-rich and multimedia-friendly API. In order to do this, the company needed to win designers over to the idea of using Expression Blend rather than Adobe Flash and Photoshop.

This was doubly true when Microsoft decided to bring WPF to the browser in the form of Silverlight, a decision that was announced at PDC 2005 and expanded on at the first MIX in 2006.

One of the things I recall at the first and second MIX events were groups of bemused Flash designers who had been bussed in by Microsoft to enjoy the lights of Vegas and learn about Blend.

General web authoring was a factor as well, as Microsoft sought to bring Internet Explorer back on track and to persuade web designers of the virtues of Microsoft’s web platform.

I enjoyed the MIX events. They were small enough that you could easily get to speak both to attendees and to the Microsoft folk there, and once you allow for the fact that Vegas is Vegas, the atmosphere was good.

As an attempt to appeal to designers though, MIX was a failure. It was all too forced; many of the people attending were developers anyway; and Microsoft itself included more and more developer content in ensuing MIX events.

The 2010 MIX was hijacked by Windows Phone 7, an interesting topic but drifting far from the original intentions.

It comes as no surprise to hear than MIX is no more. It is associated with WPF and Silverlight, neither of which are now strategic for Microsoft in these days of Windows 8 and the Windows Runtime (WinRT).

That said, Microsoft still has difficulty appealing to designers.

What next then? O’Brien says:

we look ahead to 2012 and beyond, the goal is to ensure that global Microsoft developer events are of the caliber that many of you experienced at BUILD last September, in addition to the thousands of online and local developer events we host around the world to support communities and connect directly with developers. We will share more details of our next developer event later this year.

Silverlight 5 is done. Is Silverlight also done?

tim — Fri, 09 Dec 2011 23:07:55 +0000

Microsoft has has announced the release of Silverlight 5.0.

Silverlight is a cross-platform, cross-browser plug-in for Windows and Mac. It is relatively small size – less than 7MB according to Microsoft, though the Mac version seems to be bigger, with a 14MB compressed setup .dmg and apparently over 100MB once installed:

Never mind, it is a fine piece of work and has considerable capabilities, including the .NET Framework, the ability to render a GUI defined in XAML, multimedia playback, and support for applications running inside the browser or on the desktop. New in version 5 is better H.264 performance, 3D graphics, and Platform Invoke support on Windows enabling trusted applications to call the native API. Another change is that in-browser applications can also run with full trust, again only on Windows. The cross-platform idea has become increasingly diluted.

If Microsoft had come up with Silverlight early in the .NET story it might have become a major application platform. As it is, while still useful in some contexts, the technology has been side-lined by new things including HTML 5 and the Windows Runtime in the forthcoming Windows 8.

While I have huge respect for the team which created Silverlight and rapidly improved it, it now looks a sad story of reactive technology that failed to capture sufficient developer support. Microsoft invented Silverlight when Adobe Flash looked like it might take over as a universal runtime for web applications. The outcome was that Adobe evolved Flash with renewed vigour, keeping Silverlight at bay. Then Apple invented a new platform called iOS that supported neither Flash nor Silverlight, and the whole plug-in strategy began to look less compelling. Adobe has now reduced its focus on Flash, while Microsoft has been signalling a reduced role for Silverlight since its Professional Developers Conference in October 2010.

The question now is whether there will ever be a Silverlight 6.

Microsoft itself uses Silverlight across a number of products, such as administrative consoles for various server applications. Silverlight will be around for a while yet. Of course it is also the runtime for Windows Phone 7. Visual Studio LightSwitch generates Silverlight applications, and this one I am rather sad about, because it is an interesting tool that now seems to target the wrong platform. Perhaps the team will create an HTML 5 version one day.

Windows Runtime must come to Windows Phone

tim — Thu, 29 Sep 2011 12:15:23 +0000

I’ve been trying Windows Phone 7 in its latest “Mango” version over the last couple of days and mostly enjoying it. One thing I am not impressed by though is the range of apps available. Have a look at the Marketplace – Microsoft may claim 30,000 apps, but given how unexciting even the “top” selections are, you can imagine how bad the bottom ones must be. Microsoft I guess has been guilty of accepting almost anything to puff up the numbers.

What would fix this? Sell more phones, of course; but also improve the platform for developers. Windows Phone 7.x is not a bad platform: you get Silverlight, XNA, C# and Visual Studio.

By contrast though, the Windows Runtime (WinRT) shown at the BUILD conference earlier this month is a platform mobile developers can love. Here are what seem to me three great features:

Three first-class languages and programming platforms – C#/.NET, JavaScript and HTML 5, C++ and native code. All three are strategic platforms. I particularly like the native code option, as many mobile developers like native code and it is a weakness of Windows Phone 7.
Asynchrony built into the platform. This is a smart move: make every API call that might cause a delay an async-only call. On top of that, build easy async programming into the languages. The result should give apps a responsive user interface almost by default; developers will need to make an effort to freeze the UI.
Contracts which integrate apps with the operating system and with one another. There are five contracts: search, share, play to, settings, and app to app picking (for example, file selection).

Microsoft’s Windows chief Steven Sinofsky says Windows 8 is for tablets but not for phones. But he has to say that, because if Microsoft announced that the current Windows Phone 7.5 is a platform without a future, it would further dampen enthusiasm for the product.

Is there any reason why WinRT should not come to Windows Phone? A few:

Windows Phone is currently built on Windows CE, a cut-down version of Windows, whereas WinRT runs on top of the full Windows API.
The Metro-style UI is designed for tablets rather than phones.
Finally, the existence of Desktop Windows is presumed in the current Windows 8 design. If Microsoft has not had time to work out a Metro-style UI for something, you simply use the Desktop version.

All of these are good reasons why the arrival of WinRT on the phone will be delayed, but none are insuperable. Long-term, I find it inconceivable that Microsoft will persevere with a different programming platform for the phone and for tablets.

What are the implications for Windows Phone developers today? Well, WinRT and Metro borrow from the phone OS, so the porting effort should not be too bad, except in the case of XNA, a .NET wrapper for DirectX which WinRT does not support.

Of course this post is entirely speculative, and I have no insight into Microsoft’s plans beyond what is publicly stated, so there might be other compatibility options when and if the time comes.

And it is time that is Microsoft’s biggest enemy. Fumbling tablet computing has been a costly mistake, and the big question is whether anyone will care how good some future Windows Phone will be, if the ecosystem which Nokia likes to talk about is firmly established as Android vs Apple.

Reflections on Microsoft BUILD 2011

tim — Sat, 17 Sep 2011 16:08:18 +0000

I’m just back from Microsoft’s BUILD conference at Anaheim in California, which lived up to the hype as a key moment of transition for the company. Some said it was the most significant PDC – yes, it was really the Professional Developers Conference renamed – since 2000, when .NET was introduced; some said the most significant ever.

“Significant” does not necessarily mean successful, and history will judge whether BUILD 2011 was a new dawn or the beginning of the end for Windows. Nevertheless, I have not heard so much cheering and whooping at a Microsoft conference for a while, and although I am no fan of cheering and whooping I recognise that there was genuine enthusiasm there for the new direction that was unveiled.

So what happened? First, let me mention the Windows Server 8 preview, which looks a solid upgrade to Server 2008 with a hugely improved Hyper-V virtualisation and lots of changes in storage, in IIS, networking, in data de-duplication, in modularisation (enabling seamless transition between Server Core and full Server) and in management, with the ascent of PowerShell scripting and recognition that logging onto a GUI on the server itself is poor practice.

The server team are not suffering the same angst as the client team in terms of direction, though the company has some tricky positioning to do with respect to Azure (platform) and Server 8 (infrastructure) cloud computing, and how much Microsoft hosts in its own datacentres and how much it leaves to partners.

What about Windows client? This is the interesting one, and you can almost hear the discussions among Microsoft execs that led them to create the Windows Runtime and Metro-style apps. There is the Apple iPad; there is cloud; there are smartphones; and Windows looks increasingly like a big, ponderous, legacy operating system with its dependence on keyboard and mouse (or stylus), security issues, and role as a fat client when the industry is moving slowly towards a cloud-plus-device model.

At the same time Windows and Office form a legacy that Microsoft cannot abandon, deeply embedded in the business world and the source of most of the company’s profits. The stage is set for slow decline, though if nothing else BUILD demonstrates that Microsoft is aware of this and making its move to escape that fate.

Its answer is a new platform based on the touch-friendly Metro UI derived from Windows Phone 7, and a new high-performance native code runtime, called Windows Runtime or WinRT. Forget Silverlight or WPF (Windows Presentation Foundation); this is a new platform in which .NET is optional, and which is friendly to all of C#, C/C++, and HTML5/JavaScript. That said, WinRT is a locked-down platform which puts safety and lock-in to Microsoft’s forthcoming Windows Store ahead of developer freedom, especially (and I am speculating a little) in the ARM configuration of which we heard little at BUILD.

BUILD attendees were given a high-end Samsung tablet with Windows 8 pre-installed, and in general the Metro-style UI was a delight, responsive and easy to use, and with some fun example apps, though many of the apps that will come as standard were missing and there was evidence of pre-beta roughness and instability in places.

The client strategy seems to me to look like this:

Windows desktop will trundle on, with a few improvements in areas like boot time, client Hyper-V, and the impressive Windows To Go that runs Windows from a bootable and bitlocker-encrypted USB stick leaving no footprint on the PC itself. Many Windows 8 users will spend all their time in the desktop, and I suspect Microsoft will be under pressure to allow users to stick with the old Start menu if they have no desire or need to see the new Metro-style side of Windows..

A new breed of Intel tablets and touch-screen notebooks will make great devices towards the high end of mobile computing. This is something I look forward to taking with me when I need to work on the road: Metro-style apps for when you are squashed in an aeroplane seat, browsing the web or checking a map, but full Windows only a tap away. These will be useful but slightly odd hybrids, and will tend to be expensive, especially as you will want a keyboard and stylus or trackpad for working in desktop Windows. They will not compete effectively with the iPad or Android tablets, being heavier, with shorter battery life, more expensive and less secure. They may compete well with Mac notebooks, depending on how much value Metro adds for business users mainly focused on desktop applications.

Windows on ARM, which will be mainly for Metro-style apps and priced to compete with other media tablets. This is where Microsoft is being vague, but we definitely heard at BUILD that only Metro-style apps will be available from the Windows Store for ARM, and even hints that there may be no way to install desktop apps. I suspect that Microsoft would like to get rid of desktop Windows on ARM, but that it will be too difficult to achieve that in the first iteration. One unknown factor is Office. It is obvious that Microsoft cannot rework full Office for Metro by this time next year; yet offering desktop Office will be uncomfortable and (knowing Microsoft) expensive on a lightweight, Metro-centric ARM device. Equally, not offering Office might be perceived as throwing away a key advantage of Windows.

Either way, Windows on ARM looks like Microsoft’s iPad competitor, safe, cloud-oriented, inexpensive, long battery life, and lots of fun and delightful apps, if developers rush to the platform in the way Microsoft hopes.

There are several risks for Microsoft here. OEM partners may cheapen the user experience with design flaws and low-quality add-ons. Developers may prove reluctant to invest in an unproven new platform. It may be hard to get the price down low enough, bearing in mind Apple’s advantage with enormous volume purchasing of components for iPad.

Still, one clever aspect of Microsoft’s strategy is that everyone with Windows 8 will have Metro, which means there will be a large installed base even if many of those users only really want desktop Windows.

I also wonder if this is an opportunity for Nokia, to use its hardware expertise to deliver excellent devices for Windows on ARM.

Finally, let me mention a few other BUILD highlights. Anders Hejlsberg spoke on C# and VB futures (though I note that there were few VB developers at BUILD) and I was impressed both by the new asynchronous programming support and the forthcoming compiler API which will enable some amazing new capabilities.

I also enjoyed Don Syme’s session on F#, where he focused on programming information rather than mere algorithms, and showed how the language can query internet data sources with IntelliSense and code hints in the IDE, inferred from schemas retrieved dynamically. You really need to watch his session to understand what this means.

In the end this was a great conference, with an abundance of innovation and though-provoking technology. In saying that, I do not mean to understate the challenges this huge company still faces.

A few facts about Microsoft’s new Windows Runtime

tim — Wed, 14 Sep 2011 22:52:09 +0000

I’ve just come out of Martyn Lovell’s talk on WinRT internals here at BUILD in Anaheim, California.

Make no mistake: Microsoft has re-invented the Windows API in WinRT. Just to recap, WinRT is the API for Metro-style applications, the touch-centric, app-centric API for tablets and, one presumes, eventually for Windows Phone (though Microsoft has yet to admit it).

WinRT is only useable from Metro applications. You cannot call WinRT from a Win32 application, nor vice versa*. I think it is reasonable to assume that a future version of Windows which runs only WinRT is a possibility; and that Windows 8 on ARM will look a bit like that even though Win32 will still be there, but mainly out of sight; but I am speculating.

Does that mean Win32 is now legacy? In a way, but such a huge legacy that for the moment we should think of Windows 8 as two platforms side by side.

There is no inter-app communication in WinRT other than by the pre-defined contracts built into the system (though Lovell noted that you could always use the file system and polling for a crude inter-process communication).

There is no way to install a shared dynamic library. Apps can only use the system libraries together with what you install with the app. Each app lives in its own context and is isolated. In other words, WinRT is not extensible, other than within your app’s code*.

If you figure out a way to bypass limitations of WinRT by calling other Windows APIs, your app might work but the submission process for the Windows Store will prohibit it.

Versioning is built into WinRT. This means that when Windows 9 comes along, you will be able to code just against the Windows 8 versions of the classes, for compatibility, and your IDE can support this by only exposing the Windows 8 version of the API.

The CLR exists in the Metro environment, for use by .NET applications, complete with JIT (Just in time) compilation. However only a subset of the .NET Framework libraries are included. Microsoft aimed to include only what was necessary for Metro. I am not sure yet what is included and what is not, beyond the obvious (no Windows Forms, for example) but will be investigating what is documented. The native WinRT APIs look similar to a COM callable wrapper from the .NET side. That said, you do not normally need to care about WinRT interfaces, even though these are there in WinRT. Normally you interact with WinRT classes, making it more natural for .NET than working with COM.

WinRT is full of asynchronous calls. Lovell told us that Microsoft had seen in the past that if both synchronous and asynchronous APIs are available for the same function, then developers often use the synchronous version even when they should not, making applications less responsive. The new await keyword in C# makes this easy to code.

WinRT makes use of the ILDasm metadata format which is also used by .NET. This means you get rich metadata for IntelliSense and debugging, but note that the actual runtime is not .NET; they just borrowed the same metadata format.

WinRT objects are reference counted like COM for memory management, with weak references to avoid circularity. You should not have to worry about this; you can code according to the conventions of your language.

There are three ways to write WinRT applications. One is C++, in which case you write directly to the “projection” of WinRT into your language. The second is .NET, in which case your code goes via the CLR. The third is HTML and JavaScript, in which case your code goes via the “Chakra” JavaScript engine also used by Internet Explorer 9 and higher. Lovell assured me that there is little difference in performance in most cases, though there could be advantages for C++ in certain niche scenarios. Of course we heard that story for .NET as well, but from what I have seen it is more plausible in WinRT.

There is no message loop in WinRT. There is no GDI in WinRT. All graphics are via DirectX. XNA, the .NET games framework, is not supported. It seems that you will need to use C++ for fancy DirectX coding, though this is not confirmed. Of course your XAML or Canvas code will be rendered by DirectX under the covers.

It is fascinating to see how Microsoft has borrowed XAML and ILDasm from .NET, but that WinRT is native and not .NET at its core. My take on this is that Microsoft intended to preserve the productivity of .NET, but without any performance compromise.

Despite the inclusion of .NET though, the fact that only a subset of the Framework is available, and that interop to the Windows API will not work*, means that most existing apps will need considerable work to be ported to Metro.

*Updates

A few clarifications.

It has been shown that you can call WinRT from Win32 (the favoured word for Win32 seems to be “desktop applications”) though I’m not sure how useful it is.

Concerning P/Invoke (Platform Invocation) to Win32 APIs, apparently this does work for a certain specified, small subset of the Windows API. It also works for your own native code DLL, with the proviso that if your native code DLL calls a disallowed Win32 API it will raise an error.

WinRT is partially extensible. A Framework Extension is a library which you can reference as a dependency in your app’s manifest. When the app is deployed it will download this dependency from the Windows Store. An example is the C Runtime Library. An extension library installs into its own directory, and can be used by multiple WinRT apps provided each one also references it in their manifests. However, the caveat is that only Microsoft can create these extensions: there is no way to create your own shared extension for general distribution, though an enterprise can deploy a shared extension internally.

PhoneGap comes to Windows Phone

tim — Sat, 10 Sep 2011 03:26:13 +0000

Nitobi has announced PhoneGap for Windows Phone 7, nicely timed just before the Microsoft BUILD conference next week.

PhoneGap is a cross-platform mobile development tool that uses the HTML and JavaScript engine on the phone as its runtime, supplemented by extensions which give access to other device features:

After unpackaging the contents of the www folder, your www/index.html file is loaded into an embedded headless browser control. This is essentially the same paradigm as other platforms, except here it is an IE9 browser and not a webkit variant. IE9 is a much more standards-compliant browser than previous IEs, and implements commonly used html5 features like DOMContentLoaded events, addEventListener interfaces, and CSS3. Be sure to use to get the html5 implementation otherwise the browser may fallback to a compatibility mode, and your code will likely choke and die.

The version for Windows Phone 7, just released in preview, is extended to support features including the camera, accelerometer, contacts, and notifications. There is also support for plugins:

PhoneGap-WP7 maintains the plugability of other platforms via a command pattern, to allow developers to add functionality with minimal fuss, simply define your C# class in the WP7GapClassLib.PhoneGap.Commands namespace and derive your class from BaseCommand.

In general Windows Phone 7 is not well supported by cross-platform toolkits, so PhoneGap support is an interesting development. PhoneGap has a high profile currently, and is being integrated into a diverse range of tools ranging from Adobe Dreamweaver to Embarcadero RadPHP, as well as the standard PhoneGap tools based on Eclipse.

Windows Phone 7 apps, stats and future

tim — Wed, 07 Sep 2011 13:47:42 +0000

Justin Angel, a former Microsoft employee who worked on Silverlight, has posted his analysis of the 24,505 apps he found in the Windows Phone 7 marketplace, exploiting a loophole that lets you get the download links. A few highlights:

97% of the apps are not obfuscated, meaning that it is trivial (with easily available tools) to decompile the source.
90% are Silverlight vs 10% XNA. This is not so much an indicator of the popularity of the two frameworks, but more an indicator of how many apps are graphic-rich games rather than some other kind of utility. Of course if you are making a very simple app, Silverlight is easier than XNA, so that may be a factor too.
99% are C# vs 1% Visual Basic and a smattering of F#. A fascinating stat that makes me wonder what is the future of Visual Basic.

There are more interesting stats about libraries and components used, for which I refer you to the original post.

Does it matter? Well, Windows Phone 7 has not been a big success so far, though the reasons for that are not so much the quality of the OS or the ease of developing apps, but rather its low profile at retail and the fact that most operators and manufacturers don’t really need it: Apple and Android between them pretty much have the market.

That said, there are a few reasons why Windows Phone or some evolution of it may yet be significant. Nokia is betting on it, and while Nokia is undoubtedly in difficulties, this must work in Microsoft’s favour. Further, fear uncertainty and doubt surrounding Android patent and copyright issues may persuade some industry players to give Windows Phone another look.

Perhaps more significantly, when Microsoft unveils its developer strategy at the BUILD conference next week, it is likely that the application model in Windows Phone, or some evolution of it, will integrate with what is planned for Windows 8. NVIDIA is already talking about how Windows 8 will run Windows Phone apps.

For these reasons I believe there is at least a glimmer of hope for Microsoft in the mobile world; certainly the developer story to be officially told next week will be an interesting one.

Adobe says role of Flex and Flash has changed, makes play for mobile

tim — Fri, 26 Aug 2011 08:09:48 +0000

Adobe’s Andrew Shorten has posted on the future of Flex, the developer-oriented tool for building applications for the Flash runtime.

This is one of the clearest statements I have seen from Adobe that recognises that the role of Flash on the web is diminishing:

There are countless examples where, in the past, Flex was (rightly) selected as the only way to deliver a great user experience. Today, many of those could be built using HTML5-related technologies and delivered via the browser, and at Adobe, we will provide tooling to help designers and developers create those experiences – Edge and Muse are two such examples.

Adobe is not giving up on Flash, of course, and states that it is still the best for certain categories of application:

We firmly believe that Flex is already the best technology for building complex, high fidelity enterprise applications such as business dashboards, line of business tools, real time trading applications and desktop replacement applications.

I would add both statements are written from the perspective of application developers. The role of Flash as a video and multimedia player is a separate issue. Flash is also important in that context. There is some overlap, in that if your application includes multimedia content then Flash is correspondingly more attractive.

As an aside, it is interesting to note that this repositioning of Flash makes it not so different from Microsoft’s Silverlight: a runtime for business applications.

Adobe is focusing on a new market for Flex in mobile. This overcomes the Apple iOS problem, since you can compile a Flex application to iOS native code. Adobe promises “additional mobile development capabilities” later this year and says:

In our next major release timeframe we expect that the need to build a fully-native application will be reserved for a small number of use cases.

I agree that cross-platform mobile development is a key area and one where there is no clear winner yet. It is a good opportunity for Adobe, though there is increasing competition from the products like Appcelerator Titanium and PhoneGap.

I also think that Embarcadero’s new RAD Studio XE2 will attract interest. This tool which will be released soon does native code compilation across Windows, Mac and Apple iOS, with Android promised, using the Delphi IDE and language.

Microsoft releases Visual Studio LightSwitch: a fascinating product with an uncertain future

tim — Tue, 26 Jul 2011 19:51:42 +0000

Microsoft has released Visual Studio LightSwitch, a rapid application builder for data-centric applications.

LightSwitch builds Silverlight applications, which may seem strange bearing in mind that the future of Silverlight has been hotly debated since its lack of emphasis at the 2010 Professional Developers Conference. The explanation is either that Silverlight – or some close variant of Silverlight – has a more important future role than has yet been revealed; or that the developer division invented LightSwitch before Microsoft’s strategy shifted.

Either way, note that LightSwitch is a model-driven tool that is inherently well-suited to modification for different output types. If LightSwitch survives to version two, it would not surprise me to see other application targets appear. HTML 5 would make sense, as would Windows Phone.

So LightSwitch generates Silverlight applications, but they do not run on Windows Phone 7 which has Silverlight as its development platform? That is correct, and yes it does seem odd. I will give you the official line on this, which is that LightSwitch is not aimed primarily at developers, but is for business users who run Windows and who want a quick and easy way to build database applications. They will not care or even, supposedly, realise that they are building Silverlight apps.

I do not believe this is the whole story. It seems to me that either LightSwitch is a historical accident that will soon be quietly forgotten; or it is version one of a strategic product that will build multi-tier database applications, where the server is either Azure or on-premise, and the client any Windows device from phone to PC. Silverlight is ideal for this, with its modern presentation language (XAML), its sandboxed security, and its easy deployment. This last point is critical as we move into the app store era.

LightSwitch could be strategic then, or it could be a Microsoft muddle, since the official marketing line is unconvincing. I have spent considerable time with the beta and doubt that the supposed target market will get on with it well. Developers will also have a challenge, since the documentation is, apparently deliberately, incomplete when it comes to writing code. There is no complete reference, just lots of how-to examples that might or might not cover what you wish to achieve.

Nevertheless, there are flashes of brilliance in LightSwitch and I hope, perhaps vainly, that it does not get crushed under Microsoft’s HTML 5 steamroller. I set out some of its interesting features in a post nearly a year ago.

Put aside for a moment concerns about Silverlight and about Microsoft’s marketing strategy. The truth is that Microsoft is doing innovative work with database tools, not only in LightSwitch with its model-driven development but also in the SQL Server database projects and “Juneau” tools coming up for “Denali”, SQL Server 2011, which I covered briefly elsewhere. LightSwitch deserves a close look, even it is not clear yet why you would want actually to use it.