There is a ton of discussion going on around the announcements at //BUILD/ this week and what the implications are for Silverlight developers and for the future of Silverlight itself. A lot of that speculation has quickly sped to the realm of FUD. As a Silverlight MVP, I for one thing the future is quite bright and shiny for Silverlight developers, and even for Silverlight applications in terms of moving to the new platform and building Metro style applications. If you have no idea what a “Metro style” application is or what WinRT is, you have lots to read. The short story is that a WinRT application is one built for codename Windows 8, and one that runs with the new user interface style and experience called Metro. Just go check out some of the many videos available now of Windows 8 to get a better sense of what this means. But from a developer perspective, it mean you build a client app to run against the new Windows runtime (WinRT), and it is not a .NET Framework application. There is a lot more to say there, but that is for other posts. What I want to focus on here is what it means at a high level for Silverlight developers. If you are a Silverlight developer, here are a set of characteristics of your application that you have to deal with on every Silverlight app you write because they are part of the platform: It is a XAML-based user interface application, with code behind in C# or VB
The XAML that you use is a constrained set of XAML compared to WPF – there are some capabilities missing, even in SL5
It runs in a security constrained sandbox by default, with constrained access to underlying machine capabilities
Anything in the platform API (Silverlight) that might take “a while” is only exposed as an Async APISo what are some of the things we can say about developing Metro apps at a high level? These same exact statements about the platform hold true for Metro, they just have some slightly different manifestations. This means that not only will developing applications for Windows Metro feel familiar and comfortable to Silverlight developers, more of their code will be portable to Metro applications than other .NET UI applications. Now I am not saying your Silverlight apps are going to “just run” or that you won’t have to do some non-trivial porting to turn a Silverlight application into a Metro application, but there will be a lot less impedance mismatch there than there will be for your typical WPF or Windows Forms application. Those applications will likely have tons of code that is doing synchronous things that have to become async, and probably also use parts of the .NET Framework capabilities that just wont exist in WinRT, at least for the first release. However the kinds of capabilities that are in the Silverlight plug in and its supporting libraries are exactly the kinds of things that WinRT will support, just with different namespaces, type names, and some different API member names and arguments.
Read more: Brian Noyes blog
QR:
The XAML that you use is a constrained set of XAML compared to WPF – there are some capabilities missing, even in SL5
It runs in a security constrained sandbox by default, with constrained access to underlying machine capabilities
Anything in the platform API (Silverlight) that might take “a while” is only exposed as an Async APISo what are some of the things we can say about developing Metro apps at a high level? These same exact statements about the platform hold true for Metro, they just have some slightly different manifestations. This means that not only will developing applications for Windows Metro feel familiar and comfortable to Silverlight developers, more of their code will be portable to Metro applications than other .NET UI applications. Now I am not saying your Silverlight apps are going to “just run” or that you won’t have to do some non-trivial porting to turn a Silverlight application into a Metro application, but there will be a lot less impedance mismatch there than there will be for your typical WPF or Windows Forms application. Those applications will likely have tons of code that is doing synchronous things that have to become async, and probably also use parts of the .NET Framework capabilities that just wont exist in WinRT, at least for the first release. However the kinds of capabilities that are in the Silverlight plug in and its supporting libraries are exactly the kinds of things that WinRT will support, just with different namespaces, type names, and some different API member names and arguments.
Read more: Brian Noyes blog
QR:
Posts
0 comments:
Post a Comment