Notatki o Windows 8 - odc.6

Tym razem głównie o kontrolce Flyout, menu kontekstowym oraz notyfikacjach (push i lokalnych).

Flyout

Flyouts are lightweight popups that relate to what the user is currently doing. For example, you can use a flyout to show a drop-down menu from an app bar, to show more details about an item, or to ask the user to confirm an action. You should only show a flyout in response to the user, and the user is always in control of dismissing it.

When the user presses the Buy button, a flyout shows below the button:

<button id="buyButton" aria-haspopup="true">Buy</button>

<div id="confirmOrderFlyout" data-win-control="WinJS.UI.Flyout" aria-label="{Confirm Order Flyout}">

   <div>Your account will be charged $252.</div>

   <button id="confirmOrderButton">Complete Order</button>

</div>

var anchor = document.getElementById("buyButton");

var flyoutElement = document.getElementById("confirmOrderFlyout");

var flyout = WinJS.UI.getControl(flyoutElement);

flyout.show(anchor, "bottom");

When the user presses the Respond button, a menu will show above the button:

<button id="respondButton" aria-haspopup="true">Respond</button>

<div id="respondFlyout" data-win-control="WinJS.UI.Flyout" aria-label="Respond Menu" class="win-menu">

   <button id="replyMenuItem" role="menuitem">Reply</button>

   <button id="replyAllMenuItem" role="menuitem">Reply All</button>

   <button id="forwardMenuItem" role="menuitem">Forward</button>

</div>

var anchor = document.getElementById("respondButton");

var flyoutElement = document.getElementById("respondFlyout");

var flyout = WinJS.UI.getControl(flyoutElement);

flyout.show(anchor);

• A flyout is a lightweight popup that is used to temporarily show UI.
• Use flyouts to collect information from the user, or for warnings or other messages related to user actions.
• Do not use flyouts for unexpected messages, or to present complex or persistent selections of commands that would be more convenient to the user on the app's canvas or app bar.
• Make the design of the flyout as simple as possible.

Collecting information

• If the user has selected an action that requires more input, such as choosing an option or typing information, then that UI can be placed in a flyout to keep the user in their original context. For example, let's say that in a map app, users can label the locations they tag. Users tap the location to tag it, and the app presents a flyout so users can enter their label.
• Title: None
• Include just the controls you need. Keep any instructions or "Learn More" links to a minimum. If the user is changing a setting or toggling an on/off switch, for example, then the change should commit as soon as it is made. Interacting with custom content should not dismiss the flyout; the user should be in control of dismissing it manually.

• If a button is just meant to commit the user’s changes, then it isn’t required and those changes should be committed automatically. If the button begins some action (such as Login, or Save Document), or the user has entered text that they wish to commit, then a button is appropriate and the flyout should dismiss when the user presses the button.

Warnings/confirmations

• You can warn users before they take a potentially destructive action. For example, in a photo app, when users tap a Delete icon, the app presents a flyout warning them that the photos will be permanently deleted, and providing the delete command. Users can either continue or dismiss the flyout. The only warnings or errors that should go in a flyout are those that are a direct result of user action.
• Title: None
• State the warning that the user should consider before taking the action. Do not phrase it as a question.

• Include just the action that the user initiated, such as Delete. Do not include the opposite action or a Cancel button; that can be achieved by dismissing the flyout.

Drop-down menus and non-text UI elements

• If a button in an app bar has more than one option, then display a flyout to let the user pick the command to execute. Use context menus for contextual actions when selecting text; use flyouts to create drop-down menus from UI elements such as buttons. In a mail app, when users select a Respond from the app bar, the app can present a flyout as drop-down menu letting the user choose between the ways to respond: Reply, Reply All, and Forward.
• Title: None
• The user makes a direct selection from the list.

More info

• Show more details about an item onscreen that the user is interested in.
• Optional title to relate status or a description of an icon that was used to invoke it.

• Include the information

• Optional buttons to do more with the information in the flyout.

Avoid flyouts in the following types of scenarios:

