Notatki o Windows 8 - odc. 21

Koncepcje i architektura aplikacji Metro c.d: wydajność aplikacji JS, różnice między aplikacjami webowymi a aplikacjami Metro JS, funkcjonalności Windows w aplikacjach Metro - kontrakty, cykl życia aplikacji, pakiet, ustawienia i dane aplikacji (lokalne, roaming, tymczasowe).

Performance

Differences from websites

Metro style apps using JavaScript are long running

Metro style apps using JavaScript are large single-page documents

A Metro style app using JavaScript is one page that manages multiple flows.

• Since one page has to account for multiple views and perspectives, Metro style apps using JavaScript are expected to generate much more of their experience dynamically.
• The DOM may now contain many more elements to account for other pages or views. This means DOM operations could be more expensive.
• Rather than having scripts loaded on a per-page basis, there will now be the potential for a lot more script involved. Additionally, because of Windows Runtime and the nature of a Metro style apps using JavaScript, there will be more script than what a typical web page has.

Metro style apps using JavaScript are a mix of technologies

The more complex Metro style apps using JavaScript will encompass a wide breath of technologies, such as Cascading Style Sheets (CSS), HTML, Canvas, Scalable Vector Graphics (SVG), Windows Library for JavaScript and Windows Runtime APIs. Because of this, and the fact there are many ways to achieve the same scenarios, there is not a "one size fits all" solution to performance - instead, performance must be considered on a per-scenario basis.

UI performance optimization

When users interact with applications, they expect a certain level of responsiveness.

• Reduce the number of DOM elements. Use Cascading Style Sheets (CSS) for layout instead of DOM elements.
• Develop smart event handlers. Having a lot of event handlers registered for the same event can cause unnecessary code to run if only one of those items needs to be notified. Consider using a single event handler instead.
• Spawning threads with the Web Worker API. Traditionally, the web platform has been single-threaded, forcing all the script in your application to run together in a single UI thread. Although you can create the illusion of several things happening at once by using DOM events and the setTimeout API, it takes only one computationally intensive task to bring the user experience to a screeching halt. The Web Worker API provides a way for web application authors to spawn background scripts that run in parallel with the main page. You can spawn several threads at a time to use for long-running tasks.
• Using async APIs. If you have code running on the UI thread (usually code that is not running in a Web Worker), and you have the ability to use an asynchronous API over a synchronous version, it is recommended to use the asynchronous version despite the added complexity. For example, XMLHttpRequest is a common source of UI hangs due to developers commonly using the synchronous version. When using XMLHttpRequest, you should ensure to pass "true" for the async flag in the open method.
• Canvas animations. Canvas animations are often overdrawn, wasting CPU cycles and causing increased power consumption. Also, when animations are not aligned with the display’s refresh rate, choppiness can occur. An example of these problems can be seen when an animation uses a JavaScript timer resolution of 10ms to draw animations. This doesn't work because most monitors can only display at a 16.7ms resolution (60Hz frequency). The msRequestAnimationFrame method can solve the problems of using the setTimeout and setInterval methods because it enables applications to be notified when, and only when, the browser needs to update the page display. As a result, applications are perfectly aligned with the browser painting interval and uses only the appropriate amount of resources (var handle = setInterval(renderLoop, PERIOD); –> var handle = msRequestAnimationFrame(renderLoop);).
• Set timers appropriately. Set timers to an interval of the screen refresh rate and avoid a value of 0 for timers. When a timer is used, the app will round it automatically to the refresh rate of the display, even with setTimeout(0) and setInterval(0). Instead, use a value that makes sense, such as setTimeout(16) to avoid wasted cycles.
• Use fragment loading for navigation. To maintain an "app like" experience, Metro style apps using JavaScript do not conduct top level navigations. Instead, they load data as needed into the main page, a process called "fragment loading". This allows for applications to avoid incurring a large up-front cost on app initialization for loading, parsing, and creating the pages. Windows Library for JavaScript provides several functions that make it easier to use fragment loading.

Independent animation performance optimization

Independent animations provide developers a means to animate their UI separate from the app's UI thread. This enables you to create smooth, glitch-free animation experiences. Independent animation is an implicit feature in which the CSS Transitions Module Level 3 and/or animation of certain Cascading Style Sheets (CSS) properties are supported.

