{"id":110085,"date":"2024-08-01T07:00:00","date_gmt":"2024-08-01T14:00:00","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/oldnewthing\/?p=110085"},"modified":"2024-08-01T10:35:10","modified_gmt":"2024-08-01T17:35:10","slug":"20240801-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20240801-00\/?p=110085","title":{"rendered":"What’s the difference between Data­Package­View.Get­Uri­Async<\/CODE> and Data­Package­View.Get­Web­Link­Async<\/CODE>?"},"content":{"rendered":"

The Windows Runtime Data\u00adPackage<\/code> object has methods for manipulating three types of URIs:<\/p>\n\n\n\n\n\n\n
Standard\u00adData\u00adFormats<\/tt> value<\/th>\nData\u00adPackage<\/tt> method<\/th>\nData\u00adPackage\u00adView<\/tt> method<\/th>\n<\/tr>\n
Uri<\/code><\/td>\nSet\u00adUri<\/code><\/td>\nGet\u00adUri\u00adAsync<\/code><\/td>\n<\/tr>\n
Web\u00adLink<\/code><\/td>\nSet\u00adWeb\u00adLink<\/code><\/td>\nGet\u00adWeb\u00adLink\u00adAsync<\/code><\/td>\n<\/tr>\n
Application\u00adLink<\/code><\/td>\nSet\u00adApplication\u00adLink<\/code><\/td>\nGet\u00adApplication\u00adLink\u00adAsync<\/code><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

What do the three different URIs mean, and how do they differ?<\/p>\n

Once upon a time, there was only one URI data format. And it was called Uri<\/code>.<\/p>\n\n\n\n\n
Standard\u00adData\u00adFormats<\/tt> value<\/th>\nData\u00adPackage<\/tt> method<\/th>\nData\u00adPackage\u00adView<\/tt> method<\/th>\n<\/tr>\n
Uri<\/code><\/td>\nSet\u00adUri<\/code><\/td>\nGet\u00adUri\u00adAsync<\/code><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Windows 8.1 added a second URI data format called Application\u00adLink<\/code>, so that apps could add a link that relaunched the app to return to the item that was copied. For example, if the Contoso app copies a customer service record to the clipboard, it can add an Application\u00adLink<\/code> that is a link into the Contoso app that navigates to that customer service record.<\/p>\n

Since we now had two URI data formats, it was confusing to have a data format named simply Uri<\/code>, so the old Uri<\/code> format was renamed to Web\u00adLink<\/code>.<\/p>\n\n\n\n\n\n
Data format<\/th>\nMeaning<\/th>\n<\/tr>\n
WebLink<\/code><\/td>\nLink to Web resource.<\/td>\n<\/tr>\n
ApplicationLink<\/code><\/td>\nLink to app to view the item.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

For backward compatibility, we still have to support the old unfashionable API, but Uri<\/code> is just an alternate name for Web\u00adLink<\/code>. The Uri<\/code> data format is identical to the the Web\u00adLink<\/code> data format. The Set\u00adUri<\/code> method does exactly the same thing as the Set\u00adWeb\u00adLink<\/code> method. The Get\u00adUri\u00adAsync<\/code> method does exactly the same thing as the Get\u00adWeb\u00adLink\u00adAsync<\/code> method.<\/p>\n

For example, if an app uses Set\u00adUri<\/code> to set a URI, and you then call Get\u00adUri\u00adAsync<\/code>, it will produce that same URI. The Uri<\/code> and Web\u00adLink<\/code> are literally the same thing.<\/p>\n

Our final table therefore is<\/p>\n\n\n\n\n\n
Standard\u00adData\u00adFormats<\/tt> value<\/th>\nData\u00adPackage<\/tt> method<\/th>\nData\u00adPackage\u00adView<\/tt> method<\/th>\n<\/tr>\n
Uri<\/code>
\nWeb\u00adLink<\/code><\/td>\n		Set\u00adUri<\/code>
\nSet\u00adWeb\u00adLink<\/code><\/td>\n		Get\u00adUri\u00adAsync<\/code>
\nGet\u00adWeb\u00adLink\u00adAsync<\/code><\/td>\n<\/tr>\n
Application\u00adLink<\/code><\/td>\nSet\u00adApplication\u00adLink<\/code><\/td>\nGet\u00adApplication\u00adLink\u00adAsync<\/code><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

The fact that Uri<\/code> and Web\u00adLink<\/code> are identical means that your program doesn’t have to try to handle both. Just decide which name you want to use for the format (either Uri<\/code>, the OG name; or Web\u00adLink<\/code>, the hip new name), and use it.<\/p>\n

namespace winrt\r\n{\r\n    using namespace winrt::Windows::Foundation::Uri;\r\n    using namespace winrt::Windows::ApplicationModel::DataTransfer;\r\n}\r\n\r\nwinrt::Uri TryGetUri(winrt::DataPackageView const& view)\r\n{\r\n    if (view.Contains(StandardDataFormats::ApplicationLink())) {\r\n        return co_await dataPackageView.GetApplicationLinkAsync();\r\n    } else if (view.Contains(StandardDataFormats::WebLink())) {\r\n        return co_await dataPackageView.GetWebLinkAsync();\r\n    } else if (view.Contains(StandardDataFormats::Uri())) {\r\n        return co_await dataPackageView.GetUriAsync();\r\n    }\r\n    return nullptr;\r\n}\r\n<\/pre>\n
The above example decides that it wants to prefer the application link (which takes the user back to the app that provided the data package), and if that’s not available, then it sees if the data package contains a Web link (to view the content in a Web browser), and if even that’s not available, then it looks for a Uri (also to view the content in a Web browser).<\/p>\n
But the last test is redundant because Web\u00adLink<\/code> and Uri<\/code> are the same thing. If a Uri<\/code> is present, then Contains(WebLink)<\/code> will find it. The test for Uri<\/code> is dead code.<\/p>\n
It’s like taking attendance in a class, and there’s a student whose name is Joseph, but he also uses the nickname Joe. If you ask, “Is Joseph here?”, and there is no answer, then there’s no point asking, “Is Joe here?” because Joe and Joseph are the same person. There will never be a response to “Is Joe here?”<\/p>\n
So once we know that Joseph isn’t in the data package, there’s no point asking if Joe is in it.<\/p>\n
winrt::Uri TryGetUri(winrt::DataPackageView const& view)\r\n{\r\n    if (view.Contains(StandardDataFormats::ApplicationLink())) {\r\n        return co_await dataPackageView.GetApplicationLinkAsync();\r\n    } else if (view.Contains(StandardDataFormats::WebLink())) {\r\n        return co_await dataPackageView.GetWebLinkAsync();\r\n    \/\/ } else if (view.Contains(StandardDataFormats::Uri())) {<\/span><\/span>\r\n    \/\/     return co_await dataPackageView.GetUriAsync();     <\/span><\/span>\r\n    }\r\n    return nullptr;\r\n}\r\n<\/pre>\n","protected":false},"excerpt":{"rendered":"
Just improving on an ambiguous name.<\/p>\n","protected":false},"author":1069,"featured_media":111744,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[25],"class_list":["post-110085","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-code"],"acf":[],"blog_post_summary":"
Just improving on an ambiguous name.<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/110085","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/users\/1069"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/comments?post=110085"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/110085\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media\/111744"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media?parent=110085"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=110085"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=110085"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}