I've had the services below running for a few years to support Programming Windows Store Apps with HTML, CSS, and JavaScript. Hwoever, given that the books themselves are getting a bit out of date, I figured it's time to shut them down. Using the examples in the books, similar services would be easy enough for you to deploy to a host of your own. Let me know if you have questions.

http://programmingwin-js-ams.azure-mobile.net

http://programmingwin8-js-ch13-amspushnotifications.azure-mobile.net

http://programmingwin8-js-ch13-hellotiles.azurewebsites.net

 

 


My associate Brian Rasmussen released this book through Microsoft Press a few months ago: http://www.amazon.com/High-Performance-Windows-Store-Brian-Rasmussen/dp/0735682631/ref=sr_1_1?s=books&ie=UTF8&qid=1414429701&sr=1-1.

Here's the short review I wrote on Amazon:

Performance is something that's easy to talk about but difficult to do. You could say that every app could in some way perform better, but how do you really think about where to make investments? Too often, developers take an ad hoc approach, not really clear on what they're trying to accomplish. This can waste a lot of resources in areas that won't have real impact on the customer experience. In this book Brian brings years of real-world insight to the question of finding what matters, clearly defining your performance goals, and then going through the process to measure the app's present reality, making changes, and evaluating progress. And like another reviewer has said, performance information–even just what tools are available–is scattered around, and having one place to bring it all together is super-valuable. 

At 240 pages it's a concise treatment of the subject and for the price (Amazon has it at $14.13), it only takes one or two good improvements to your app to more than pay for itself!


From a background task, it's perfectly allowable to issue a tile update, for instance, when procedding a raw push notification in that task and updating a tile in response. With secondary tiles, you might also want to update the tile's arguments so that it launches into different content relevant to the tile update. However, secondary tile arguments are statically defined when the tile is pinned and cannot be changed later.

To work around this, you can use a set of static identifiers that you then dynamically map to your variable data. It's simplest to just keep a table of secondary tile IDs mapped to their dynamic arguments, in which case you're probably not using the static arguments at all.

Another question with background tasks is whether it's possible to do file I/O therein, because clearly if you're modifying a table of secondary tile arguments in a file you'll be doing file I/O. The thing to remember here is that if you use any kind of async APIs in the process, you need to make sure the background task stays active until the async work is complete. To do this, you use the deferral mechanism.

In C#, the general pattern is like this:

public async void Run(IBackgroundTaskInstance taskInstance)
{
    var deferral = taskInstance.GetDeferral();
    var contents = await DoAsyncWork();
    deferral.Complete();
}

In JavaScript, the deferral is found on the WebUIBackgroundTaskRuntimeClass object. You retrieve this in the worker with Windows.UI.WebUI.WebUIBackgroundTaskInstance.current, then call its getDeferral method, do your async work, and then call the deferral's completed method when you're done.

var task = Windows.UI.WebUI.WebUIBackgroundTaskInstance.current;
ver deferral = task.getDeferral();

DoWorkAsync().done(function () {
    deferral.completed();
    close();  //Shut down the background task
});

Note that JavaScript it's also necessary to call close() when the task is finished (which is WorkerGlobalScope.close()).

 


When creating apps for both Windows 8.1 and Windows Phone 8.1, you typically want roaming data–as managed through the WinRT APIs–to work seamlessly across both.

The first requirement here is that both apps are using the WinRT APIs for this purpose, meaning that the Phone app project is not using Silverlight but rather the "Windows XAML" or WinRT flavor. Clearly this isn't an issue for apps written in JavaScript, where that's the only option, nor for universal Windows apps that focus on WinRT.

Note that it's not necessary to implement the app with a universal app project in Visual Studio. Those project structures are simply a way to simplify development processes, and isn't a requirement for providing the same app experience on both Windows and Windows Phone.

The second requirement, however, is that both apps–however you build them–must have the same identify in their respective stores, which means specifically the package family name. This is what's used to manage the roaming settings, and so long as those match, then both implementations will work with the same roaming data. This is again a given with a universal app project, but something you have to do manually if implementing the apps with separate (non-universal) projects.

A little guidance on this can be found here: http://msdn.microsoft.com/en-us/library/windows/apps/xaml/dn630421.aspx

For some general Q&A on app data, which includes other aspects of roaming, see my post on the Building Apps for Windows blog: http://blogs.windows.com/buildingapps/2014/06/19/common-questions-and-answers-about-files-and-app-data-part-1-app-data/


I have a few bits related to the Windows Store and apps that I thought I'd share this week and next as a kind of Q&A. (And if you're curious why I like Q&A formats, it's because I collect a lot of answers from developer questions I see on different forums, and then consolidate related ones here.)

