Microsoft's new Windows 8 contracts: The debut of the developer clipboard

Microsoft has introduced a new developer concept known as "Contracts" with Windows 8. Think of it as a universal clipboard for apps and services that ties back to Internet Explorer 10.
Written by Mary Jo Foley, Senior Contributing Editor

One of the many new terms introduced during the whirlwind that was the Microsoft Build conference in Anaheim the week of September 12 was "contracts."

During the opening Build keynote, Windows President Steven Sinofsky mentioned in passing the new "contracts" functionality that will be integrated into Windows 8. But he didn't delve into exactly what contracts are or how they'll work.

In a workshop attended by some press and analysts a day before his keynote, however, Sinofsky mentioned contracts as being a key element of the Windows 8 development platform.

"Applications should be able to work together without knowing anything about each other," Sinofsky told us workshop attendees. He cited an example using a few of the different "charms," or main icons, in Windows 8. (The five charms are Devices, Settings, Share, Search and Start.) Applications  and services -- including the coming Windows Live app/service hybrids -- that implement contracts will be able to make use of a data package from Internet Explorer 10, enabling users to remain inside of an app from which they are sharing, searching, etc. In Windows 8, there are share contracts, search contracts and "picker" contracts. I'm not sure if there are others.

Sinofsky told us workshop attendees that the closest analogy to a "contract" is a clipboard. (That got me thinking about former Microsoft Chief Software Architect Ray Ozzie's "universal clipboard" concept -- dating back to 2006. Ozzie's universal clipboard, which he released under a Creative Commons license, was focused on connecting Web sites and desktop applications using a combination of RSS feeds, other XML data and the desktop clipboard. I don't know how much the Windows 8 team relied on Ozzie's vision and code, if at all.)

Microsoft officials did share more about the contracts concept during one of the Build sessions focused on the "Share" contract. The "currency" in a Share contract what's known as a DataPackage. The data can be captured and shared in a number of different formats, including text, URI, HTML, images and other extensible formats.

Source apps in the Share scenario can include news, magazines, media, games, social networking data, notes captured via a note-taking program and data stored in the cloud. Target categories on which Microsoft is expecting developers to focus include social networking, communication, entertainment, print services, "device connected" scenarios, note-taking and cloud storage. Here's the obligatory architecture slide showing how this sharing will look/work, from the Build slide deck on the topic:

(click on the slide to enlarge)

From a user standpoint, the "Share" contract may sometimes be invoked after a user selects content inside of an app and then selects the "Share" charm. Other times, users won't need to do anything; by selecting "Share," content may be auto-selected.. Microsoft is advising developers to build their data packages in a way that makes the most sense (whether that requires no user content selection, or whether it requires a user to select content).

Here's another slide from the Share Contract presentation, outlining some of the benefits Microsoft expects to accrue via Contracts:

(click on slide to enlarge)

I'll be curious to see what developers come up with around Contracts. Microsoft has met with a so-so reception for some of its previously introduced Internet Explorer-specific capabilities, like Jump Lists and app pinning. Will Contracts be any more popular? What do you think, Windows Developer preview testers?

Update: As reader and Red Badger founder David Wynne noted on Twitter, the concept of "code contracts" is something that the Microsoft Research folks have been investigating, as well. At MSR, code contracts are "language-agnostic ways to express coding assumptions in .Net programs."

Editorial standards