• Do not use flyouts to draw users' attention from their desired goals. For example, don't use flyouts for notifications that updates are available, a trial has expired, or an internet connection is not available.
• Don't use flyouts if the situation requires prolonged interaction, multiple screens, or lots of UI. Integrate the UI into the canvas of the app instead. For example, you should not use flyouts for wizards or chained set up screens.
• Avoid using flyouts to present the primary commands for your app. Use the app bar for that.
• If a menu is required purely for commands on a text selection, then use the context menu instead.

The flyout should be as small as possible given its content. It doesn't need extra padding beyond what is provided by the flyout itself. If a control isn't absolutely necessary, then don't include one. For example, if there are no actions for the user to take, then don't include any buttons. There is no need for Close or OK buttons; relying on Light Dismiss will do just fine. Similarly, if a title isn’t absolutely necessary, then don’t include a title.

If the user tapped on a toolbar button to bring up a flyout, then the flyout should show above or below the toolbar button. If showing the flyout above or below the control would obscure important content, then it can be placed to the left or right of it. The flyout is positioned by specifying the object to anchor it to and the side of the object it should appear on. Flyouts should never be positioned in non-contextual places like the center of the screen for a few reasons:

• When UI is shown in a position disconnected from the action that invoked it, the user needs to go searching for this UI and is slowed down.
• The user may not notice that the flyout has appeared and may accidentally dismiss it by continuing to tap, making your app feel unresponsive.
• Users expect that centered (or other arbitrarily positioned windows) contain a close or cancel button and would use them even if a light dismiss option was present, undermining your goal of lightweight UI.

Context menu

The system provides apps with default context menus for text and hyperlinks. For text, the default context menu shows the clipboard commands (cut, copy, and paste). For hyperlinks, the default menu shows a command to copy the link and a command to open the link.

You can replace the default context menus with menus that show custom commands for text or hyperlinks, or you can create your own context menus that act on other UI objects (like thumbnails). However, the number of commands you show in a context menu should be minimal. Only use context menus to show commands that are directly relevant to users and that cannot be readily accessed through the app toolbar or direct manipulation (like touch rotation). Context menus can show a maximum of five commands.

Use context menus to

• Use a context menu to show clipboard commands (e.g. cut, copy, and paste) for objects (such as selected text). By default the system shows commands for selected text; these are cut, copy and paste and common paste menu commands are select all, paste and undo.
• The system comes with default context menus for text and hyperlinks. Apps can replace these context menus with their own context menus. A custom command is appropriate to include in acontext menu when it is not found in the app's toolbar and cannot be performed using direct interaction (like rotation).
• Use the context menu to show commands for an object that needs to be acted upon but that cannot be selected or otherwise indicated. For example: A chat list may not be appropriate to add selection to; in this case a context menu can make commanding on each chat possible.

Dos and don’ts

• The context menu has a maximum width that equates to approximately 50 characters. Where, possible avoid truncation of your commands in the context menu by keeping command names short. When command names are too long an ellipse (…) is appended to the name automatically.
• Use separators in the context menus to group sets of commands together. Use a separator to divide app-or view-specific commands from a predictable set of commands, such as clipboard commands, that are shown together.
• The context menu should be positioned relative to the object or selection that it is acting on. When showing the context menu, provide a rectangle for that object that it will be acting on and the context menu will position itself relative to it. By default context menu should be positioned above the object that they are acting on; to do this pass the rectangle for the object that you are acting on using getBoundingClientRect().
• Do show and hide commands when they are contextually relevant to the selection or object. Note that the context menu does not have a disabled state; the context menu doesn’t show if there are no commands in it. For example, the default context menu only shows the "Paste" command over editable text when there is something on the clipboard.
• Do order custom commands in the context menu by importance, with the most important commands at the bottom
• Do order clipboard commands in the standard Cut, Copy, Paste order and place them at the bottom of the menu. If you want to show only two clipboard commands (e.g. Cut and Paste) simply omit the unused command and otherwise preserve the order.
• The first character of the command should be upper-case and all of the remaining characters should be lower-case.
• Do stick within the 5-command limit.
• Do dismiss the context menu. Programmatically dismiss the context menu when the context it was shown for does not exist anymore. This can be done by using cancel in the standard async pattern.
• Don't use the context menu when direct manipulation or selection is possible. Users should be able to command apps primarily through direct manipulation or selection and the app bar. When possible, use an app bar UI elements.
• Don't use the context menu to duplicate commands available elsewhere.
• Don't show a context menu for the background of a page or for a large object. Instead, when you have commands that act on the background of a page or on a object that takes up the whole screen, use the app bar or commands on the canvas to act on the page or object.
• Context menus do not have item accelerators do not add ampersands (&) in your menu.

