In case you haven't noticed, a recent update to Windows 8.1 makes a Privacy Policy link recently appear autmatically for Windows Store apps. This link takes the user to the app's page in the Store where the privacy policy link is available.

This means that apps no longer need to include their own privacy link; however, I don't yet know how to detect whether this is happening for an app so you can suppress your own link.If anyone has investigated this, please post in comments. That said, I personally like having a cleaner Privacy Statement link in an app that can open a settings pane directly with that content, rather than navigate to the Store.

It's worth noting that with this change, all you have to do to meet requirement 4.1.1 of the Store Certification Policy is submit a link to your policy when you submit the app. Because the app cert testers will be using the latest 8.1 build, you should pass cert without having a distinct command in your own settings. 

I wanted to let you all know that starting September 2nd, I'll be taking on a new role as Senior Content Developer for Azure and Visual Studio, as part of the Developer Answers team in Microsoft's Cloud & Enterprise Division. This means that content production will be even more of my focus than it has been in the past, when having a Program Manager title often meant getting involved in a variety of other activities!

Blogging will certainly continue, both on Windows and also on Azure and other topics as I expand into those areas. In the meantime, I've been blessed to have a little break between this and my former job, which has provided lots of time for home projects and spending time with family before my son's school starts up again.

Thanks to Michael Scherotter for the details explained in this post.

Say you have an x-ms-webview element on a page in your app:

ms-webview id="webview" class="Content" src="ms-appx-web:///contenthost.html">

and you want to print only the contents of the WebView. To do this, it seems at first that you need to get a DOM document object for the Webview to pass to MSApp.getHtmlPrintDocumentSource within a PrintTaskSourceRequested event. However, as noted in an earlier post, the Webview's DOM isn't accessible by the host app, for many good reasons, so it seems you're left with solutions like obtaining a bitmap of the Webview and printing that.

But there's another way that can work in a number of scenarios, especially when you know the content you're loading into the Webview and aren't wanting to print arbitrary pages. The trick is to load that content into a new document fragment and use that to obtain a source:

    //content is what you load in the Webview; printTask and printDeferral come from the WinRT print event

    var fragment = document.createDocumentFragment();
    var printSource;
    div = document.createElement("div");

    WinJS.Utilities.setOuterHTMLUnsafe(div, content);

    source = MSApp.getHtmlPrintDocumentSource(fragment);

You new methods like setOuterHTMLUnsafe had a use somewhere!

When you have a Webview hosting an iframe element, it's possible to monitor what's going on in the iframe using the MSWebViewFrame* events, which are documented with the x-ms-webview element. These are MSWebViewFrameNavigationStarting, MSWebViewFrameContentLoading, MSWebViewFrameDOMContentLoaded, and MSWebViewFrameNavigationComplete.

In the event you have multiple iframe elements in a webview, the way to distinguish between frames is with the e.uri property, where e is the event args object for the event in question. This property is presently undocumented, but should be–this comes directly from the engineers who built the webview, so we can trust that it's there!

Generally speaking, the content of a Webview is generally a black box from the host app's perspective, and for this reason you can't get into the Webview's DOM, you can't get element references (e.g. to an iframe), and so on. There'd be serious overhead to go that route.

Which brings us to the question of what happens when code within an iframe or Webview crashes. You've certainly seen some of those sites–the ones that cause the browser to pop up debugging messages about JavaScript exceptions and whatnot. Overall, crashes in a Webview or iframe should not crash the host app.

However, there is the possibility that long-running scripts within whatever web page you're hosting are taking so long that your app is considered to be unresponsive. Those are messages you've seen in the browser as well, and if the app gets blocked on the same kind of script, it's possible the Windows will take the app down. This is a known issue that might be addressed in future releases of the operating system. At present, you can consider watching the Webview/iframe NavigationStarting and setting up your own timeout so you can catch an unresponsive site before Windows takes down the app.

I've seen the question come up on occasion about using WinJS within a webview. This is entirely supported, and has been since the introduction of WinJS–the library always checks whether WinRT is present and adjusts itself accordingly. For example, if WinRT is available, then it will use WinRT app data for saving its settings; if WinRT isn't available, it uses standard HTML5 APIs instead.

This strategy wisely foresaw the day when WinJS was licensed for use in web page. This wasn't originally the case (as the copyright headers in the WinJS files made clear), but with WinJS going open source in April 2014, WInJS can be used anywhere.

When using WinJS, and especially WinJS controls, inside a webview or web page, it's important to remember steps that are included by default within the Windows app templates, most notable the step of calling WinJS.UI.processAll. That is, when you create a new Windows app, the templates in Visual Studio supply the following default activation code:

var app = WinJS.Application;
var activation = Windows.ApplicationModel.Activation;

