sobota, 5 stycznia 2013

Z dokumentacji WP8 (2)

Kolejna porcja ciekawostek, które wygrzebałem z dokumentacji Windows Phone. Wymienię kilka najciekawszych: wykrywanie przekleństw przy rozpoznawaniu mowy, współdzielenie prostych UserControl dla Win8 i WP8 (niby nic wielkiego, ale niekiedy taki pomysł może się przydać), debugowanie obrazu MDIL aplikacji, brak weryfikacji capabilities w aplikacjach WP8. Pojawia się też refleksja, że kod z WinRT API nie jest binarnie przenośny. Nawet pliki z tak samo wyglądającym kodem w Win8 i WP8 wymagają osobnych kompilacji na każdą z platform. Pod tym względem .NET w Portable Libraries pozostaje lepszy, choć… czy w sumie dużo tracimy?


Konwersja: Windows.Devices.Geolocation.Geocoordinate that’s returned when you get your current location to the System.Device.Location.GeoCoordinate expected by the Map control.

You can get an extension method to do this conversion, along with other useful extensions to the Maps API, by downloading the Windows Phone Toolkit.

How to request driving or walking directions for Windows Phone 8


How to provide driving or walking directions for Windows Phone 8



Supported media codecs for Windows Phone - w zależności od rodzaju procesora


Apps that track location in the background automatically participate in Fast Resume.

When an app running in the background is deactivated, the Deactivated event is raised just like a regular foreground application. Your app can check to see the reason for deactivation in the Deactivated event handler by checking the Reason property.

  • The app stops actively tracking location. An app stops tracking location by removing event handlers for the PositionChanged and StatusChanged events of the Geolocator class or by calling the Stop() method of the GeoCoordinateWatcher class.

  • The app has run in the background for 4 hours without user interaction.

  • Battery Saver is active.

  • Device memory is low.

  • The user disables Location Services on the phone.

  • Another app begins running in the background.

Search extensibility

Windows Phone 7.1: In the Extras.xml file, the AppTitle element is used to specify the title of the app, as you would like it to appear in the apps pivot page of the quick card. With Windows Phone 8, the app title from the Apps list is used instead.

The debugging limitation doesn’t apply to Windows Phone 8 apps. When debugging a Windows Phone 8 app, you can set breakpoints in the URI mapper and use the debugging tools to examine the contents of the deep link URI. Although simulating a search extensibility launch isn’t necessary in Windows Phone 8, you may want to use it as a convenient way to launch your app with a specific URI.

Search registration and launch reference for Windows Phone - dodatkowe pola i nowe karty dla eventów


System voice commands for Windows Phone 8

If the speech recognizer uses a predefined grammar type and a user speaks profanity, the profanity words within the recognized phrases are encapsulated in <profanity> tags in the speech recognition result's Text property.

If the Windows.Phone.Speech.Recognition.SpeechRecognizerUI class is used, any profanity words are individually censored on the displayed Heard you say screen, but the actual recognition result still will be returned with encapsulated <profanity> tags, as described earlier.

Semantics are info that a grammar author enters when creating an XML format grammar that conforms to the Speech Recognition Grammar Specification (SRGS) Version 1.0. Semantics assign meaning to the contents of an item element or to a ruleref element and the phrases they define. For example, a semantic assignment might assign an airport code to the name of a city in a list of city names that can be recognized. The tag element within the item element defines the semantic value.

<rule id = "flightCities">
      <item> New York <tag> "JFK" </tag> </item>
      <item> London <tag> "LHR" </tag> </item>
      <item> Beijing <tag> "PEK" </tag> </item>

A semantic assignment to a ruleref element could indicate that the airport name returned by one rule reference to a list of airports is the point of origin for a flight, and the airport name returned by another rule reference to the same list of airports is the flight's destination. In the following example, the first rule reference to the rule named flightCities is directly followed by a tag element. The tag element creates a property called LeavingFrom for the Rule Variable of the rule named flightBooker, and assigns the recognition result from the flightCities rule to the LeavingFrom property. The second reference to the flightCities rule assigns recognition result from the flightCities rule to the GoingTo property.

<rule id="flightBooker" scope="public">
    <item repeat="0-1"> I want to </item>
    <item repeat="0-1"> fly </item>
    <item repeat="0-1"> me </item>
    <item repeat="0-1"> from </item>
    <ruleref uri="#flightCities" />
    <tag> out.LeavingFrom=rules.latest(); </tag>
    <item> to </item>
    <ruleref uri="#flightCities" />
    <tag> out.GoingTo=rules.latest(); </tag>

  <rule id = "flightCities">
      <item> New York <tag> "JFK" </tag> </item>
      <item> London <tag> "LHR" </tag> </item>
      <item> Beijing <tag> "PEK" </tag> </item>


