So, I was sent off to the DevConnections conference in Las Vegas recently. I was there as an exhibitor, but I also had a full attendee pass and was told to attend sessions as much as I could while there. There was a lot to learn there specifically on Metro and HTML 5. I'm writing now to summarize some of the things that were key points accross the sessions that I attended.
New C++ Features
I'm actually going to start with the new features of C++ in Visual Studio 11 as it is the shortest and probably in my opinion the most important.
One of the biggest surprises here was Microsofts statement regarding the state of C++ in software development today. IT'S BACK! That's right, as far as Microsoft claims to be seeing the interest and desire to work in C++ is growing again. It was thought for quite some time computers were surpassing the software we were putting on them so there was no need to go through the extra effort of C++/Native development.
The biggest things for me and I assume many developers with an interest and desire to work in C++ that are very good to hear are these two things:
- Intellisense has greatly improved
- Types are now color coded
I know these are not as big of a deal as they seem, but for many years C++ has been a painful experience while these two features greatly reduce just how painful that is. If you have used C++ in the VS 11 Beta already you have probably seen this.
There are a few things that are both really great and a little weird at the same time. For example there are a few new keywords added, one specifically I am not in full agreement on is the "auto" keyword. If you're familiar with var in C# or a few other various languages it basically does the same thing. Auto does not require a type definition, it requires a specific template based instantiation, but does not works very similar to var as it does not specify a type. It does delete itself, so it behaves a lot like a managed memory allocation. I refuse to use automatic type resolution myself so this was not appealing to me personally, and chances are if I'm developing in C++, it is to get away from managed and this sounds too much like managed behavior, without the CLR.
The last big implementation is that XAML can now be used with C++ when using WinRT. Yes, that's right Metro apps can be developed with C++ as well if you didn't already know this.
Something else really neat that threw me off a bit, mainly because they did not show much of what they meant was that supposedly the new Libs for C++ are more DirectX friendly and allow writing 2D/3D graphics in standard C++ libraries. It seemed to me all they really did was include DirectX in the standard Libs/Headers and that's just all it really seemed to be, still cool, but I don't know if it was a HUGE thing for me.
WinRT / Metro
This is where things start getting fun. WinRT and Metro are "practically" the same. So, let that sink in a moment...
Ok, unlike .NET WinRT communicates directly with the Operating System, but is also exclusive to Windows 8 and will not be ported for compatibility in Windows 7, which I think most everyone is aware of. What exactly is WinRT though? It is a new API for development which is NATIVE not managed for development of Metro applications in Windows 8.
WinRT is actually Native COM to be more specific. The DLLs/Assemblies are compiled with CLI metadata the same as .NET and actually... the code you write will very much resemble .NET. Another big kicker is that many of the .NET 4.5 objects ARE WinRT objects. Just in .NET they hit the CLR BEFORE going to WinRT.
INFORMATION OVERLOADED, take a breath...
Ok, now given the fact that WinRT is Native COM what does this give us? Unlike .NET the "common language runtime" WinRT is ACTUALLY more so a common language runtime than .NET by a thousand times. WinRT can be used in C#, VB, C++, Javascript/HTML, and pretty much anything else that can access COM. Another big factor is that ALL WinRT is XAML ready, sooooo... C++/XAML applications are possible where they were not really before.
There are a few downers to this though, WPF/Silverlight developers are not going to be as happy as they originally may have thought. WPF and Silverlight use XAML and so does Metro, but as one of the speakers at DevConnections stated XAML needs to be stated for what it really is and not associated directly with WPF/Silverlight.
XAML as he puts it is a language for object instantiation. Yes, this is true, but there is more to it than that. It defines data bindings as well and some extra syntax for handling event mapping as well. Basically think XML with a twist.
That being said, XAML in Metro communicates with WinRT, while WPF and Silverlight communicated with .NET or the Silverlight specific binaries. The objects and properties may be different... Actually you will find that only the MAJORLY used pieces of each were ported exactly as they are. So, just because you know WPF or Silverlight does not mean it's going to be easy, but it is NOT as bad as some are making out to be. General development should be rather simple, but most Metro apps will need a rewrite anyway to comply with the proper paradigm for Metro.
HTML 5
I really didn't take as much from these sessions. This is mainly because all they were really saying was it's an idea, you can use polyfills to add support to browsers that don't have it. There was some mention of more specifics, but there was nothing too glamorous or interesting to me aside from a little more realization to what the big fuss is. Oh and Opera is the most feature filled browser at this time. HTML 5 is very friendly will cell phones.
LOOK UP MONDERNIZR, this site has a ton of useful polyfills and scripts for making HTML5 work everywhere, even IE6.
Aside from that, I really don't have a whole lot here.
Conclusion
Ultimately, this article is not nearly as glamorous as I wanted it to be, but it's hard to get too deep into the specifics without losing majority of the people who may read this. Either way, I hope there was something here that sparked interest enough to do some of your own research.
No comments:
Post a Comment