app.onactivated = function (args) {
    if (args.detail.kind === activation.ActivationKind.launch) {
        if (args.detail.previousExecutionState !== activation.ApplicationExecutionState.terminated) {
            // TODO: This application has been newly launched. Initialize
            // your application here.
        } else {
            // TODO: This application has been reactivated from suspension.
            // Restore application state here.

Clearly, if you're using WinJS outside of an app, then the Windows.ApplicationModel.Activation namespace won't mean anything, so naturally you'll delete all the code inside the onactivated handler here. But if you delete WinJS.UI.processAll then none of your WinJS controls will show up. This can be confusing and might lead to the idea that WinJS doesn't work in a webview. But it does, because in the end WinJS is just a JavaScript library using standard HTML5/DOM to do its work. So just make sure that somewhere you have a line like this:



[For full details on working with the Windows Store, see Chapter 20 of my free ebook Programming Windows Store Apps with HTML, CSS, and JavaScript.]

For this final post, I wanted to provide the list of ms-windows-store URIs that you can launch for various purposes (using Windows.System.Launcher.LaunchUriAsync). These are in my book, but are good to have as a blog post:

  • ms-windows-store:PDP?PFN=<package_family_name> links directly to the app’s page; the package family name is what comes back from
  • ms-windows-store:REVIEW?PFN=<package_family_name> goes to the Ratings and Reviews section of the Store for your app, which is what the Rate And Review command in your Settings pane does. You can launch this URI from your app directly when inviting a review. Note, however, that there is not presently a means to determine whether the user left a rating or review.
  • ms-windows-store:Publisher?name=<publisher_display_name> Links to a page that shows all your apps, which you might do from an About pane in your Settings. The publisher name can be from
  • ms-windows-store:Updates opens the Store’s updates page (no arguments). You can use this when you detect that the user is running an older version
  • of your app, which suggest they’ve opted out of auto-updates.
  • ms-windows-store:Search?query=<search_string> executes a search in the Store.

[For full details on working with the Windows Store, see Chapter 20 of my free ebook Programming Windows Store Apps with HTML, CSS, and JavaScript.]


Q. I want to have my app load and show in-app purchase listings, but until the app is in the Store, such listing information won't be available. As a result, my app will look non-functional and could fail certification. What can I do about that?

A. The right approach is to remember that Windows.ApplicationModel.Store.CurrentApp.LoadListingInformationAsync is not ever guaranteed to work. Having no listing information in the Store is one case where it would fail, but so is lacking connectivity. Therefore you should always write your code to fail gracefully is no in-app purchase listings can be obtained. Arik Cohen of the Store team suggests these approaches:

  • Manage your list of in-app purchases in your own service (or have the list built into the app) and use the ListingInformation only for pricing.
  • Don't show the prices within your app
  • Show the purchases as presently unavailable and suggest the user checks back later.

Know too that the unavailability of ListingInformation doesn’t mean that you don’t have in-app purchase information; CurrentApp.LicenseInformation maintains a local cache of all durable in-app purchases that the user has made.

Gracefully handling the case when you're unable to retrieve in-app purchase listing information should avoid any problems in certification.


Q. Is there a way to add or edit in-app purchases to an app that is currently published without having to submit a new build of the app?

A. To change the listing information you always have to submit an update, but you don't have to upload a new app package or change the app's version number. And because you're not changing the package, certification should be quick.

To avoid having to resubmit, you'll need to manage your own in-app purchase catalog, which enables you to generate your list of available purchases dynamically. For more details, see Chapter 20 of (my free ebook) Programming Windows Store Apps with HTML, CSS, and JavaScript, in the section "Handling Large Catalogs" starting on page 1145.

[For full details on working with the Windows Store, see Chapter 20 of my free ebook Programming Windows Store Apps with HTML, CSS, and JavaScript. Note also that CurrentApp refers to Windows.ApplicationModel.Store.CurrentApp for convenience.]

Q. Why does CurrentApp.GetProductReceiptAsync return a not implemented exception for a Windows Store app?

A. This API is not implemented for Windows, just for Windows Phone. Windows Store apps should use the CurrentApp.GetAppReceiptAsync API and examine the in-app purchase receipts contained within it. (In short, this is one area of non-convergence with universal Windows apps at present.) 


Q. Can an trial version of an app provide in-app purchases?

A. No, by design the CurrentApp.RequestProductPurchaseAsync API does not work when the app is running under a trial license if the app is paid. The API can be invoked, but will fail. However, if the app is free, then in-app purchases will work (see the next question).

This is important to understand when testing an app with the CurrentAppSimulator: by default, the simulator assumes a trial version, so CurrentAppSimulator.LicenseInformation.isTrial will be true and in-app purchases won't work. To fix this, make sure your WindowsStoreProxy.xml file contains the following:


Q. I have a free trial app in the Windows Store with features that turn on when the full app is purchased. Can I change this to a free app (no trial) with in-app purchases?

A. Then question here is reall about handling the transition between licensing states, that is the information provided by CurrentApp.LicenseInformation. Prior to the app update, you'll have users with two possible states with the desired transition logic:

  • LicenseInformation.isTrial= true : convert to non-trial (full) version with no-in app purchases
  • LicenseInformation.isTrial = false : turn on licenses for in-app purchases that match the paid version.

When the update happens, it's important to note that the trial state of the all (isTrial) will continue to be true, but because the app is now free, in-app purchases will work properly. In this case, then, the app wouldn't bother to make any differentiations between trial and non-trial; that is, the updated app wouldn't ever check the isTrial flag at all.

The trick is then differentiating new installs of the app, which will have isTrial = false and isActive = true, from those who previously purchased the app and for whom these flags have the same values. You'll need another mechanism, then, other than the LicenseInformation itself, to differentiate the upgrades. 

This is straightforward to do. The best way is to CurrentApp.GetAppReceiptAsync to retrieve the app purchase receipt and check the receipt date against when you made the conversion. Any customers who purchases the app prior to that date were ones who paid for the license and should thus be granted all the rights that you otherwise now only grant through in-app purchases. Thus in your code to enable features, you would check that either (a) the appropriate in-app purchase license is set or (b) a previous purchase was made.


Q. I'm having trouble getting my licensing logic to work correctly; what's the best practice for checking license states?

A. The most reliable place to put your licensing logic is inside a handler for CurrentApp.LicenseInformation.LicenseChanged event. If you consolidate everything here, then you naturally handle any change made through purchase APIs, as well as trial expirations and other license-affecting events. You can check specific license flags after one of the async purchasing APIs completes, but as those should invoke LicenseChanged it's much cleaner to keep everything in the event handler.