On a recent drive to San Francisco (three hours from my home in Nevada City, CA), I listened to a number of talks from //Build 2013 that I'd downloaded to my Surface. (I've found that just listening to the presentations provides 80% of the content, and I can make notes of sections where I want to go back and watch the video for real.)

Three these are very interesting for their perspectives on JavaScript as a language, so I wanted to highlight those in particular:



An introduction and best practices for monetizing your Windows 8 app with advertising from //Build 2012 (2-113, 56m, 10s). And if you haven't discovered this trick yet, if you download the video and play back in Windows Media Player, you can set the playback speed to 1.6x or higher to watch the video in less time. I do that frequently, as I can often consume such content at a faster pace than when it was originally presented, and slow it down to normal speed when there's a part that's specifically interesting.


In addition to section 1.1 of the Store Certification Requirements, which is general enough to allow rejection of any app that just attempt to wrap a website, section 3.9 come into the picture when you have a legitimate app that wants to use web content in some way:

3.9 All app logic must originate from, and reside in, your app package

Your app must not attempt to change or extend the packaged content through any form of dynamic inclusion of code or data that changes how the application interacts with the Windows Runtime, or behaves with regard to Store policy. It is not permissible, for example, to download a remote script and subsequently execute that script in the local context of your app package.

The wording of this policy certainly allows for hosting web content within an <iframe> element (HTML/JS) apps or a WebView control (XAML apps). A number of reader apps (as for blogs) do this routinely, where the app is processing an RSS feed to provide a nice view of the overall content, then displays specific posts within an iframe/webview. That hosted content can run script within its iframe/webview sandbox.

In such cases, the app typically provides for different view states, handles touch input, provides app bars and appropriate navigation controls, and might implement other OS integration points that clearly add value. That is, while the app is clearly hosting web content, it's not relying entirely on that hosted content for the user experience.

Now an app might have pages that are entirely created with hosted content, where that web site is set up to provide a user experience that is indishtinguishable from a native app. The tricky part here is supporting functions like snapped view, which would have to be done with responsive CSS design and so forth. The app would also need to pass messages (via postMessage in HTML or InvokeScript in XAML) to implement things like app bar commands.

So would such a thing violate section 3.9 above? It's something of a gray area. The key factors are (a) whether the hosted content attempts to modify the in-package contents through injection of HTML/JS, and (b) whether you're attempting to pass script or other data that would cause the main app, which has access to the WinRT API, to behave in a way that either breaks Store policy or changes the behavior of the app from what it says it does.

What's really at stake here is user safety and confidence. First, dynamic injection of script and other content within the app can pose security risks that the user may not be aware of. Second, such a dynamic nature can deviate well away from what the app says it does in the Store, hence eroding user confidence because it makes it possible for an app to say one thing in the Store and do completely different things at runtime.

This is really to say that all content that interacts with the WinRT API must be included in the app package, so bringing down any kind of script or code and executing that within the app (e.g. in the local context of an HTML/JS app) is not allowed. Bringing down HTML/CSS/JS (or XAML for that matter) and rendering that in a sandboxed viewport of some kind (which includes implementing your own renderer) is allowable.


Apropos to today's other post on testing network connectivity is this session from //Build 2012: Tips and tricks for developing connected apps (58m, 09s). Here's the description:

Most Windows Store apps will be connected, using the network for some purpose.  This talk addresses questions about connected apps that we’ve heard from you so far, and covers a set of tips and tricks that will help you provide a predictable and enjoyable experience for your users.   This includes such topics as power-efficiency, securing connections, connecting streams, and discovering other nearby application instances.


At home I've been enjoying the ability to easily send pictures and videos from a Windows 8 device, such as my Surface, to a DLNA-compatible receiver elsewhere in the house, such as our Western Digital LiveTV Hub that's attached to our TV. No more pulling out the 15-foot HDMI cable!

The feature that makes this work is known as Play To. I covered this in Chapter 10 ("Media") of my book, and you can find a short introductory video here: http://channel9.msdn.com/Series/Introducing-Windows-8/Play-To.