Splash screen

A splash screen is required for all Metro style apps.

You can customize your application's loading display by specifying the splash screen image and background color, and by using the Splash Screen API to display your splash screen for longer, and/or to notify your app when your splash screen is dismissed.

Extending the length of time that your splash screen is displayed enables your application to complete additional startup tasks and display additional loading information. For example, your app might need to load resources from the network. You would extend your splash screen by retrieving the coordinates of the splash image in order to construct your own splash screen (which is the first view in your app) that mimics the default splash screen, but can also provide the user with additional loading information. If you have entrance animations, detecting when the splash screen is dismissed lets you know when to begin your app's entrance animations.

If you're using a Visual Studio template to create your app, "images\splashscreen.png" was automatically added to your project and set as the splash screen for your app in the "package.appxmanifest" manifest file.

“package.appxmanifest” –> Application UI –> Splash Screen

While a splash screen image is required, specifying a background color for your image is optional. Set a background color to use with your splash screen image by going to the Splash Screen section of the Application UI tab (as above) and enter the hex value of the color in the Background Color field. If you do not specify a background color, the background color will default to the color you set in Background Color field of the Tile section of the Application UI tab.

Use a transparent PNG image for best visual results.

If your app needs extra time to load resources, consider creating identical splash screens and first views.

Tiles, toast & push notifications

Tile notifications, toast notifications, and badge updates can all originate either from a local API call or from the cloud.

Tiles are available in two sizes. Which of the two sizes is displayed is entirely controlled by the user.

• Square: This tile size can contain application branding—either an application icon or name—as well as potential notification badges. Because a square tile contains only basic information, only one template is available to create them.
• Wide: This tile size can contain any of the content of a square tile plus richer, more detailed, and more visually compelling content as well. A broad choice of layout templates is available at this size to allow the additional content. Any app that uses a wide tile must also provide a corresponding square tile because the user can choose to shrink the tile at any time as they personalize their Start screen.

The content of a tile is defined in XML, based on a set of templates provided by Windows. To define a tile's contents, the developer simply retrieves one of the templates and provides their own text and images.

A tile can contain text and images, depending on the template selected, and can also display a badge and either a logo or short name. The badge is displayed in the lower right corner and the logo or short name in the lower left. The choice of whether to show the logo or the short name is declared in the app manifest.

Cycling. Up to five update notifications can cycle repeatedly through the tile if the developer declares the tile to have the cycling capability. Notifications can be given a tag to use as a replacement ID. Windows examines the tag on a new notification and replaces any saved notification with the same tag. Notifications cycle until they expire, are pushed out of the queue by newer updates, or are replaced in the queue with an updated version of themselves.

Default tiles. When your app is first installed, it is represented by a default tile. This is a simple, static tile defined in your app manifest; generally just a representation of your logo or brand. This tile is replaced only when you send your first tile notification. It's a significant concept to grasp that the only time you technically "create" a tile is when you define it in your app manifest. All further changes are tile notifications. Default tiles are rendered on top of the app color, so if there is any transparency in the default tile image, the app background shows through.

Secondary tiles. Secondary tiles provide the ability to create tiles pinned to the Start screen that launch directly to a specific location or subexperience in a parent app. The app decides which content to offer as a pin option, but the user has the final say in whether the secondary tile will be created or deleted. This tile is independent of the main app tile and can receive tile notifications independently.

Toast notifications. Toasts are an optional part of the app experience and are intended to be used only when your app is not the active foreground app. A toast notification can contain text and images but secondary actions such as buttons are not supported. Think of toast as similar to a Windows balloon notification arising from the taskbar's notification area. Like those notifications, a toast appears in the lower-right corner of the screen. When a user taps or clicks on the toast, the associated app is launched in a view related to the notification. It is the only mechanism by which one app can interrupt a user in another app. Toasts can be activated, dismissed, or ignored by the user. The user can also choose to disable all toasts for an app. A toast notification should only be used for information considered of high interest to the user, typically involving some form of user opt-in, therefore it is a good choice for incoming e-mail alerts, IM chat requests, and breaking news.

