Notatki o Windows 8 - odc. 10

W tym odcinku poruszone zostały m.in takie zagadnienia jak single sign-on, zasoby i lokalizacja aplikacji JS,  manifest aplikacji i jego lokalizacja, uprawnienia, kontrakty, pakowanie, debugowanie, analiza jakościowa kodu i unit testy.

Single Sign-On

Developers

1. Use the AuthenticationAsync function that doesn't expose the callbackUri parameter. This ensures that the webpage name has the "ms-app://" string at the front of the webpage title.
2. Call the GetCurrentApplicationCallbackUri method to get your applications SID.
3. When only authentication is required, use the WebAuthenticationOptions.SilentMode flag to avoid a dialog box.

Providers

1. Allow applications to register "ms-app" scheme as their redirect URIs.
2. Don't allow applications to use a redirect URI if it hasn't been registered. For example, in the OAuth 2.0 protocol, the value of the redirect_uri parameter must be within the set of URIs registered by the application.
3. Recommended but optional:  Use the protocol flows that require implicit grants of the OAuth 2.0 protocol.

Live Connect

On a Windows Developer Preview computer, a user can link a Microsoft account (such as a Hotmail address) with a local account on that computer. Then, when the user signs in to that computer, he or she can sign in with that Microsoft account instead of that local account. When this happens, if your apps use the Live Connect  APIs, they can automatically detect that the user has already signed in and not require him or her to sign in again.

App developers can provide a single sign-on experience across Metro style apps. For example, if users are signed in to a Windows Developer Preview computer, they will already be signed into participating Metro style apps that support signing in with their Microsoft account.

The most straightforward way to enable single sign-on in an application is to use the Live Connect sign-in control that is a part of the Live  software development kit (SDK). This allows the application to seamlessly authenticate the user and request access to the user’s profile or other info.

Apps that need to authenticate a local user against the app's own web service can use the authentication token, which contains an app-specific user ID and is encoded as a JavaScript Object Notation (JSON) Web Token (JWT). The basic flow for working with the authentication token is for the app to send the token to its web service, which decodes it, saves the data from each segment of the token, and then uses the user ID value for comparison to identify the user on subsequent sign-ins.

Application resources

User- and device-specific UI resources

Localize strings - a resjson resource file:

{

   "Placeholder1" : "Click here",

   "Title1"       : "Tooltip Info",

   "ListElement1" : "Red",

   "ListElement2" : "Blue"

   "_scenario.comment" : "Be sure to keep red/blue in this order."

}

The resource file is placed in a folder that has been named for the BCP-47 language tag (such as en-US/resources.resjson)

Customize images

img - images/logo.png

• images/logo.scale-100.png
• images/logo.scale-140.png
• images/logo.scale-180.png

Acessing:

var R = new Windows.ApplicationModel.Resources.ResourceLoader();

el.innerHTML = R.getString('HelloWorld');

where HelloWorld is the name of the string "Hello World" in the resource.resw or resource.resjson file.

<input type="text" placeholder="Click here" title="Tooltip Info" />

<ul>

   <li>Male</li>

   <li>Female</li>

</ul>

<input type="text" placeholder="" title=" " data-win-res="placeholder:Placeholder1; title: Title1" />

<ul>

   <li data-win-res="textContent:ListElement1"></li>

   <li data-win-res="textContent:ListElement2"></li>

</ul>

data-win-res="attribute name:resource ID;attribute name2:resource ID2"

In order to process these data-win-res attributes, the document must include a Windows Library for JavaScript toolkit called Res.js, which exposes a processAll call.

VS project –> new folder strings –> en-US, de-DE, fr-FR –> Add: Resource file (.resjson)

Strings are displayed in the default display language of your machine.

Packing

To install your package on your local machine, follow these instructions:

1. Go to the package output location, typically located at <application>/Packages/<appname_configuration_Test>
2. Right-click the .bat file and then click Run as administrator.

<drive>:\Program Files\Windows Kits\8.0\Software Logo Toolkit\wslkui.exe

You can upload your package by following these instructions:

1. Go to the Package Upload page on the Windows Developer Center website.
2. Find the package upload (.appxupload) file, typically located at <application>/Packages/<appname_configuration>.appxupload
3. Drag the .appxUpload file to the Package Upload page.

Manifest designer

Application UI: Logo, Wide Logo, Small Logo, Show Name, Short Name, Foreground Text, Background Color, Badge Logo, Toast Capable, Lock Screen Notifications, (SplashScreen) Background Color, Initial Rotation

Capabilities

