Since the pre-release of Windows 8 at the Microsoft BUILD conference in 2011, I’ve been investigating the different ways for a Windows Store App (WSA in the rest of the post) to interact with either other WSAs or Desktop Apps (DA in the rest of the post). Unlike .NET that was built from the beginning with interoperability in mind, WinRT is another beast.
A Microsoft collegue has been working on a WSA that makes it simple to deploy and launch applications in an enterprise environment (visit http://companystore.codeplex.com/ for more details). However, some actions are not allowed from a WSA such as looking for installed WSAs and launch them. This was a great opportunity to turn my research into real code. I’m sharing the outcome in a few blog posts starting with this one.
The WinRT API comes with well-defined contracts that let WSAs interact both with the system and with other WSAs. Note that the data and the user interface are strictly controlled in each case and DA are not eligible to be part of the dance (except for Clipboard):
- Share: sort of Clipboard on steroid, a source App lets the user select data to be shared with other target WSAs via well-known formats (text, image, uri) or even custom schemas.
- Search: WSAs receive textual input from the user via the Charm UI and provides feedbacks and recommendations; not usable to exchange data between applications.
- File Picker: a “providing” WSA is able to show custom UI to the user in a “get a file“ workflow retrieved by a “calling” WSA; a sample from the Windows SDK is available.
With this contract, you could easily imagine implementing a WSA that would provide a non-file oriented UI and return information via a file; this file would contains a documented set of data that would be parsed by the calling WSA. This is circumvented but totally feasible: for example, a WSA could implement the File Picker contract and let the user scan a bar code via a nice UI that drives the camera. The returning file would contains the bar code description in XML for example. You can see this kind of interaction as the opposite as the Share Contracts: the user is in the WSA where the information is needed and she accesses the source WSA via the File Picker Contract. The big limitation is the lack of parameter the calling WSA could pass to the providing WSA…
Let’s be clear, this is not the way this contract is supposed to be used because the UI provided by the system is very FILE oriented, but… it works. Last but not least, a private file extension should be chosen to limit the number of choices automatically offered by the picker.
- The usual Windows Clipboard is accessible for WSAs via the same DataPackage and DataPackageView types used by the Share Contract. The corresponding guidelines are available on MSDN.
As you can see, all these solutions are limited compared to the other kinds of inter-process interaction available to Windows Desktop Applications such as COM interop, Dll-based API, sockets or Web Service calls. Even though sockets and web service calls are allowed for WSA, there is no way to make them work toward an end point on the same machine (except during development for testing purpose).
Is it possible to go beyond the new contracts? Well… To allow WSAs and DAs to communicate, it is still possible to use two mechanisms that existed for a very long time in the Windows Shell and that are supported by WinRT: file and protocol associations. Both associations allow either a WSA or a DA to start a WSA/DA with parameters: file(s) for the former and url for the latter. The next post will dig into the details of the file association.