There are two types of toast notification:

• Standard toast: Most developers will use the standard toast. This toast remains on the screen for 7 seconds, playing a brief sound to alert the user when it appears. This toast is best for notifications such as a new e-mail, an IM contact sign-in, or a new social media update.
• Long-duration toast: This toast looks the same as a standard toast but stays on the screen for 30 seconds and can play longer, looping audio. This is used in situations where developers want to grab the user's attention because there is a human waiting on the other end of the connection. This type of toast is appropriate for person-to-person communication like instant messages and VOIP calls.

Scheduled and recurring toast

A toast notification can also be scheduled to appear at a specific time. Use this feature for alarms, calendar reminders and notifications that depend on precise timing. These notifications do not depend on the app's state or the computer's network connection.

A scheduled toast notification can also display multiple times within a short period to increase the user's chance of seeing it. For instance, you might want to show important meeting reminders three times, five minutes apart.

Scheduled toast notifications specify the date and time when Windows should raise that toast notification. In the case of a recurring scheduled toast it is the first time that the OS will display the notification.

Badges

A tile can display a notification badge which conveys summary or status information concerning and specific to the app. Badges can be displayed on either the square or wide tile. They can be numeric (0-99) or one of a set of Windows-provided glyphs.

The system provides a set of glyphs for use with a badge. These glyph values are available: none, activity, alert, available,  away, busy, newMessage, paused, playing,  unavailable, error.

Push notifications

Push notifications allow third-party app servers to send toast notifications, tile notifications, and badge updates to the client, even if the target app is not running. This is done by posting a message on a channel Uniform Resource Identifier (URI) specific to an app. Think of a channel URI as a way to address a specific tile (or app in the case of toast) for a specific user on a specific machine.

Sending push notifications involves authenticating your app server with the Windows Push Notification Services (WNS) using credentials provided to you when you register your app with the Windows Live Application Management site. Once authenticated, your server receives an access token that allows it to send notifications to WNS, which then passes them to the app.

Lock screen notifications

Apps can display content on the lock screen if they declare themselves capable in their manifest. This content simply mirrors the content of the app's tile or badge and does not require any additional API calls.

package.appxmanifest –> Application UI

• Replace the default images with paths to your own logo images.
• Choose whether to show the app's short name on the tile. This name should be 13 characters or less. If the name is too long, it will be truncated. You can elect to show the logo, the name, or neither.
• Choose whether the name's text should use a light or dark font, based on the background color.

Push notifications

Tile notification

Clear any existing notification. You might want to remove any currently shown notification before sending a new one.

Windows.UI.Notifications.TileUpdateManager.createTileUpdaterForApplication().clear();

Pick a template for your tile.

var template = Windows.UI.Notifications.TileTemplateType.tileWideSmallImageAndText01;

Get the template's contents.

var tileXml  = Windows.UI.Notifications.TileUpdateManager.getTemplateContent(template);

 

TileUpdateManager.getTemplateContent returns an XmlDocument. Specify your content by filling in that template using document object model (DOM) methods.

 

var tileTextAttributes = tileXml.getElementsByTagName("text");

 

tileTextAttributes.forEach(function (value, index) {

    value.appendChild(tileXml.createTextNode("textField " + (index + 1)));

});

 

var tileImageAttributes = tileXml.getElementsByTagName("image");

 

tileImageAttributes[0].setAttribute("src", "ms-resource:images/redWide.png");

tileImageAttributes[0].setAttribute("alt", "red graphic");

 

Create the notification based on the XML content you've specified.

 

var tileNotification = new Windows.UI.Notifications.TileNotification(tileXml);

 

Choose whether to enable a notification queue. This step is optional. A tile can cycle through up to five update notifications. If the queue is full, the new notification replaces the oldest notification in the queue. If this value is not set to true, Windows always shows the latest notification.

 

Windows.UI.Notifications.TileUpdateManager.createTileUpdaterForApplication().enableNotificationQueue(true);

 