[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: Is there a way to persist unique data for an app after it's uninstalled? Put another way, how can an app save a piece of data (like an ID) so that it knows it was previously installed on a particular device?

A: Some background first. As you might already know, when a Windows Store/Phone app is uninstalled, all of its app data is also uninstalled. Roaming data lives on in the cloud for a time even if the app is uninstalled from all of the user's devices, but nothing remains on the device itself. So you can use roaming data for the purpose in the question, but after some time (like 30 days) the roaming data might disappear. Roaming data, in other words, is reliable only if you want to save user-specific data so long as the app is installed on at least one device.

Although you could consider saving something as user data–which would require asking the user to pick a location through the file picker–that would be clumsy and end up polluting user data areas with stuff that doesn't make sense to the user directly.

The only alternative, then, is to store that data in the cloud (a table within Azure Mobile Services comes to mind here) indexed by some kind of per-user app-specific identifier so it can be precisely retrieved later on. (This is, in fact, the scenario that prompted the question: the developer wanted some unique ID for a guest account to which to associate in-app purchases that did not go through the Store itself.) This leads to the next question.

 

Q: Where can I get a unique per-user per-app identifier that's unique across devices for the same user? And what about a device-specific identifier?

A: There are good answers to both of these questions. For the latter, a device-specific ID, also know as an App Specific Hardware ID (ASHWID), ca be obtained from the Windows.System.Profile.HardwareIdentification.GetPackageSpecificToken method (Windows 8 and Windows Phone 8.1; for Windows Phone 8, try HostInformation.PublisherHostId). For additional details on this API, refer to also Guidance on using the App Specific Hardware ID (ASHWID) to implement per-device app logic.

OK, that was easy–what about a per-user ID? For this one, use the App Receipt ID available through the Windows Store API, namely Windows.ApplicationModel.Store.CurrentApp.GetReceiptAsync. This returns you a piece of XML from which you'll need to parse the AppReceipt > Id property, a process that's straightforward with the XmlDocument class in WinRT:

Windows.ApplicationModel.Store.CurrentApp.getAppReceiptAsync().done(function (receipt) {
    var doc = new Windows.Data.Xml.Dom.XmlDocument();
    doc.loadXml(receipt);
    var appReceipt = doc.getElementsByTagName("AppReceipt");

    if (appReceipt != null && appReceipt[0] != null) {
        console.log("AppReceipt.Id = " + appReceipt[0].getAttribute("Id"));
    }
});

Again, the AppReceipt ID will be unique per user across all installations on all devices, which includes universal Windows apps in Windows and Windows Phone where those apps share the same package family name.  

Remember that the ASHWID is unique for a device, but not for multiple users of that device, so if you want a per-user and per-device ID, you'll need to combine the user-specific ID from the app receipt and the ASHWID.

 

Q; Speaking of uninstallation, are old versions of an app still available in the Store? That is, if I uninstall and app and then it gets updated in the meantime, can I install the version I previously had?

A: No, only the current version of an app is maintained in the Store. If you uninstall and reinstall, you'll get the latest version.



I've seen this question come up twice lately, once via email and again on StackOverflow. The questions are something like this:

My app has strange behavior with its template bindings with WinJS. When I navigate to a page and then back, everything is fine, but if I navigate to the same page then the bindings get all jumbled and I see only the raw JSON.

I have an app written in JavaScript whose app bar commands navigate to different pages, including the page that's currently loaded. Navigating between different pages works fine, but navigating to the same page (essentially reloading it) loses event handlers on my buttons.

In short, strange things seem to happen when navigating (with WinJS.Navigation.navigate) to the same page that's already loaded. Here's what's happening.

Page navigation in WinJS is just a matter of DOM replacement. When you navigate using the navigator.js file that's part of the Visual Studio templates, the target “page” contents are loaded into the DOM and then the previous “page’s” contents are unloaded. You can see this in navigator.js in the _navigating method. It creates a new element for the page being loaded, renders that fragment therein, and then unloads the old page.

The ready method for the new page, however, is called before the old page is unloaded (this was a change in WinJS 2.0, as WinJS 1.0 unloaded the old page before calling ready). The upshot of this is that when you navigate to the same page that’s already loaded, page.html(A) is in the DOM when you load page.html(B).

As a result, anything you attempt to do in the DOM during the processed or ready methods, which includes adding event listeners or attaching templates, will find the elements in page.html(A) and not page.html(B). That is, when getElementById traverses the DOM it finds elements in (A) first and stops there; locating templates works in the same way, so any data bindings that include templates will get hooked up to the templates in (A).

But then, of course, as soon as you return from the ready method, page.html(A) gets unloaded, so all your hard work is thrown away!

Again, this is a behavior that appears when navigating to the same page that's already loaded, so the solution is to avoid navigating to the same page because it's just fraught with peril. In some cases you can disable the navigation controls in your UI so you can't navigate to the current page. However, that's not always easy to do, so here's a way to wrap your call to WinJS.Navigation.navigate with a check for whether you're already on the target page:

function navigateIfDifferent(target) {
    var page = document.getElementById("contenthost").winControl.pageControl;
    var fullTarget = "ms-appx://" + Windows.ApplicationModel.Package.current.id.name + target;
    if (fullTarget !== page.uri) {
        WinJS.Navigation.navigate(target);
    }
}

This assumes that the PageControlNavigator control that you're using is in a div called "contenthost" in default.html (which is what the VS template gives you). What I'm then doing is building the full in-package URI for the target page and comparing that to the uri of the current page control, which is also a full in-package URI. You could also strip off the ms-appx:// part from the current page URI and compare to the target URI. Either way–you can then replace calls to WinJS.Navigation.navigate with navigateIfDifferent.

On the flip side, there are likely some scenarios where you specifically want to reload or refresh the current page, so a self-navigation seems like a way to do this. It should be fairly obvious, though, that any page initialization you do in ready or processed can be moved into separate methods that you call elsewhere to refresh the page. Remember too that you can call WinJS.Binding.processAll at any time in your code to refresh the data binding–it's not specific to page loading or other initialization procedures.

I'd recommend this as the first choice, because it won't mess with everything else that's been set up in the DOM already, and should perform better than reloading everything. 

However, if you still want to navigate to the same page to reload, then you need to defer the processing you'd normally do in ready to a later time. You could use a call to setImmediate for this purpose (it should work–I haven't tried it directly), but a simpler means (thanks to Guillaume Leborgne) is to make sure you scope any element queries or selections using the page's root element that's passed as the element argument to the ready method. Using this as the starting point, you'll restrict the scope to the newly-loaded page rather than the whole document.