It's only possible to achieve independent animation when using CSS Transitions Module Level 3 and CSS Animations Module Level 3 to animate non-layout properties. This means that properties such as top, left, and bottom cannot be independently animated. Timer-based and jQuery animations are not supported either. 2-D and3-D (but not preserved 3-D) transform and opacity animation is supported. To achieve independent animation, these properties must be set via CSS or JavaScript.

When an element fails to meet the requirements for independent animation, it will fall back to the standard dependent animation. This means the animation will continue to behave as expected but will not take advantage of independent composition.

Supported animation technologies:

• CSS3 Transitions
• CSS3 Animations

Supported CSS properties (you can animate one or both):

• -ms-transform (for both 2-D and 3-D transforms, but not preserve 3-D)
• opacity

@-ms-keyframes myGraphic {

    from {

        -ms-transform:  rotateX(180deg);

        -ms-transform:  rotateZ(180deg);

        opacity:1;

    } to {

        -ms-transform:  rotateX(280deg);

        -ms-transform:  rotateZ(280deg);

        opacity:0.5;

    }

}

The following are unsupported scenarios. Meaning even if an element is using the correct CSS Transitions Module Level 3 transition or animation to animate a transform or opacity property, it will not independently animate if any of the following also apply to that same element.

1. The element's visibility is set to hidden.

/* This is how the visible class is set in the CSS file. */

h1.visible {visibility:hidden}

 

<!-- And this is how the visible class is used in the HTML document. –>

    <h1 class="visible">This is an invisible heading</h1>

2. The element is not in stacking context.

Stacking context is defined by the W3C in Appendix E. An element is in full stacking context if any one of the following conditions is true:

• The element's has a position with z-index value that is not equal to auto.
• The element's opacity is less than 1.
• The element has a 2-D or 3-D transform applied to it.

3. The element is a child of an element that has a "dependent" composition effect (f.e blur)

4. The element's outline-color set to invert.

When the outline-color is set to "invert", it is expected to perform a color inversion on the pixels on the screen.

5. The element is a Scalable Vector Graphics (SVG) element.

SVG is commonly used by web developers to define vector-based graphics for the web. SVG elements, such as shapes, filters, and so forth, do not independently animate. However, if an SVG element is embedded inside of HTML element, the element can independently animated.

<embed src="rect.svg"

       width="300"

       height="100"

       type="image/svg+xml"

        />

Not indepedently:

<rec width="300"

     height="100"

     style="fill:rgb(0,0,255); stroke-width:1; stroke:rgb(0,0,0)" />

6. The element has a negative z-index.

Optimize JavaScript code

1. Minimize Document Object Model (DOM) interaction

2. Avoid inline JavaScript. Inline JavaScript interrupts the parsing of the HTML, so that the JavaScript may execute first, in the event the JavaScript may be doing something to the HTML. Instead of inline code, keep all of your JavaScript in a separate JavaScript file, or towards the end of your HTML document. Generally, script changes less frequently, and so pulling it into a separate file allows it to be cached and reduces the size of your page.

3. Link JavaScript files at the end of the HTML document. Linking JavaScript files at the beginning of your HTML document forces the browser to download the file before it can continue parsing the HTML. Moving your scripts to the bottom of the page allows multiple parallel downloads to efficiently pull down the content of your page (images and so forth) instead of blocking on the script download. Also Metro style apps using JavaScript support the use of the defer tag for the same result:

<html>

<head>

    <title>Test</title>

    <script src="myscript.js" defer="defer" ...></script>

</head>

<body>

…

</body>

</html>

4. Factor JavaScript files. Referencing the same script twice, particularly if it can't be cached, can cause the app to request and wait for the download of the same script twice.

5. Batch DOM calls and visual changes.

6. Minimize symbol resolution. Create locally scoped symbols. When the JavaScript engine is executing code and encounters the need to resolve a symbol, such as a variable, it will begin by looking in the current scope. If it does not find the resolution, it will begin to look outwards, until it reaches the global scope. With each step outwards, there is a performance impact.