Tag your tile notification to prevent duplicate notifications. This step is optional. If you have decided to enable the notification queue, you can add a tag to a notification. If a notification arrives with a tag that matches a notification already in the queue, the new notification replaces the old regardless of its place in the queue. This prevents duplicate or out-of-date information from cycling through.

 

tileNotification.tag = "tag01";

Specify whether the information in your update should expire. This step is optional.

 

var seconds = 10;                       

var expirationTime = new Date(currentTime.getTime() + seconds * 1000);

tileNotification.expirationTime = expirationTime;

 

Toast notification

You have declared in your app's manifest that it is toast capable.

var template = Windows.UI.Notifications.ToastTemplateType.toastImageAndText01;

var toastXml = Windows.UI.Notifications.ToastNotificationManager.getTemplateContent(template);

var toastTextElements = toastXml.getElementsByTagName("text");

 

toastTextElements.forEach(function (value, index) {

     value.appendChild(toastXml.createTextNode("textField " + (index + 1)));

});

 

var toastImageElements = tileXml.getElementsByTagName("image");

 

toastImageElements[0].setAttribute("src", "ms-resource:images/redWide.png");

toastImageElements[0].setAttribute("alt", "red graphic");

The display of a toast notification is accompanied by a sound. This audio, specified in the XML content, must be selected from one of several system-provided sounds. These sounds are named in a way that indicates the scenarios they are intended for, such as Notification.IM and Notification.Looping.Call. To play no sound, you must explicitly specify silent audio; the element is required and cannot be simply omitted.

When you launch your app from a toast, you should launch into a view related to the content of the toast. To do so, use the launch attribute of the toast element, which provides a string that is passed to the app. This string has no specific form and is app-defined.

Note that the background color in the toast will be the same as the background color on your tile.

var toast = new Windows.UI.Notifications.ToastNotification(toastXml);

Secondary tile

• An ID for the tile
• Short name and display name
• A string which will be passed to the parent application when the secondary tile is activated.
• Display attributes
• Tile logo

var uriLogo = new Windows.Foundation.Uri("ms-resource:images/SecondaryTileDefault-sdk.png");

var uriSmallLogo = new Windows.Foundation.Uri("ms-resource:images/smallLogoSecondaryTile-sdk.png");

 

var currentTime = new Date();

var TileActivationArguments = "timeTileWasPinned=" + currentTime;

var tile = new Windows.UI.StartScreen.SecondaryTile("SecondaryTile.01",

                                                    "A Second Tile",

                                                    "A Sample Secondary Tile",

                                                    TileActivationArguments,

                                                    Windows.UI.StartScreen.TileDisplayAttributes.showName,

                                                    uriLogo);

tile.foregroundText = Windows.UI.StartScreen.ForegroundText.dark;

tile.smallLogo = uriSmallLogo;

tile.requestCreateAsync().then(function () {

    sdkSample.displayStatus("Operation complete.");

});

Note that the background color Once a secondary tile is created, the parent app tile creates a channel Uniform Resource Identifier (URI) so that it can receive notifications from the secondary tile.

The option to create a secondary tile is seen most often in UI as the Pin to start option. To pin content is to create a secondary tile for it. This option is often presented as a glyph on the app bar.

Only users can create a secondary tile; apps cannot create secondary tiles programmatically. Users also have explicit control over secondary tile removal, either through the Start screen or through the parent app.

Secondary tiles in relation to app tiles

Secondary tiles are associated with a single parent app. They are pinned to the Start screen to provide a user with a consistent and efficient way to launch directly into a frequently used area of the parent app.

Once the secondary tile is pinned, users can receive at-a-glance updates through the tile and use it to launch directly into the parent app to reveal a focused experience centered on the pinned content or contact.

Secondary tiles are similar to app tiles in many ways:

• Uses tile templates to determine layout
• Must include a 152x152 pixel logo
• Can optionally use a 312x152 pixel wide logo
• Can show notifications and badges
• Can be rearranged on the Start screen
• Can be shown on both the All Programs View and Start
• Are automatically deleted when the app is uninstalled

secondary tiles differ from app tiles in some noticeable ways:

• Users can delete their secondary tiles at any time without deleting the parent app.
• Secondary tiles can be created at runtime. App tiles can only be created during installation.
• A flyout prompts the user for confirmation before adding a secondary tile (it shows a preview of the tile)