And as a final note, you can always go to the lower-level WinJS.UI.fragments API to do your own page-loading implementation.


With the introduction of universal Windows apps at //build 2014, and the announcement of Windows Phone 8.1 that includes support for writing apps in HTML, CSS, and JavaScript, we do have some resources that are starting to emerge.

First, my newly-released second edition, http://aka.ms/BrockschmidtBook2, is very applicable to Phone apps. I didn't have time to spell out all the differences, but there is a summary of what to watch out for in Chapter 1, namely a few differences in controls and some parts of WinRT that aren't on the Phone.

Second, watch the Building Apps for Windows Blog for material in this area. For example, an upcoming post will spell out the controls story between Windows (WinJS 2.0) and Windows Phone (WinJS 2.1).

Third, Josh Williams and Ryan Salva did a demo session on building a universal app with HTML, CSS, and JavaScript at //build, which you can find on http://channel9.msdn.com/Events/Build/2014/2-540. What you'll see is that they do nearly all of the work in the Shared folder of the VS project, making only one small change at the end of the session to switch the Hub control in the Windows Store app to Pivot in the Phone app…the two controls, in fact, are identical in their API except for the top-level object names, so you just change the names and voila! You're in business.

Finally, there is a post on the Visual Studio blog on universal apps: http://blogs.msdn.com/b/visualstudio/archive/2014/04/08/building-windows-phone-8-1-apps-in-html.aspx.

More is certainly to come.


Programming Windows Store Apps with HTML, CSS, and JavaScript, Second Edition, is now released! You can find this free ebook (PDF, Mobi, and epub) it on http://blogs.msdn.com/b/microsoft_press/archive/2014/04/08/free-ebook-programming-windows-store-apps-with-html-css-and-javascript-second-edition.aspx. Companion content is on http://download.microsoft.com/download/6/6/5/665AF7A6-2184-45DC-B9DA-C89185B01937/Programming_Windows_8_Apps_HTML_CSS_JavaScript_2E_CompContent.zip and the videos are on http://microsoftpressbooks.azurewebsites.net/programming_windows_apps_with_html_2ed/.

I have to say that it's ironic that although the book covers Windows 8.1 and is mostly applicable to Windows Phone 8.1 as well, announcements at //build changed the landscape almost immediately. For one, WinJS is now open source and isn't specific to Windows Store Apps, and WinJS 2.1 for Windows Phone has some differences from WinJS 2.0 for Windows Store apps. Oh well. Guess it's onto the third edition now! Still, I suspect that this book, being free and the most comprehensive, will continue to be the primary WinJS reference, open source or not.