The second day of the BUILD conference was dedicated mostly to breakout-style sessions on the various topics covered only in brief during the keynotes. Some of the new stuff I’ve seen today in pseudo-random order:
Visual Studio 11
- Productivity Power Tools (with over a million downloads)! are going to be built-in in Visual Studio 11.
- You can right-click a piece of code in Visual Studio and select “Find Matching Clones” for a similarity analyzer that detects copy-paste across the board.
- Visual Studio will feature a revamped image editor and a viewer for 3D models.
- TFS will be available through Windows Azure as a SaaS offering. This includes a nice web front-end with a Scrum board (including post-in notes :-)).
Metro applications adhere to an application lifecycle model that is very reminiscent of Windows Phone (and other mobile operating systems). Namely, when a Metro app is launched, the previous application goes off the screen and becomes suspended. Prior to suspension, the app gets 5 seconds to save transient state. Suspended apps are not removed from memory, but all their threads are suspended.
After an application has been suspended, the user can return to it, which will resume it from the suspended state. However, it’s also possible that the system will terminate the app because of a low memory condition. In this case, when the application is relaunched, it has to restore its state from persistent storage and appear to the user as if it has never been gone.
In addition to the simple activation model whereas the user launches the app from a start screen tile, applications can be launched through contracts – an app-to-app communication mechanism. For example, if an app can send information to your Facebook friends, and you use the “Share” charm within any other app, Windows will present to the user your application and it might be invoked with the user-provided data. Your app will have to check its activation context and retrieve from it the custom data to share.
Even though most applications will be suspended when the user is not interacting with them, it is still possible to engage in certain background activities without forgoing the Metro-style UI. For example, your app can play background audio while in the background. Another option is to be a “lock-screen app” which can periodically run code in the background and maintain persistent TCP connections (this would obviously be required of an email or instant messaging app).
The goal of WinRT is to provide a native foundation for Metro-style applications. It is not a replacement for all Windows programming frameworks, and it is not a replacement for .NET – it is only intended as a framework for Metro-style applications to interact with.
Possibly the biggest change is in the way WinRT components are consumed and implemented in C++. Considering that WinRT components are glorified COM objects, one might expect the horrors of native C++ consuming COM, what with smart interface pointers, managing lifetime through scopes, and so on. Fortunately, the C++ compiler supports a new switch, /ZW, which compiles new syntactic extensions to code that manages WinRT objects. For example, a ^ is a reference to a reference-counted WinRT object, so whenever you manipulate a Platform::String^, for example, the compiler inserts the necessary IUnknown::AddRef and Release calls. (This is akin to the way Objective C on Mac OS X 10.5 implements automatic garbage collection.)