MICROSOFT_PRESS_EBOOK_PROGRAMMING_WINDOWS_8_APPS_WITH_HTML_CSS_AND_JAVASCRIPT_PDF

more specific. For instance, when an email app is shown as an option for sharing, the best it can do is
create a new message with no particular recipients. A quicklink, however, can identify specific email
addresses, say, for a person or persons you email frequently. The quicklink, then, is essentially an app
plus specific configuration information.
Whatever the case, some app is launched when the user selects a target. With the Share contract, the
app is launched with an activation kind of shareTarget. This tells it to not bring up its default UI but to
rather show a specific share pane (with light-dismiss behavior) in which the user can refine exactly what
is being shared and how. A share target for a social network, for instance, will often provide a place to
add a comment on the shared data before posting it. An email app would provide a means to edit the
message before sending it. A front-end app for a photo service could allow for adding a caption,
specifying a location, identifying people, and so on. You get the idea. All of this combines together to
provide a smooth flow from having something to share to an app that facilitates the sharing and allows
the user to add customizations.
Overall, then, the Share contract gets apps connected to one another for this common purpose
without either one having to know anything about the other. This creates a very extensible and scalable
experience: since all the potential target choices appear only in the Share charm pane, they never need
to clutter a source app as we see happening on many web pages. This is the “content before chrome”
design principle in action.
Source apps also don’t need to update themselves when a new target becomes popular (e.g., a new
kind of social network): all that’s needed is a single target app. As for those target apps, they don’t have
to evangelize themselves to the world: through the contract, source apps are automatically able to use
any target apps that come along in the future. And from the end user’s point of view, their experience of
the Share charm gets better and better as they acquire more Share-capable apps.
At the same time, it is possible for the source app to know something about how its shared data is
being used. Alongside the datarequested event, the DataTransferManager also fires a
targetApplicationChosen event to those sources who are listening. The eventArgs in this case contain
only a single property: applicationName. This isn’t really useful for any other WinRT APIs, mind you, but
is something you can tally within your own analytics. Such data can help you understand whether you’d
provide a better user experience by sharing richer data formats, for example, or, if common target apps
also support custom formats that you can supportin future updates.
Source Apps
Let’s complete our understanding of source apps now by looking at a number of details we haven’t fully
explored yet, primarily around how the source populates the data package and the options it has for
handling the request. For this purpose, I suggest you obtain and run both the Sharing content source
app sample and the Sharing content target app sample. We’ll be looking at both of these, and the latter
provides a helpful way to see how a target app will consume the data package created in the source.
495