Windows displays a flyout that shows a preview of the tile to be removed, asking the user to confirm its removal.

Templates

Tile, toast, and badge notifications are each based on their own set of Windows-provided set of templates. Windows provides a large set of templates for tiles and toast, each with varying content, layout, and presentation. They can contain an image or several images, text, and a glyph or numeric badge. Use of these templates allows an app to maintain the expected Windows look and feel in their app and notifications.

Tile templates

Tile templates are available in square and wide sizes. Wide tile templates are available in numerous configurations and come in two varieties: static and peek. The content of a peek tile is taller than the tile itself, so its content scrolls up and down to display the full communication. Static tiles do not scroll.

When an app is first installed, it displays a default tile in the Start screen. The default tile is displayed until the tile receives its first notification. It is recommended that both a square and wide tile are provided in the update.

A tile notification is defined as an XML document whose elements are defined in the tile schema. Tile notifications can be posted by the app when it is running or by a cloud-based service associated with the app.

Toast templates

Toast notifications are also based on templates. Generally, you work with these in a way similar to a tile template, though there are fewer variations and peek templates are not available. In addition to the images and text provided in a tile notification, a toast notification comes with a sound that is played when the toast is shown.

Like a tile, a toast notification is defined as an XML document. Its elements are defined in the toast schema.

Badge templates

A badge is used to provide status on a tile, such as the number of new e-mails received or the status of a network connection. There are two variations: a number and a glyph. Badges are also defined as an XML document and its elements are defined in the badge schema.

A square and wide tile in notification

Add the square tile to the wide tile's payload. It retrieves the binding element that defines the square tile in the squareTileXml payload and imports and appends it as a sibling of the wide tile.

var binding = squareTileXml.getElementsByTagName("binding").item(0);

var node = tileXml.importNode(binding, true);

tileXml.getElementsByTagName("visual").item(0).appendChild(node);

 

Toast template

Specify a sound to play when the toast appears. Windows plays a short sound when it raises a toast. The sound can be played only once or it can loop in the case of a long-duration toast.

 

var audio = toastXml.createElement("audio");

audio.setAttribute("src", "ms-winsoundevent:Notification.IM");

toastNode.appendChild(audio);

 

var audio = toastXml.createElement("audio");

audio.setAttribute("src", "ms-winsoundevent:Notification.Looping.Alarm");

audio.setAttribute("loop", "true");

toastNode.appendChild(audio);

Images  in a template

Note that all images in all templates are required to be less than 150 KB in size and smaller than 800 x 800 pixels.

var template = Windows.UI.Notifications.TileTemplateType.tileWideImageAndText;

var tileXml  = Windows.UI.Notifications.TileUpdateManager.getTemplateContent(template);

Assign a local image included in the app's package. This type of image is included in your Microsoft Visual Studio solution file and is packaged as part of your app. These images are accessed with the "ms-resource:" prefix.

tileImageAttributes[0].setAttribute("src", "ms-resource:images/redWide.png");

tileImageAttributes[0].setAttribute("alt", "red graphic");

Assign a local image from the app's local storage. This type of image is saved by your app in its local storage. This is the location returned by Windows.Storage.ApplicationData.current.localFolder. These images are accessed with the "localfolder://" prefix.

tileImageAttributes[0].setAttribute("src", "localfolder://redWide.png");

Assign a Web image. It uses the http:// protocol to access an image in the app's local storage. You can also use the https:// protocol.