You can also select a speaking voice of a particular language using Speech Synthesis Markup Language (SSML).

Handling errors in speech apps for Windows Phone

Although occasionally you'll encounter a managed exception when dealing with the speech feature, the majority of speech errors are returned in HResult format.


To increase the discoverability of your app that integrates with the Wallet, you can define your app as a Wallet extension. This makes your app appear in the other list of apps in the Wallet when the user taps add. The user can then pick your app from that list and the app will be downloaded and installed on the phone. This is another great way to increase the discoverability of your app.

<Extensions> <Extension ExtensionName="Wallet_app_other" ConsumerID="{3860f72b-b8fc-4503-b922-c25f315da9c3}" TaskID="_default" /> </Extensions>

  • ExtensionName: Defines the type of extension you are registering. Valid values for this attribute when registering as a Wallet extension are:

    • Wallet_app_other – for non-specific Wallet items

    • Wallet_app_loyalty – for loyalty cards

    • Wallet_app_membership – for membership cards

    • Wallet_app_transit – for transit cards

    • Wallet_app_payment – for payment cards

    You only need to register once, even if your app is used for multiple Wallet item types. You can register as an extension for multiple Wallet item types if you want by adding multiple Extension elements to the Extensions section in WMAppManifest.xml. Currently, when the user taps other to bring up the Add to Wallet dialog box and look for Wallet extensions, all extensions are returned, regardless of what Wallet item type was defined when registering as an extension.

  • ConsumerID: This should be set to the same value as the ProductID attribute of the App element. This is shown in the preceding code.

  • TaskID: Set this to default.


An app that is running in the background cannot vibrate the phone. If your code tries to use vibration while the app is running in the background, nothing happens, but no exception is raised.

.NET API – zgodne z WP 7.x


using Windows.Phone.Devices.Notification;

VibrationDevice testVibrationDevice = VibrationDevice.GetDefault();



Globalization & localization

Font and language configuration support for Windows Phone

New project default behavior is that Language properties of the running app are initialized using parameters from the resource file the app loads when it launches (ResourceLanguage and ResourceFlowDirection). This behavior imposes the pattern that the font and text flow direction are aligned with the language of the resource being displayed at run time.

The InitializeLanguage() function in the App.xaml.cs file sets the app's RootFrame.Language based on the value of the AppResoures.ResourceLanguage resource, and its RootFrame.lowDirection based on the value of the AppResources.ResourceFlowDirection resource.

  • If you want to start from scratch, you can comment out the app's InitializeLanguage method call in App.xaml.cs.

  • If you want to globally impose a specific language regardless of which locale the user has chosen for their phone's display language, you can modify the RootLanguage string in each of the app’s .resx files.

  • If you want FlowDirection to globally flow in one direction regardless of traditional direction of the app’s runtime language, you can modify the ResourceFlowDirection string in the apps .resx files.

App Manifest

App capabilities and hardware requirements for Windows Phone

WP8: The FunctionalRequirements element is an optional child of the App element and should immediately follow the Requirements section in the manifest file. Use the FunctionalRequirements element to indicate if the app requires certain hardware functionality, such as the increased memory limit.

How to determine app capabilities

The Windows Phone SDK 8.0 does not contain tools to detect the capabilities required for apps that target Windows Phone 8. When you submit an app that targets Windows Phone 8 to the Store, capabilities are not analyzed and the app manifest file is not regenerated or corrected.


Direct3D for Windows Phone 8

Windows Phone 8 supports a subset of the APIs in the DirectX library. Most notably, the Windows Imaging Component (WIC) and Direct2D libraries are entirely unsupported. The APIs that are supported on the phone are supported at the 9_3 feature level which means that they behave differently than the same APIs running on a device that supports a higher feature level (Microsoft Direct3D 11 introduced the concept of feature levels). There are a few instances where the APIs behave differently on the phone than they do in a desktop app using the 9_3 feature level, particularly around setting up the swap chain for the graphics device.

XAML and Direct3D apps for Windows Phone 8

Direct3D with XAML apps for Windows Phone 8

Direct3D app development for Windows Phone 8

Microsoft Media Foundation for Windows Phone 8

Microsoft Media Foundation (MF) is a framework for audio and video capture and playback for the desktop. Microsoft Media Foundation for Windows Phone is a reimplementation of a subset of the MF APIs. With this feature, Windows Phone 8 apps can implement the following scenarios.

  • Render video to textures in apps that use native code.

  • Display cinematics for games.

  • Play in-game background audio in apps that use native code, such as a game soundtrack.