Contracts: AutoPlay Content, AutoPlay Device, Background Tasks, Camera Settings, Certificates, Contact Picker, Digital Rights Management, File Picker, File Type Associations, Game Explorer, Print Task Settings, Protocol, Search, Send Target, Share Target, User Tile Provider

Background Tasks - Enables the app to specify the class name of an inproc server DLL that runs application code in the background in response to external trigger events. When the event triggers, the Run method of the given class is invoked.

The package build process transforms the source manifest (.appxmanifest) file into the target manifest (AppxManifest.xml) file that is included in the package contents. This transformation can introduce changes into the manifest. You can override this transformation by providing your own target manifest file.

When you create a local package, a test layout is generated that includes the signed package itself. The certificate (.cer) file that is included in the test layout contains the public key used to sign the package.

The certificate file is automatically generated from the project source certificate (.pfx) file, which contains the public and private key pair used to sign the package. This certificate file is added to your project when you first create the package, provided that the file doesn’t already exist. The certificate Subject field is set to the Publisher attribute of the Identity element of the source manifest (.appxmanifest) file.

• If you create a local package, the Publisher attribute is set by default to your user name.
• If you create a package for the Windows Store, the Publisher attribute is set to the Publisher ID that is obtained from your account at the Store when you sign in during package creation.

The package creation process also adds two properties to the project file: PackageCertificateThumbprint, PackageCertificateKeyFile. If you would want to create a certificate or use an existing certificate to sign a package, you can use the Manifest Designer to select the certificate.

If you would want to create a certificate or use an existing certificate to sign a package, you can use the Manifest Designer to select the certificate.

The F5 icon (the small green right-facing triangle) on the Visual Studio toolbar has a dropdown list that typically offers you three choices for running an app:

• Simulator
• Local Machine
• Remote Machine

The simulator is effectively a remote desktop connection to your local machine. Because of this, you do not get the full performance that you would if you had chosen Local Machine.

Output:

• The source Images folder and *.xaml files are copied to the output folder.
• The AppxManifest.xml file is a simple transformation of the source manifest file Package.appxmanifest.
• The *.build.appxrecipe file is used by the build process for incremental builds.
• The resource.pri file contains the app resources.

Validating a package locally

<drive>:\program files\windows kits\8.0\software logo toolkit\wslkui.exe

In the Select the validation to perform dialog, choose Validate Tailored App.

In the Select an app to validate dialog, choose the app with your Package Name.

Manifest localization

You can localize your Metro style app display name, description, and other identifying features.  Because the Manifest Designer does not support field localization, you must open the manifest file in a text editor and add localization information manually.

<Properties>

<Property>

<DisplayName>ms-resource:calculator</DisplayName>

<Description>ms-resource:numbers</Description>

<Logo>tile.png</Logo>

</Property>

</Properties>

 

For Metro style apps that use XAML, these fields are localized in resources.resw files using the ResX editor. To create the United States English version of the manifest fields, you would add an en-us\resources.resw file.

For Metro style apps that use JavaScript, these fields are localized by using JSON syntax to add strings to the resources.resjson file. To create the United States English version of the manifest fields, you would add a \strings\en-us\resources.resjson file.

You can reserve multiple names for an app at the Windows Store.  When you publish a package to the store, the value of the token strings you’ve created for the DisplayName element in the package manifest must match the names you’ve reserved for the app at the Store.  If not, a validation error will be displayed when you upload the package to the Store.

Extension SDKs

You can add an entire software development kit (SDK) to your project without having to add the components one at a time. You can also group together your own assemblies, components, and resources into an SDK and distribute it as one piece. SDKs that you can add to your app or create and distribute as one piece are called extensions SDKs.

Extensions SDKs come in two flavors

• Framework extension SDKs, which are included in Windows Developer Preview and Visual Studio. For example, the C runtime SDK. If an app uses a framework extension SDK, it is marked in the manifest file as a dependency. When the app runs, the framework extension SDK is downloaded from the Windows Store.
• Non-framework extension SDKs, which are created by you, your friend, or a vendor. The non-framework SDK is deployed with the app that uses it. Non-framework SDKs can be installed as a VSIX extension.

We’ll be adding our extension SDK to a managed Metro style app. Because managed assemblies are simpler and easier to create than Windows metadata components (.wmd), we’ll use them to build our extension SDK.

1. Create a new Visual C# Windows Class Library for Tailored Applications project named MyCompany.Alpha.
2. Add a new Visual C# Windows Class Library for Tailored Applications project named MyCompany.Beta.

