W odcinku nr. 22 trochę cytatów na temat:
- brokera autentykacji - który został teraz dokładniej objaśniony (np. dowiadujemy się, że wyświetlanie w oknie dialogowym strony webowej do wprowadzenia danych dla autentykacji odbywa się w oddzielnym procesie)
- niskopoziomowego obiektu aplikacji w WinRT - domyślny wygląd i zachowanie aplikacji można zmodyfikować, co może być przydatne do współpracy z DirectX lub do zlecenia wykonania kodu komponentu w oddzielnym procesie
- współpracy DirectX z XAML - jest to nowość w wersji Consumer Preview, zastosowano podejścia z dwóch stron - czyli tworzenie bitmap w DirectX i osadzanie ich w XAML przez brush (dużo XAML i trochę ograniczonego DirectX odświeżanego tak jak XAML) albo cały panel z grafiką DirectX sam zarządzający swoim odświeżaniem i rysujący na swej powierzchni trochę elementów w XAML (zasadniczo DirectX ze stosunkowo niewielką ilością XAML). Dostarczone API dla 3D w Windows 8 stawia na DirectX i jest oczywiście inne niż podzbiór zarządzanego XNA w API Silverlight 5 czy integracja XNA i Silverlight w Windows Phone 7.5, choć rysowanie XAML na powierzchni przypomina trochę koncepcje z WP. Możliwe jest korzystanie z DirectX nie tylko z poziomu C++, można także w C# pod warunkiem opakowania odwołań do DirectX w komponent WinRT. Należy też zauważyć, że - póki co przynajmniej - nie mamy integracji HTML5 z DirectX -:)
- kafelków - z tym wydaniem dowiadujemy zdaje się o możliwości lokalizacji tekstu i obrazków w notyfikacjach, także zdalnych! Obrazki są wybierane spośród wielu dostarczonych przez nas wersji, tak by oprócz przeznaczenia dla danej kultury, pasowały najlepiej pod względem wymiarów i miały odpowiednią kolorystykę adekwatną dla ustawień wysokiego kontrastu.
- ekranu lock-screen
- notyfikacji
User identity
Web authentication broker
When an app calls the web authentication broker, the user gets a dialog box in which the necessary webpages are rendered to sign in. After the user completes those steps, the dialog box goes away and the user continues with the app.
The web authentication broker provides the following benefits:
- An easy-to-use programming interface that frees the app developer from hosting a browser control within their own app.
- User credentials that are isolated from the app.
- Native support for single sign-on with online providers.
It consists of a set of APIs, a broker, and a web host. Your app uses the APIs to communicate with the broker. The broker creates a new web host process in a separate app container. The broker communicates with the app, assembles the user interface (UI), and controls the lifecycle of the web authentication host. The web authentication host renders the pages from the online provider's website.
The typical workflow of using web authentication broker is as follows:
- An app invokes the web authentication broker providing a request (WebAuthenticationBroker.AuthenticateAsync) and callback URI (WebAuthenticationBroker.GetCurrentApplicationCallbackUri). These correspond to an Authorization Endpoint URI and Redirection URI in the OAuth 2.0 protocol. The OpenID protocol and earlier versions of OAuth have similar concepts.
- The broker creates a system dialog box that is modal to the calling app.
- The broker selects a dedicated app container that is separate from the calling app or any other app on the system and clears any persisted cookies. This app container is never shared between two apps simultaneously unless the broker was started in the single sign-on (SSO) mode.
- The broker starts the web authentication host in the selected app container.
- The broker attaches the host's window to the dialog box it created earlier. The host window is responsible for rendering the web content.
- The web authentication host navigates to the request URI. Typically this is a logon page.
- As the user interacts with the online provider website by clicking links or submitting information, the host checks each URI for a match with a callback URI provided by the app before navigating to it.
- If a match is found, the host ends the navigation and signals the broker.
- The broker takes down the dialog box, clears any persisted cookies created by the host from the app container, and returns the protocol data back to the application.
Having the web authentication host in a separate process and in a separate app container allows user credentials to be separate from the app.
Live services
Live Connect enables Metro style apps to work with user info in Hotmail, Microsoft SkyDrive, Microsoft Messenger, and other Live services by using industry standard protocols like OAuth 2.0, JavaScript Object Notation (JSON), and Extensible Messaging and Presence Protocol (XMPP, for real-time communication).
Identity
Your apps - including Metro style apps - can determine when users have signed in to their computers with their Microsoft accounts and can provide a single sign-on experience—that is, they can avoid requiring signed-in users to sign in again. With Microsoft accounts, you don't need to replace existing identity or user account systems; users can simply associate their existing user accounts with their Microsoft accounts.
personalization, profiles
Hotmail - contacts, calendar
Skydrive
Messenger - instant messaging, user's info, and info for his or her Messenger buddies, status updates
Metro style UI
Windows Runtime core application and window objects
Each Metro style app has an instance of the app object that defines the interoperation between the app and Windows. This object works as an intermediary between your code and the Windows system-level functions, and exposes specific features to your app , such as process lifetime management and system settings, plus window views and events. This app object is defined as the type CoreApplication in the Windows.ApplicationModel.Core namespace.
As a developer of a Metro style app, you don't directly create an instance of CoreApplication. Rather, the Windows Runtime creates it for your app when the app launches. It is a static type, and the running instance is a singleton object. There are two types of app launches: cold starts and warm starts. In a cold start, there is no current instance of the app, and one is created for you. In a warm start, an instance of the app is already running. So the Windows Runtime finds the current process for the running app, and gets a pointer to its instance of CoreApplication instead of creating a new instance.
It has one overloaded method that lets you configure and customize the window view and window event behaviors: CoreApplication.Run. The two overloads for CoreApplication.Run take either an activation factory callback, which you implement using IGetActivationFactory, or a specific view framework source, which you implement using IFrameworkViewSource.
int main(Platform::Array<Platform::String^>^)
{
// EventsViewSource implements IFrameworkViewSource.
auto frameworkViewSource = ref new EventsViewSource();
Windows::ApplicationModel::Core::CoreApplication::Run(frameworkViewSource);
return 0;
}
You commonly use this overload of CoreApplication.Run to obtain access to DirectX resources and attach them to a the app object's associated CoreWindow.
You activate out-of-process server types from your Metro style app by implementing the IGetActivationFactory interface, which is accessed by the app object.
You can define your own Windows Runtime classes that can be used from your Metro style app. Under some circumstances, you may want your classes to run in a different process from your Metro style app.
- Your app has background work that is performed in a separate process.
- Your app may require specific process isolation between your classes and your app's process.
- Your app may want to share the same class instance between multiple processes. This scenario is very uncommon.
DirectX and XAML interop
With the release of Windows 8 Consumer Preview, you can use XAML and Direct X together in your Metro style app. DirectX APIs are not defined as Windows Runtime types, so you typically use C++/Cx to develop XAML app components that interop with DirectX. That said, you can create a Metro style C# XAML app that uses DirectX if you wrap the DirectX calls in a separate Windows Runtime type library.
You can use Direct2D and Direct3D to render part or all of the graphics.
Two concepts:
- Shared surfaces are sized regions of the display, defined by XAML, that you can use DirectX to draw into indirectly, using Windows::UI::Xaml::Media::Brush types. For shared surfaces, you don't control the calls to present the swap chain(s). The updates to the shared surface are synced to the XAML framework's updates.
- The swap chain itself. This provides the back buffer of the DirectX rendering pipeline, the area of memory that is presented for display after the render target is complete.
You use one of these Windows Runtime types to incorporate DirectX rendering into your XAML app:
- Windows::UI::Xaml::Media::Imaging::SurfaceImageSource - to compose a static image, or draw a complex image on event-driven intervals. This type handles a sized DirectX drawing surface. Typically, you use this type when composing an image or texture as a bitmap for display in a document or UI element. It doesn't work well for real-time interactivity, such as a high-performance game. That's because updates to a SurfaceImageSource object are synced to XAML user interface updates. SurfaceImageSource graphics objects can be composited with other XAML UI elements. You can transform or project them , and the XAML framework respects any opacity or z-index values. (Result: bitmap –> to ImageBrush)
- Windows::UI::Xaml::Media::Imaging::VirtualSurfaceImageSource - if the image is larger than the provided screen real estate, and can be panned or zoomed by the user. This type handles a sized DirectX drawing surface that is larger than the screen. Like SurfaceImageSource, you use this when composing a complex image or control dynamically and it doesn't work well for high-performance games. Examples: map controls, a large, image-dense document viewer. (Result: bitmap)
- Windows.UI::Xaml::Controls::SwapChainBackgroundPanel - to support high-performance graphics and gaming, where you manage the swap chain directly. You can refresh the graphics without syncing to the XAML framework refresh timer. This type enables you to access the graphics device's swap chain (IDXGISwapChain1) directly and layer XAML atop the render target. You create your own DirectX swap chain and manage the presentation of your rendered content. You can then add XAML elements to the SwapChainBackgroundPanel object, such as menus, heads-up displays, and other UI overlays.
To ensure good performance, there are certain limitations to the SwapChainBackgroundPanel type:
- There is only one SwapChainBackgroundPanel instance per app.
- The SwapChainBackgroundPanel is at the bottom of the z-list for the user interface, below all of the XAML elements.
- The SwapChainBackgroundPanel must be the root XAML element of the app.
- The Opacity, RenderTransform, Projection, and Clip are not supported.
- You must set the DirectX swap chain's scaling mode (in DXGI_SWAP_CHAIN_DESC1) to DXGI_SCALING_STRETCH.
- You should set the DirectX swap chain's height and width (in DXGI_SWAP_CHAIN_DESC1) to the current dimensions of the app window. If you don't, the display content will be scaled (using DXGI_SCALING_STRETCH) to fit.
- You can't set the DirectX swap chain's alpha mode (in DXGI_SWAP_CHAIN_DESC1) to DXGI_ALPHA_MODE_PREMULTIPLIED.
- You must create the DirectX swap chain by calling IDXGIFactory2::CreateSwapChainForComposition.
If you need to synchronize the updates of SwapChainBackgroundPanel to those of the XAML framework, register for the Windows::UI::Xaml::Media::CompositionTarget::Rendering event. Otherwise, you must consider any cross-thread issues if you try to update the XAML elements from a different thread than the one updating the SwapChainBackgroundPanel.
SwapChainBackgroundPanel inherits from Windows::UI::Xaml::Controls::Grid, and supports similar layout behavior.
After a DirectX swap chain has been set, all input events that are fired for SwapChainBackgroundPanel work the same as they do for any other XAML element. You don't set a background brush for SwapChainBackgroundPanel, and you dont' need to handle input events from the app's CoreWindow object directly as you do in DirectX apps that don't use SwapChainBackgroundPanel.
All content of the visual XAML element tree under a direct child of a SwapChainBackgroundPanel is clipped to the layout size of the SwapChainBackgroundPanel object’s immediate child. Any content that is transformed outside these layout bounds won't be rendered. Therefore, place any XAML content that you animate with a XAML Storyboard in the visual tree under an element whose layout bounds are large enough to contain the full range of the animation.
Limit the number of immediate visual XAML elements under a SwapChainBackgroundPanel. If possible, group elements that are in close proximity under a common parent. Likewise, don't create a single full-screen child XAML element for your app's SwapChainBackgroundPanel because this increases overdraw in the app and decreases performance. As a rule, create no more than 8 immediate XAML visual children for your app's SwapChainBackgroundPanel, and each element must have a layout size only as large as necessary to contain the element's visual content. However, you can make the visual tree of elements under a child element of the SwapChainBackgroundPanel sufficiently complex without decreasing performance too badly.
Więcej szczegółów na DirectX and XAML interop.
Tiles, badges and notifications
Tile concepts
An update notification that does not include a version for the current size of the tile will not be shown unless that tile is resized by the user.
You must declare in your app manifest (package.appxmanifest) whether you want to show the logo or the short name.
While a badge is shown on a tile, it is not part of the tile's XML content and is not affected by tile updates. Badges have their own XML schema and are independently updated through their own set of APIs.
Tile templates for both square and wide tiles are available in two varieties: static and peek. The content of a peek tile scrolls up and down within the tile space to display the full communication; static tiles are fixed.
The default tile also optionally defines a background color for your tile, to associate with your brand or simply to differentiate your tile. This color choice is also reflected in other areas of the UI:
- The button color in any dialog box that is owned by your app
- The App Description page in the Windows Store
Scaling tile sizes by Windows. Because Windows can be run on many different devices, it is a best practice to include scaled versions of your images in your app package so that Windows can choose the most appropriate version for the device and its settin.
Secondary tiles overview
Secondary tiles can be shown on both the All Programs View and Start.
Windows can copy secondary tiles through the cloud when an app is acquired by a user on a second computer.
Toast notification concepts
Sending toast notifications from desktop apps
Generally, sending a toast notification from a desktop app is the same as sending it from a Metro style app. However, you should be aware of these differences and requirements:
- For a desktop app to display a toast, the app must have a shortcut on the Start screen.
- The shortcut must have an AppUserModelID.
- Desktop apps cannot schedule a toast.
Text can be localized by storing the strings in different languages in a resource file—Resources.resjson (JavaScript) or Resources.resw (C# and C++).
Images can be localized, scaled, and made accessible through high contrast.
- Local images. These images must be included in your app package to use the application resources platform. Local storage is not included in the resources platform, so the app must write each of the appropriately localized/scaled/accessible file versions into local storage.
- Cloud images. A query string is appended to the image's URL.
| Type | Query string | Possible values | Example |
|---|---|---|---|
| Scale | scale |
| ?scale=100 |
| Accessibility | contrast |
| ?contrast=standard |
| Localization | lang | The BCP-47 language tag specified in the notification template's lang attribute, or the default app language if lang is omitted. | ?lang=en-US |
How to structure your app package for globalization
(default en-US)
Text:
/ProjectFolder
/strings
/en-US
resources.resjson
/fr-FR
resources.resjson
/ja-JP
resources.resjson
Images (only provided in the app's package (ms-appx)):
| /ProjectFolder | /ProjectFolder | /ProjectFolder |
How to use localized images and text in a notification
Text
In the text element of your template content, use the "ms-resource:" prefix in the text body, followed by the string tag as defined in the Resources.resjson or Resources.resw file.
Local images
Images included in the app package
Add the "ms-appx:" prefix to the resource path in your template's image element.
Images saved to local storage
Add the "ms-appdata:local/" prefix to the path to the file relative to local storage. Image versions in local storage cannot be recognized by Windows based on the storage structure as in the application resources platform.
Images saved in the Roaming or Temp folders
These images cannot be used.
Web images
Use an HTTP handler to inspect the query string for the language, scale, and contrast, the values of which can then be used.
Lock screen overview
An app can reflect three different types of information to the lock screen:
- The app tile's current badge
- The text from the app tile's most recent update notification
- Toast notifications
On the lock screen the badge sits next to a logo image rather than on a tile and only the text portion of a tile update is shown. Images in the tile update are not displayed on the lock screen.
Up to seven apps can have a lock screen presence at once. All seven apps can show badges and toast, but only one of those apps is allowed to show the text of its latest notification.
As long as your app has a tile or badge on the lock screen and is declared Toast Capable in the app's package.appxmanifest file, any toast notifications sent by your app will appear on the lock screen as well.
The best app candidates to be placed on the lock screen can convey understandable, context-free, summary information through only a badge and a logo icon.
Declaring your app's lock screen capabilities
Lock screen tile display type
If you use the Visual Studio 11 Express Beta for Windows 8 manifest editor, choose the appropriate Lock Screen Notifications option in the Application UI tab. The choices are:
- Badge: Your app can show only a badge on the lock screen.
- Badge and Tile Text: Your app can show both a badge and a detailed status on the lock screen.
Both options provide that toast notifications for your app will appear on the lock screen if toast is enabled for this user.
Badge logo
When your app's badge is shown on the lock screen, it appears next to an icon for your app. This icon must meet these requirements:
- Size: 24 x 24 pixels
- Type: .png
- Color: monochrome white
- Transparency: any
Wide logo
When the lock screen displays text from a tile update, it does so only in a wide tile. Therefore, if you declared the Badge and Tile Text option, you must provide a wide logo for your app's tile or your manifest will be invalid and your app will not build.
If the tile notification currently shown on the lock screen is removed, nothing is shown in its place until a new tile notification arrives.
Background task
An app with a lock screen presence must declare one of the following types of background tasks:
- Control Channel
- Timer
- Push Notification
Prompting the user to place your app tile on the lock screen
Your app can ask the user to place the app on the lock screen. Call Windows.ApplicationModel.Background.BackgroundExecutionManager.requestAccessAsync to present a dialog box through which the user must explicitly select "allow" or "don't allow". In response, your app will receive one of the values in the BackgroundAccessStatus enumeration.
If all seven lock screen positions are already full when this request is made, the user is presented with a Flyout that asks them to choose which of the existing apps that the new one should replace.
An app is allowed to ask for lock screen access only once. The user can choose only one of the two options, so their preference will have been stated. Further calls to requestAccessAsync will be ignored.
User management of lock screen apps
The user can toggle an app's lock screen rights (and associated background access) in the Permissions section of the app's Settings pane.
Sending information to the lock screen
Once your app is on the lock screen, there is no additional work for you to do. Windows simply routes badge updates, tile updates, and toasts normally and they appear on the lock screen.
Note Tile notifications shown on the lock screen do not use the notification queue. Only the most recent tile update will appear on the lock screen, behaving like an app tile with the notification queue disabled.
Sending notifications
There are four mechanisms that an app can use to deliver a notification:
- Local - Tile, Badge, Toast
- Scheduled - Tile, Toast
- Periodic (polling a cloud service) - Tile, Badge
- Push -Tile, Badge, Toast
Push notification overview
One access token cannot be used to send notifications across multiple apps. Therefore, if your cloud service supports multiple apps, it must provide the correct access token for the app when pushing a notification to each channel URI.
When the device is offline, the WNS will store up to five tile notifications (if queuing is enabled; otherwise, one tile notification) and one badge notification for each app. However, toast notifications are never stored.
Posty
Brak komentarzy:
Prześlij komentarz