Native audio APIs for Windows Phone 8

Windows Phone 8 apps can use the WASAPI and XAudio2 APIs to play and process audio and manage audio streams.

XAudio2 is a low-level audio API that you can use to play, mix, and process audio for sound effects in games written in native code. Windows Phone 8 supports the standard XAudio2 feature set you can use on the desktop, although with some exceptions. For example, the desktop supports multiple audio devices, and the phone supports only one. This might affect the parameters you use to call some APIs. Another difference is support for compressed audio data. The XAudio2 interface works only with uncompressed PCM or ADPCM audio data. On the desktop, you can use Microsoft Media Foundation APIs to decompress content into PCM data to use with XAudio2. Windows Phone 8 does not offer these helper APIs, so it will be more difficult to implement a scenario that includes XAudio2 and compressed audio.

You can use the Windows Audio Session API (WASAPI) to manage audio streams in your app. Windows Phone 8 supports a subset of the WASAPI interfaces, and other APIs, that you can use on the desktop. Audio Capture and Render APIs for native code for Windows Phone.

Windows Phone 8 & Windows 8

Windows Phone 8 and Windows 8 platform comparison

Common native API

  • DirectX 11.1
  • XAudio2
  • MediaEngine
  • STL
  • CRT
  • WinSock

Common Windows Runtime API

  • Networking
  • Sensors
  • Proximity
  • Storage
  • DataSaver/Connection Manager
  • Location
  • Touch
  • Online Identity
  • Keyboard
  • Launchers & Choosers
  • In-App Purchase
  • Threading
  • Base Types/ Windows.Foundation

+ speech + VOIP + … = Windows Phone Runtime API

Shared .NET Engine

In Windows Phone 8, the .NET Compact Framework has been replaced by CoreCLR, which is the same .NET engine used on Windows 8. Most new devices are now multicore, and the operating system and apps are expected to be faster because of that technology.

Maximize code reuse between Windows Phone 8 and Windows 8

Portable code is any code that can be compiled once and run on Windows Phone 8 and Windows 8. For example, most of the .NET API is portable between both platforms and can be implemented in a Portable Class Library. Common code is code that uses API that’s common to both platforms, but isn’t portable. For example, code that uses the Windows Runtime API that is common between Windows Phone 8 and Windows 8 can be considered common, but it isn’t portable because the code must be compiled for each platform. It also can’t be used in a Portable Class Library.

Note that the Express versions of Visual Studio 2012 don’t include a Portable Class Library project template. The template is available only in Visual Studio 2012 Pro or greater versions.

Windows Runtime APIs aren’t portable and can’t be used in a Portable Class Library. Binary compatibility is not supported. Your code has to be compiled for each platform.

Sharing XAML UI - pewne rozwiązania dla prostych UserControl:

  • szablony XAML można sprowadzić do jednej postaci
  • umieścić wspierany przez obie platformy XAML
  • wykorzystać Add as Link
  • warunkowa kompilacja importowanych przestrzeni nazw

Klasy partial - w drugiej połowie metody zależne od platformy

Dziedziczenie klas - klasy abstrakcyjne mogą być umieszczane w Portable Library

Interfejsy  - implementacje zależne od platformy

XAML controls comparison between Windows Phone 8 and Windows 8


How to test the retail version of your app for Windows Phone 8

When you build your app in Visual Studio, the code is not compiled into a native image, but into a machine-independent Common Intermediate Language (CIL) binary file. (CIL was formerly known as Microsoft Intermediate Language, or MSIL.) This CIL file is what you submit to the Store when you’re ready to sell your app. At that time, the binary file is converted from CIL to optimized Machine Dependent Intermediate Language, or MDIL. Finally, when the user downloads your app to a device, the MDIL file is linked to produce a native image. These steps are repeated in your development environment whenever you deploy your app to a Windows Phone 8 device.

When you deploy and run your app without debugging, you’re testing it as an optimized native image.

To debug your app as an optimized native image: 

Tools –> Options –> Debugging

Clear options:

  • Suppress JIT optimization on module load
  • Enable Just My Code

Windows Phone Application Analysis

App monitoring is supported only for managed apps - you can’t monitor Direct3D apps.

Profiling Direct3D apps for Windows Phone 8

The native code profiler uses the profiling technology built into Visual Studio 2012 and stores its results in standard .vspx files. You can also profile a Windows Phone Runtime Component project that’s referenced from a C# or Visual Basic project with the native code profiler.

Events raised by the Qualcomm graphics driver are enabled by default.

Brak komentarzy: