To a large extent, operating systems owe their acceptance and circulation to successful applications. A successful application is essentially an one that allows the user to perform a common task in a seamless and comfortable way. In the beginning of computing, common tasks were relatively simple and a single application could take care of them from start to finish. Take the creation of a document: A user types some text and saves it to a persistent store. A single application for example, Notepad can take care of all the steps.
But "simple" tasks became more and more sophisticated over time. Subsequently, applications had to catch up and became, themselves, more and more complex. Consider another example: capturing a picture via webcam. Taking the picture is the least complex part of the task and arranging an application to handle this is no big deal. It is much more critical arranging the next step the user may want to take deciding what to do with the picture. Should the picture just be saved to disk? Should the app offer an option to upload the picture somewhere? Should the picture be sent to a graphical editor? Worse yet, each user may come up with a different list of "share" options. More recently, architects of applications introduced plugins to address extensibility and user customization. While effective, plugins make even simple applications increasingly complex. And applications that are too complex are good for neither developers nor users.
The complexity of even simple applications is largely due to the abundance of use-cases that would be better implemented through some combined interaction of multiple (and possibly simpler) applications. Unfortunately, application interaction was never properly addressed in the Windows space. Over the years, we've seen different attempts including clipboard, service bus, and (to a lesser extent) common dialogs. Most developers had to resort to custom solutions. Custom solutions, though, are limited to a subset of known applications. In Windows, we never had a system-wide protocol enabling applications developed by different companies to communicate and share data.
This is precisely what Metro contracts bring to the table.
Metro Contracts In Action
Returning to the photo sharing example. In Windows 8, you can write your simple application to capture a photo from a webcam, optionally save it to disk, declare it can be made available to others, and just stop there. If user Bob wants to upload the picture to his Facebook account, all he does is tap the Share charm and select the social network app. Likewise, if user Alice wishes to touch-up to her picture, she just shares the picture with her favorite graphical editor.
The webcam application declares its availability to share some content by implementing the Share contract one of the default contracts in Windows 8. The Share contract comes in two flavors an application can be the Source and/or the Target. Being a Share Source means the application holds some data that can be shared on demand. Being a Share Target makes an application capable of picking its input data from other applications coded as Share Sources. Share Target applications are listed in the Charms bar.
From a more technical perspective, a Share Source application adds a thin extra layer over its core functionality. Our sample webcam application, for example, will do its basic photo acquisition job, plus copying its shareable data to an ad hoc memory structure in response to a well-known system event. This system event is fired when the user opens the Charms bar while the application is active. This action is interpreted as the desire to share the public content of the current app in our case, the webcam app with a selected Target.
When I first approached Metro contracts in Windows 8, I spotted a mild similarity with the traditional Windows clipboard. It's not the same, of course, but I still like to think of the specific Share contract as a more powerful clipboard. (By the way, the main difference with the classic clipboard is that shared data is not copied to some common memory area where it can be overwritten when multiple applications use the same feature. Instead, shared data has to be explicitly requested and will typically be overwritten only when the source application or more likely, the user decides to replace or clear it.)
Other Metro Contracts
In Windows 8 Metro, the Share contract is one of the most interesting contracts, but it is not the only one. Metro supports quite a few types of contracts for common scenarios such as Search, Print, and a few "pickers" including File Open, File Save, and Contacts. Pickers remind me of common dialog boxes from back in the late 1990s and the parallel between them is closer than the one between the Share contract and clipboard. Contracts for pickers work nearly the same as common dialog boxes worked, except for the much tighter integration with the host user interface you can achieve in Windows 8.
Metro contracts bring a substantial change to general Windows application development. Paraphrasing a popular principle of software development, contracts help apply the Single Responsibility Principle to application-level granularity. Contracts apply a form of normalization to complexity, thus leading to simpler, more reusable applications. As the simple webcam example has shown, you no longer need to duplicate the same logic (say, uploading a picture to Facebook) in multiple applications. You simply write your app to publish some shareable data and make users responsible for setting their preferred tools to share that content. At the same time, if your app consumes some data (say, uploads a photo to Facebook), you are not necessarily forced to write the logic to retrieve the picture to upload. You can use Search or picker contracts to find the picture yourself through code written by others. In addition, you can implement the Share Target contract and have other applications pass you the data to process directly. Simpler is always better, and really more reusable.