You can combine your two assemblies into an extension SDK and install it to your machine this way:

1. Navigate to the folder  C:\Program Files\Microsoft SDKs\Windows\v8.0\ExtensionSDKs
2. Create a new subfolder named MyCompany.Extension.
3. Create a new subfolder in this folder named by the version number of your extension, for example, 1.0:  MyCompany.Extension\1.0
4. Create a new manifest text file named SDKManifest.xml.
5. Fill the manifest file with the following xml: 

   <?xml version="1.0"?>

   <FileList AppliesTo="TailoredC#,TailoredVB"

       MinToolsVersion="4.0" MinVSVersion="11.0"

       DisplayName="Brand name of extension">

       <File Reference="MyCompany.Alpha.dll"/>

       <File Reference="MyCompany.Beta.dll"/>

       </FileList>
6. Copy the manifest file to the version subfolder:  MyCompany.Extension\1.0\SDKManifest.xml
7. Create a new subfolder named References in the version folder:  MyCompany.Extension\1.0\References
8. Create a new subfolder named CommonConfiguration in the References folder:  MyCompany.Extension\1.0\References\CommonConfiguration
9. Create a new subfolder named neutral in the CommonConfiguration folder:  MyCompany.Extension\1.0\References\CommonConfiguration\neutral
10. Copy the MyCompany.Alpha and MyCompany.Beta assemblies to the neutral folder.

Actually, folders are examined in order from the least specific to the most specific:

• \commonconfiguration\neutral
• \commonconfiguration\[arch]
• \[config]\neutral
• \[config]\[arch]

Your extension is immediately available through the Add Reference dialog in Visual Studio.

Notice that there are no references at all under the References node. Managed Metro style apps invisibly include references to all of the WinSDK and the .NET 4.5 Core API. For the same reason, there is no Framework item in the Assemblies tab in the Reference Manager.

Debugging and testing

To debug, test, or run performance analysis on a Metro style app, you can run the app on the same machine that hosts Visual Studio. Because Metro style apps run in a full screen window, using a dual-monitor display is the most efficient way to run your application locally.  Remote connection: Use all my monitors for the remote session.

When you run a Metro style app on a local machine and use only a single monitor, you might want to switch back to Visual Studio while leaving the app running. To return to Visual Studio, press ALT + TAB.

The Metro style simulator does not run in an isolated environment on your local machine. Therefore, errors that occur in the simulator, such as a non-recoverable system-wide error, can also affect the entire machine.

To switch between standard mouse mode and touch emulation, click one of the following buttons on the palette: Start touch emulation, Start mouse mode. Hold is not supported in Visual Studio 11 Developer Preview.

• The remote device and the Visual machine must be connected over a network or connected directly through an Ethernet cable (if the device does not have an Ethernet port, you can use a USB to Ethernet adapter to connect to the cable). Debugging over the internet is not supported.
• The remote device must be running the remote debugging components.
• You must be an administrator on the remote device to configure the firewall during installation. You must have user access to the remote device to run or connect to the remote debugger.

Debugging is not supported on ARM devices in Visual Studio 11 Developer Preview.

Debugging Java Script apps

When debugging JavaScript apps, you can use an interactive debugging model, in which you can view and interact with the rendered HTML, CSS, and JavaScript code to fix problems. You can also use a more traditional Visual Studio debugging model, which enables you to perform important tasks like setting breakpoints and stepping through code.

DOM Explorer

JavaScript Console window - in the console, you can interact with the rendered JavaScript app by viewing and sending messages from your code to the console, by viewing the values of local and global variables, and by the immediate execution of JavaScript code. The console also reports JavaScript errors and exceptions, in addition to Document Object Model (DOM) and Windows Runtime exceptions.

The Visual Studio debugger enables you to set breakpoints and step through code by using commands like F5 (Start Debugging or Continue), F11 (Step Into). When stepping through code, you can interact with the app based on the current state in the JavaScript Console window.

You can also use standard Visual Studio features such as the Watch window and Profiler when debugging JavaScript apps.

The syntax for the console commands that you can use in your scripts. You can also enter these commands in the JavaScript Console window.

JavaScript apps that reference managed or native back end code are called hybrid applications. When you debug these apps, you must specify the debugger to run. You cannot debug JavaScript and managed or native code simultaneously.

Code analysis is not available for JavaScript code.

Microsoft Visual Studio 11 Developer Preview includes support for unit testing managed Metro style apps and includes unit test library templates for Visual C#, Visual Basic and Visual C++.

Metro style Unit Test Library + Capabilities

Unit Test Explorer

c.d.n