7. Avoid complex calculations.It's important to remember that JavaScript uses double precision floats, so when you perform any division, the value converts from an integer into a large float that’s never really 0 or 1. It's common to get into situations where you're changing values that are to small to have a visual impact but still cause the app to perform a lot of work, re-rasterizing Scalable Vector Graphics (SVG) that haven't visibly changed.

8. Use native methods over script equivalents. In particular, use the native JavaScript Object Notation (JSON) parsing methods over those provided by frameworks, or by calling eval. This can speed up these methods by as much as five or six times.

9. Use the selector API instead of iterating on the DOM. Rather than traversing the DOM, use the selector API to query for elements. For example, you could use document.querySelectorAll to locate elements.

Layout and design performance optimization

1. Eliminate inline styles. Placing Cascading Style Sheets (CSS) styles in your HTML markup forces the app to stop and parse the CSS before parsing the HTML which increases the file load time. Instead of using inline styles, keep all your CSS in an external style sheet. Generally script changes less frequently, and so placing it into a separate file allows caching to manage it separately and reduces the size of your page.

2. Factor style sheets to avoid sending unused styles. Your app has to evaluate all of the styles, even if they are not used.

3. Link your CSS early in your HTML. Link your CSS files in the document head so the app has style information sooner. Since the app must parse the HTML and apply the proper styles to each element, linking the CSS file in the head of the HTML document improves the speed at which your app can parse the HTML.

4. Use the link element instead of @import. Using @import is equivalent to placing a link tag at the end of the document.

5. Use class or ID selectors. Avoid using complex selectors, and instead use simple class or ID based selectors. Complex selectors can be slow because the app must traverse every element to determine if it has the selected properties.

table tr td ul li {color: green;}

=

li#myID {color: green;}

<li id="myID">

6. Use child selectors. Use child instead of descendent selectors. The app must traverse every descendent element to see if it has the selected properties. The child combinator, denoted by the greater-than symbol, ">", can be used to combine two elements and will only be applied if the second element comes directly after the first.

An example of a descendent selector:

p em {color: purple;}

This is a child selector using a child combinator:

p > em {color: purple;}

This style affects all em elements that occur as children of paragraphs, but not those that have another parent element in between.

7. Use a "data: URI". The data:URI scheme is a Uniform Resource Identifier (URI) scheme that provides a way to include data in-line in web pages as if they were external resources. Using a data URI directly in the CSS eliminates another fetch from the server as HTTP request and header traffic is not required for embedded data, so data URIs consume less bandwidth whenever the overhead of encoding the inline content as a data URI is smaller than the HTTP overhead.

