MICROSOFT_PRESS_EBOOK_PROGRAMMING_WINDOWS_8_APPS_WITH_HTML_CSS_AND_JAVASCRIPT_PDF

our lives. And is that not how you want your customers to feel about your apps? Absolutely! Knowing
the delight that a well-architected app can bring to your customers, let’s dive in and find our own
delight in exploring the intricacies!
Local and Web Contexts within the App Host
As described in Chapter 1, “The Life Story of a Windows Store App,” apps written with HTML, CSS, and
JavaScript are not directly executable like their compiled counterparts written in C#, Visual Basic, or
C++. In our app packages, there are no EXEs, just .html, .css, and .js files (plus resources, of course) that
are, plain and simple, nothing but text. So something has to turn all this text that defines an app into
something that’s actually running in memory. That something is again the app host, wwahost.exe, which
creates what we call the hosted environment for Store apps.
Let’s review what we’ve already learned in Chapter 1 and Chapter 2, “Quickstart,” about the
characteristics of the hosted environment:
• The app host (and the apps in it) use brokered access to sensitive resources.
• Though the app host provides an environment very similar to that of Internet Explorer 10, there
are a number of changes to the DOM API, documented on HTML and DOM API changes list and
HTML, CSS, and JavaScript features and differences. A related topic is Windows Store apps using
JavaScript versus traditional web apps.
• HTML content in the app package can be loaded into the local or web context, depending on the
ms-appx:/// and ms-appx-web:/// scheme used to reference that content (the third / again
means “in the app package”). Remote content (referred to with http[s]://) always runs in the
web context.
• The local context has access to the WinRT API, among other things, whereas the web context is
allowed to load and execute remote script but cannot access WinRT.
• ActiveX control plug-ins are generally not allowed in either context.
• The HTML5 postMessage function can be used to communicate between an iframe and its
containing parent across contexts. This can be useful to execute remote script within the web
context and pass the results to the local context; script acquired in the web context should not
be itself passed to the local context and executed there. (Windows Store policy actually disallows
this, and apps submitted to the Store will be analyzed for such practices.)
• Further specifics can be found on Features and restrictions by context, including which parts of
WinJS don’t rely on WinRT and can thus be used in the web context. (WinJS, by the way, cannot
be used on web pages outside of an app.)
Now what we’re really after in this chapter is not so much these characteristics themselves but their
impact on the structure of an app. (To explore the characteristics themselves, refer to the Integrating
86