tileImageAttributes[0].setAttribute("src", http://www.microsoft.com/redWide.png);

 

The visual element in the tile or toast notification XML payload contains the baseUri attribute. If the baseUri was set to http://www.microsoft.com/:

 

tileImageAttributes[0].setAttribute("src", "redWide.png");

Inappropriate use of tiles

• Don't create multiple tiles that open subexperiences in the same app. There should only be one tile for each unique app. Instead, consider whether secondary tiles would be a better option for those scenarios.
• Don't clutter the user's Start screen with tiles for extras or accessories along with the app's main tile. Only create multiple tiles when the product is truly a suite and each tile represents a separate core app in that suite.
• Don't create a tile for a configuration or troubleshooting experience within the app. That functionality should be provided to the user through the app's Setting charm.

Appropriate use of badges

• Use numbers when the number is small enough to be meaningful in your scenario. If your badge is likely to always display a number 50 or higher, then consider using a system glyph. Strategies to make the a badge number less overwhelming include showing the count since the user last launched the app rather than the absolute count. For instance, showing the number of missed calls since the user last launched the app is more useful than showing the total number of missed calls since the app was installed.
• Use one of the provided system glyphs to indicate a change in cases where a number would be unhelpful or overwhelming. For instance, the number of new unread articles on a high volume RSS feed can be overwhelming. Instead, use the newMessage system glyph.
• Use a glyph if a number is not meaningful. For instance, if the tile shows a "paused" notification for a playlist, it should use the paused glyph because a number doesn't make any sense for this scenario.
• Use the "new notification" glyph in cases where a number is ambiguous. For instance, "10" in a social media tile badge could mean 10 new requests, 10 new messages, 10 new notifications, or some combination of them all.
• Use the "new notification" glyph in high-volume scenarios, such as mail or some social media, where the tile's badge could be continually displaying the maximum value of 99.

Inappropriate use of badges

• Don't repeat badge numbers elsewhere in a wide tile's body content, because the two instances could be out of sync at times.
• Don't use a glyph if what the glyph tells the user never changes. Glyphs represent notifications and transient state, not any sort of permanent branding or state.

Don't use images with text on them; use a template with text fields for any text content needs.

Avoid image content that looks like a hyperlink, button, or other control. Tiles do not support those elements and the entire tile is a single click target.

Don't use secondary tiles as shortcuts to discrete files that cannot change or other static content.

Don't use a secondary tile as a virtual command button to interact with the parent app, such as a "skip to next track" tile.

Push notifications

The Windows Push Notification Services (WNS) allows third-party developers to send toast, tile, and badge updates from their own cloud service.

Zasada działania taka sama jak w Windows Phone 7.

When your cloud service has an update to send, it notifies WNS using the channel URI. This is done by issuing an HTTP POST request, including the notification payload, over Secure Sockets Layer (SSL). This step requires authentication.

Before you can use the WNS, your app must be registered through the Windows Live Application Management site. To access the site, you will need a Windows Live ID.

application manifest –> Package Display Name & Publisher –> I accept

The credentials that you'll need for your cloud service to communicate with WNS.

• Package Security Identifier (SID): Each app has its own unique Package SID and it must be used to authenticate your service with WNS when the cloud service sends a notification to that app. Provide this value in the client_id parameter in the OAuth request for an access token.
• Secret Key: Provide this value in the client_secret parameter in the OAuth request for an access token.

When an app that is capable of receiving push notifications runs, it must first request a notification channel through the CreatePushNotificationChannelOperation object. This API returns a channel URI that is uniquely linked to the calling application and its tile. Therefore, note that it is not possible to send notifications to multiple users or multiple apps using a single channel URI.

It is not guaranteed that the notification channel URI for an app will always remain the same. We advise that the app request a new channel every time it runs and update its service when the URI changes. The developer should never modify the channel URI and should consider it as a black-box string.

• The cloud service is implemented by you, the developer. We recommend that the app goes through an authentication process with its own service and transmits data over a secure protocol such as HTTPS.
• It is important that the cloud service always ensures that the channel URI uses the domain "notify.windows.com". The service should never push notifications to a channel on any other domain.

Authenticating your cloud service

In order to send a notification, the cloud service must be authenticated through WNS. The first step in this process occurs when you register your app with WNS and the Windows Live Application Management site. During the registration process, your app is given a Package security identifier (SID) and a secret key.

The WNS authentication scheme is implemented using the client credentials profile from the OAuth 2.0 protocol. The cloud service authenticates with WNS by providing its credentials (Package SID and secret key). In return, it receives an access token. This access token allows a cloud service to send a notification. It is required with every notification request sent to the WNS.

The access token can be reused for multiple notification requests. This allows the cloud service to authenticate just once to send many notifications. However, when the access token expires, the cloud service must authenticate again to receive a new access token.

When the device is offline, the WNS will store up to five tile notifications (if queuing is enabled; otherwise, one) and one badge notification for each app. However, toast notifications are never stored

Notification channel

var channelOperation = Windows.Networking.PushNotifications.PushNotificationChannelManager.createPushNotificationChannelForApplicationAsync();

return channelOperation.then(function (newChannel) {

    },

    function (error) {

    }

);

channel.close();

channel = null;

 

Request parameters

 

Authorization, Content-Type (text/xml), Content-Length, X-WNS-Type, X-WNS-Cache-Policy (opt), X-WNS-RequestForStatus (opt), X-WNS-Tag (opt), X-WNS-TTL (opt).

 

Authorization: Bearer <access-token>

 

X-WNS-Type: wns/toast | wns/badge | wns/tile

 

X-WNS-Cache-Policy: cache | no-cache

 

When the notification target device is offline, WNS will cache up to five tile notifications (if cycling is enabled; otherwise just one) and one badge notification for each app. Items are not held in the cache indefinitely and will be dropped after a reasonable period of time. This header is optional and should only be used in cases where the cloud service does not want WNS to cache notifications.

 

X-WNS-RequestForStatus: true | false

Specifies whether the response should include the device status and WNS connection status.

X-WNS-Tag: <string value>

This optional header is used to assign a tag label to a notification. The tag is used in for the replacement policy of the tile in the notification queue when the app has opted for notification cycling. If a notification with this tag already exists in the queue, a new notification with the same tag takes its place. This header is only applicable when sending tile notifications.

X-WNS-TTL: <integer value>

This optional header can be used to specify the TTL (expiration time) for a notification. This is not typically needed, but can be used if a developer wants to ensure that their notifications are not displayed after a period of time. The TTL is specified in seconds and is relative to the time that WNS receives the request. When a TTL is specified, the device will not display the notification after that time. In general, an expiration time will be measured in at least minutes. If this optional value is not specified, the notification will not expire and will be replaced under the normal notification replacement scheme.

Local tile notification

Windows.UI.Notifications.TileUpdateManager.createTileUpdaterForApplication().update(tileNotification);

Local toast notification

var toastNotifier = Windows.UI.Notifications.ToastNotificationManager.createToastNotifier();

toastNotifier.show(toast);

Schedule a toast notification

var template = Windows.UI.Notifications.ToastTemplateType.toastText02;

var toastXml = Windows.UI.Notifications.ToastNotificationManager.getTemplateContent(template);

var currentTime = new Date();

var startTime = new Date(currentTime.getTime() + 3 * 1000);

var scheduledToast = new Windows.UI.Notifications.ScheduledToastNotification(toastXml, startTime);

scheduledToast.id = "Future_Toast"; 

This ID must be 16 characters or less, including the terminating null character. It can be used later if you want to cancel the notification.

var toastNotifier = Windows.UI.Notifications.ToastNotificationManager.createToastNotifier();

toastNotifier.addToSchedule(scheduledToast);

recurring toast

var recurringToast = new Windows.UI.Notifications.ScheduledToastNotification(toastXml, startTime, 60 * 1000, 5);

AutoCycle

By default, tiles show one update at a time and any subsequent updates replace the current content. With cycling enabled, a tile can cycle through up to five update notifications. If the queue is full, the new notification replaces the oldest notification in the queue. The display time and order for notifications is based on several factors and cannot be controlled by applications.

If cycling is enabled and the user is offline, up to five notifications will be saved and delivered when the user comes online. These undelivered notifications also conform to the FIFO queue and replacement tagging logic.

This code enables the notification queue. This only needs to be done once for the lifetime of the app, so you should place this call in your initialization code.

Windows.UI.Notifications.TileUpdateManager.createTileUpdaterForApplication().enableNotificationQueue(true);

Don't raise a toast when your application is in the foreground. Use PushNotificationReceivedEventHandler to intercept push notifications when your application is running.

Secondary tile notifications do not display. You must set the DynamicTileCapable value for your secondary tile to receive notifications. You will receive an error if you attempt to send a notification to a secondary tile without setting this value.

Images for tile notifications and toast notifications need to be smaller than 800x800 pixels and less than 150 KB in size. If any image in a notification exceeds any of these dimensions, the notification will be discarded.

Notifications can only use images in .png or .jpg/.jpeg format.

c.d.n