li.checklist  {

    margin-left: 20px;

    background:url('data:image/png;base64,

iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAQMAAAAlPW0iAAAABlBMVEUAAAD/

//+l2Z/dAAAAM0lEQVR4nGP4/5/h/1+G/58ZDrAz3D/McH8yw83NDDeNGe4U

g9C9zwz3gVLMDA/A6P9/AFGGFyjOXZtQAAAAAElFTkSuQmCC')

    top left no-repeat;

    text-indent:1.5em;

}

 

<li class="checklist">Display a check box in a list.</li>

Graphics and imaging performance optimization

1. Draw only when visual changes happen. Many apps that contain canvas elements continue to clear and draw even when nothing has visually changed. To reduce unnecessary cycles, only draw when something has visually changed instead of using a while(true) approach. Additionally you should avoid playing videos or performing other CPU-intense operations if the result wouldn't be visible.

2. Draw only as often as physically possible. Many web-based animation patterns do more work than is actually needed. Mr. Potato Gun is a great example of this. It redraws the screen every 4ms even though the display is refreshing at 60hz. When you see this pattern you can usually shave 75 percent of the CPU time by only painting when the display is refreshed. The msRequestAnimationFrame method can solve the timing problems of the setTimeout and setInterval methods because it enables applications to be notified only when the browser needs to update the page display.

3. Avoid scaling images in HTML. Scaling the image requires the app to do the work to actually rescale the image once it has been loaded. Instead, scale the image before use when possible.

4. Avoid empty image src tags. Avoid empty image src tags because they require extra computing cycles by making a request to the directory in which the page is located. When an empty string is encountered as a URI, the app attempts to resolve it, potentially corrupting user data.

5. Optimize images. To reduce HTTP traffic, optimize your images. Portable Network Graphics (PNG), is often preferable to Graphics Interchange Format (GIF), and can be run through a PNG optimizer, such as pngcrush. For JPEG, use jpegtran to strip out unwanted information such as EXIF data.

6. Use Cascading Style Sheets (CSS) sprite sheets. Rather than using lots of small images, combine all your images into a single file and use the background-image and background-position CSS properties to clip the image to just the portions that you want to show. When combined with data URLs, sprite sheets can save numerous HTTP requests. You can optimize your sprite sheets by arranging sprites horizontally rather than vertically, which will lead to smaller file sizes. Keeping all colors in a sprite sheet to 256K or less can help them fit in the smaller PNG8 format.

7. Use SVG only where it makes sense. Scalable Vector Graphics (SVG) is useful only where it makes sense, such as for charts, graphics, or other graphics that need to scale. If you have no need for SVG, use a flat image instead. Keep in mind that each linked SVG element is essentially an independent SVG document with its own object model. When you drag an SVG image around, the script updates every pixel of the underlying model, causing the app to expend CPU cycles processing the changes.

Network performance optimization

1. Minimizing HTTP requests. Here are some ways to minimize HTTP requests:

• Use content from your Metro style app using JavaScript package whenever possible.
• Use HTML5 AppCache. Grabbing data off the network is one of the most time consuming actions in most applications. Reducing network requests will allow your application to start up more quickly, and use system resources on other tasks. Adding support for AppCache to your application will improve performance by reducing the amount of data that must be loaded off the network, as well as enabling your application to work off-line. Storing data locally which has already been processed or requested from the network will allow your app to not incur this cost again in the future.
• Use external files. Make JavaScript and Cascading Style Sheets (CSS) external when pulling from a server. Generally script changes less frequently, and so pulling it into a separate file allows caching to manage it separately and reduces the size of your more dynamic page that may use that JavaScript or CSS by eliminating the inline declarations of that relatively more static content.
• Use CSS URIs. Use inline images. Especially in CSS, you can use a data: URI directly in the CSS, thus eliminating another fetch from the server.
• Remove duplicate scripts. Referencing the same script twice, particularly if it is not cache able, can cause IE to request and wait for the download of the script twice.
• Use CSS sprite sheets. Rather than using lots of small images, combine all your images into a single file and use CSS properties background-image and background-position to clip out just the part of the image you want to show.
• Add an Expires or Cache-Control Header. For server-generated content, adding appropriate headers can help with performance. For static content, set an Expires header to far in the future so that it essentially never expires. For dynamic content, set a Cache-Control header.
• Avoid redirects. 30X HTTP response codes take time to make the round trip to the server only to make another request. A common error is to omit a trailing slash on a URL that requires one.
• Make AJAX cacheable. By making the responses to AJAX queries cache able, you can improve the speed of second-time access. You do this by adding an Expires or Content-Cache header.
• Use GET for Asynchronous JavaScript and XML (AJAX) Requests. POST runs slower, using two requests, so GET is preferred if you're just retrieving data.
• Eliminate 404s. Why try to download something that isn't there?
• Pack components into a multi-part doc thus avoiding multiple HTTP downloads.
• Avoid empty Image src tags. This will cause a request to a directory in which the page is located, since this would be treated as a relative URI to be composed with the base URI of the referencing page.

2. Minimizing the size of traffic over the network.

• Use GZip compression for server-delivered resources. All text-base files; HTML, CSS, JavaScript, XML, JavaScript Object Notation (JSON), and so forth, can receive a performance benefit, usually about 70 percent, by being compressed before being sent and is therefore faster to deliver. The client indicates its desire to receive files on the HTTP request by setting the Accept-Encoding header, for example "Accept-Encoding: gzip, deflate". The server responds with the selected encoding in the Content-Encoding header, for example, "Content-Encoding: gzip".
• Minify JavaScript and CSS. Minifying, or obfuscating, these files can save 20 to 25 percent of the size of the file, thus improving download times. Likewise, inline <script> and <style> blocks can and should also be minified.
• Reduce cookie size. Because cookies are sent with each request, they can slow down the time to transfer responses.
• Use cookie-free domains for components. By hosting components; scripts, images, and the like, that have no need for cookies on their own domain, for example static.microsoft.com, and removing the cookies from the headers of those domains, you eliminate unnecessary traffic when downloading those components.
• Reduce DNS lookups. Each DNS lookup can take 20-120ms, unless cached, so reducing the number of lookups required may help the overall speed of your application.
• Optimize images. Portable Network Graphics (PNG) is often preferable to Graphics Interchange Format (GIF). When using PNG, run them through a PNG optimizer, such as pngcrush. On JPEG, use jpegtran to strip out unwanted information such as EXIF data.
• Optimize CSS sprites. Arranging sprites horizontally rather than vertically can lead to smaller file sizes usually. Trying to keep all colors in a sprite sheet to 256 or less can help them fit in the smaller PNG8 format.
• Avoid scaling images in HTML. Downloading a large file that you then scale in the HTML is wasteful if you never need it at the larger size.
• Use conditional requests. By setting the If-Modified-Since header on a request, you will get back the small 304 HTML response code instead of the resource if the requested resource has not been modified. It will have the Last-Modified header on the response with the date of last modification.

Tools

While developing your application, you may be running the JavaScript engine in debugger mode. This means the engine will not just-in-time (JIT) your code, which results in running at a much slower speed. For JavaScript-intensive applications, this performance hit is noticeable. This is only applicable at development time, since release applications will not be running in debug mode.

Web programming for Metro style apps using JavaScript

Metro style apps using JavaScript provide many new features you can use to enhance your apps:

• Enhanced support for touch.
• New controls, such as DatePicker, TimePicker, and ListView, a data control that can be highly customized and can bind to different types of data, including XML and web services. These controls are included in the Windows Library for JavaScript (WinJS).
• Enhanced styling support. Metro style apps using JavaScript provide additional stylable components, called parts, to many existing HTML controls and all the new WinJS controls. These parts give you more control over the look and feel of your controls.
• Access to the Windows Runtime.

Differences

In general, HTML and DOM APIs function as they would inside Windows Internet Explorer 10 in standards mode. There are some differences, though. Some of these differences are the result of running inside the Windows shell, which controls what types of windows you can open. Other differences are the result of the Metro style app using JavaScript security model.

A Metro style app using JavaScript contains at least one HTML page. That page, and any other pages you include in the app itself, run in the app's local context. When you navigate to page in the app's navigation domain, that page runs in the web context.

Creating and manipulating windows

In the Windows shell, the active app occupies a single window that fills most of the screen. You can't create new windows, and you can't resize or move existing windows. So window methods such as alert, prompt, open, moveby, moveto, resizeby, and resizeto don't work in Metro style apps using JavaScript. A page running in the local context can use window.close to quit the app, but should only do so in the case of an unrecoverable error. Pages running in the web context can't use window.close.

Dynamically adding HTML

A page in your app's local context has more access to the system than other pages. It can access the Windows Runtime and, depending on the app's permissions, might be able to access the file system and your devices. For this reason, it's important to prevent potentially malicious code from executing.

To protect your system from potentially malicious code, HTML you inject into a page in the local context is filtered as through it was processed by the toStaticHTML method. Attempting to inject HTML that contains an unknown element, event handlers, script or references to script, or unknown CSS pseudo-elements and pseudo-classes causes an exception when you attempt to add the HTML to the page's DOM.

You can bypass this security restriction, but you should only do so with trusted content that does not contain any remote web content outside of your control. To bypass safe HTML filtering, you use one of the following functions:

• createElement
• msWWA.execUnsafeLocalFunction
• setInnerHTMLUnsafe, setOuterHTMLUnsafe

Because they have limited access to the system, pages in the web context are not subject to these restrictions: properties and functions such as innerHTML and pasteHTML do not check for potentially malicious code.

Metro style apps using JavaScript do not support custom ActiveX controls.

All pages accessed by a Metro style app using JavaScript must be encoded as UTF-8 or a subset of UTF-8, such as ANSI.

Features and restrictions by context

• WinRT: local - yes, web - no
• WinJS: local - yes, web - yes
• JavaScript URIs: local - no (yes: attribute="myFunction()", no: attribute="javascript: 2 + 2;"), web - yes
• Custom ActiveX controls: local - no, web - no
• External script references: local - no, web - yes
• Window manipulation methods (alert, prompt, open, moveby, moveto, resizeby, and resizeto): local - no, web - no
• window.close: local - yes, web - no
• Cross-domain XHR requests: local - yes, web - no

toStaticHTML

HTML you inject into a page in your app's local context is filtered as through it was processed by the toStaticHTML method.

Windows features for Metro apps

Contracts

These are the application contracts that Windows supports:

• Search
• Sharing
• Play To
• Settings
• App to App Picking

Application lifecycle

Application launch

An app is launched whenever it is activated by the user but the process is not running, either because it was just deployed or because it was suspended but could not be kept in memory. Users will rarely close apps.

Application activation

Apps can be activated as follows:

1. camera - the app is used to capture photos or video from an attached camera.
2. contact picker - the app is used to pick contacts.
3. device - the app is used to handle AutoPlay.
4. file - the app is the program associated with a file.
5. file picker - the app is used to pick files or folders.
6. launch - the app is launched.
7. print task - the app is used to handle print tasks.
8. protocol - the app is the program associated with a protocol.
9. search - the app is used to search.
10. sendtarget - the app is a target for a send operation.
11. sharetarget - the app is a target for a share operation.

Application suspend

An app can be suspended when the user moves it to the background or when the system enters a low power state. Most apps should stop running when the user switches away from them. However, there are some apps that should continue to run in the background, such as music players.

When the user moves an app to the background, the system will wait a few seconds to see whether the user intends to immediately switch back to the app. If the user does not switch back, the system suspends the app.

You can use the event handler to save relevant application data to disk. It is recommended that you use the application data APIs for this purpose because they are guaranteed to complete before the app is suspended.

Generally, your app should save its state immediately in the event handler when the suspending event is received, and take less than a second to save its data. If an app does not return from the suspending event within 5 seconds, the system assumes that the app has stopped responding and terminates it.

The system attempts to keep as many suspended apps in memory as possible. By keeping these apps in memory, the system ensures that users can quickly and reliably switch between suspended apps. However, if there are insufficient resources to keep an app in memory, the app is terminated. Note that apps do not receive notification that they are being terminated, so the only opportunity for you to save your app's application data is during suspension.

Application resume

A suspended app can be resumed when the user moves it to the foreground or when the system comes out of a low power state. No application data will have been lost, as it was stored in memory. However, the app could have been suspended for hours. Therefore, if your app has content or network connections that may have gone stale, these should be refreshed upon resume.

Application updates

You can use Windows Update to provide automatic updates for your app to your customers.

Application removal

When a user deletes your app, the app is removed, along with all its application data.

App packages and deployment

A package can contain one or more Metro style apps. Each app in the package must have its own tile. It can also have images, media files, web pages, and dynamic-link libraries. After a package is installed on a disk, it is represented as a directory.

The package manifest is digitally signed as part of signing the package; you don't need to sign the manifest separately. After the package is signed, any changes to the manifest or the content of the packages invalidate the package signature.

A package manifest consists of the following sections:

• Package Identity
• Package properties
• Apps
• Prerequisites
• Dependencies
• UI resources
• Capabilities
• Extensibility points

Package Identity

Each package is defined by a globally unique identifier known as a Package Identity. The Package Identity consists of 5 tuples:

• name
• version
• publisher  - the publisher specified in the certificate used to sign the package.
• processor architecture - the architecture of the package (optional).
• resource ID - the UI resources in the package (optional).

<Identity Name="MyCompany.MySuite.MyApp" Version="1.0.0.0" Publisher="CN=MyCompany, O=MyCompany, L=Seattle, S=Washington, C=US"

Package properties

Each package is described through its package properties.

<Properties>

  <DisplayName>MyApp</DisplayName>

  <PublisherDisplayName>MyCompany</PublisherDisplayName>

  <Logo>images\icon.png</Logo>

</Properties>

Apps

Each package consists of one or more apps. Use the package manifest to declare general properties of each app.

<Applications>

  <Application Id="MyCompany.MySuite.MyApp" StartPage="default.html">

    <VisualElements DisplayName="My App" Description="A useful description."

         Logo="images\icon.png" SmallLogo="images\icon.png"

         ForegroundText="dark" BackgroundColor="#000000" ToastCapable="true">

      <DefaultTile ShortName="MyApp" ShowName="true" WideLogo="images\icon.png" />

      <SplashScreen BackgroundColor="white" Image="images\splash.png" />

    </VisualElements>

  </Application>

</Applications>

Prerequisites

An app often requires that some level of functionality be present in Windows. Therefore, you must use the package manifest to declare the version of Windows that its apps require.

<Prerequisites>

  <OSMinVersion>6.2</OSMinVersion>

  <OSMaxVersionTested>6.2</OSMaxVersionTested>

</Prerequisites>

Dependencies

An app can require the use a framework. Frameworks are also deployed as packages. To indicate that your app requires a framework be installed, use the package manifest to declare the package dependencies.

<Dependencies>

  <Dependency Name="Company.Framework" MinVersion="1.0.0.0" />

</Dependencies>

UI resources

An app must declare at least one language resource.

<Resources>

  <Resource Language="en-us" />

</Resources>

Capabilities

An app can require access to protected system resources or user data. If you determine that your app requires certain capabilities, use the package manifest to declare the required capabilities.

<Capabilities>

  <Capability Name="internetClient"/>

  <Capability Name="musicLibrary"/>

  <Capability Name="videosLibrary"/>

</Capabilities>

Extensibility points

An app can interact with the system or other apps through extensibility points. Use the package manifest to declare extensibility points. For example, an app can declare that it handles files with certain extensions, or that it uses a dynamic-link library.

Application packaging

• Visual Studio 11 Express for Windows Developer Preview
• MakeAppx.exe
• packaging API

Application install

There's no need for elevation to install the app, and there are no custom actions during the install. All required information is contained in the package. The user won't be prompted for additional information.

Apps are installed under the %ProgramFiles%\Applications directory.

Application data

Application settings and files can exist in the following data stores:

• local - persistent data that exists only on the current device.
• roaming - data that exists on all devices on which the user has installed the app.
• temporary - data that could be removed by the system at any time.

You can optionally version the application data for your app. This would enable you to create a future version of your app that changes the application data format without causing compatibility problems with the previous version of your app. The app checks the version of the data in the data store, and if it is less then the version the app expects, the app should update the application data to the new format and update the version. For more information, see the Application.Version property and the ApplicationData.SetVersion method.

Settings in the app data store are stored in the registry. When you use the application data API, registry access is transparent. Within its app data store, each app has a root container for settings. Your app can add settings and new containers to the root container. Create new containers to help you organize your settings. Note that containers can be nested up to 32 levels deep, with no restriction on the breadth of the tree.

Use composite settings to easily handle atomic updates of interdependent settings. The system ensures the integrity of composite settings during concurrent access and roaming. Composite settings are optimized for small amounts of data, and performance can be poor if you use them for large data sets.

Application settings can be local or roaming. The settings that your app adds to the local data store are present only on the local device. The system automatically synchronizes settings your app adds to the roaming data store on all devices on which the user has installed the app.

The following Windows Runtime data types are supported for application settings: Boolean, Double, Int32, Int64, Single, String, UInt8, UInt32, UInt64. Note that there is no binary type. If you need to store binary data, use an application file.

Application files

Files in the app data store are stored in the file system. Apps can use files in the app data store just as they use files in the AppData part of the user's profile in Windows 7. Note that directories in the app data store can be nested up to 32 levels deep, with no restriction on the breadth of the tree.

Local application data

Use the local app data store for information that it does not make sense to roam and for large data sets.

Roaming application data

If a user installs your app on multiple devices, Windows keeps the application data in sync, reducing the amount of setup work that the user needs to do for your app on their second device. Roaming also enables your users to continue a task, such as composing a list, right where they left off even on a different device.

Windows limits the size of the application data that each app may roam. If the app hits this limit, none of the app's application data will be replicated to the cloud until the app's total roamed application data is less than the limit again. For this reason, it is a best practice to use roaming data only for user preferences, links, and small data files.

Typically, an app does not expect its data to change. However, roaming app data can change at any time. An app should register to handle the datachanged event, which occurs whenever roaming app data changes.

If the application data on a device is updated to a new version because the user installed a newer version of the app, its application data is copied to the cloud. The system does not update application data to other devices on which the user has the app installed until the app is updated on those devices as well.

c.d.n