That’s because .NET Standard 2.0 contains many APIs that require FCU to make them work in the context of the UWP execution environment, specifically AppContainer.

Error DEP3321: To deploy this application, your deployment target should be running Windows Universal Runtime version 10.0.16299.0 or higher. You currently are running version 10.0.15254.158. Please update your OS, or change your deployment target to a device with the appropriate version

• Reduce the app's minimum target version (which will have the effect of removing .Net Standard 2.0 support)
• Switch the deployment target to a non-Mobile device.

A few people have noticed that their Windows Store app projects stopped generating the .appxupload file after upgrading to VisualStudio 2015 Update 1.

Cause
The project is not associated with the Store app.
The StoreAssociation file path is missing from the respective project .csproj file.

Either one of these causes listed above can stop the appxupload file from being generated. This is because msbuild tries to find the Package.StoreAssociation.xml file in the project using the path specified in the respective project .csproj file.

Extract from MSBuild log showing working and failing scenarios:

• Failing scenario:

Notice that ('@(StoreAssociationFile)' != '') was evaluated as ('' != ''). Which means the StoreAssociation file was never found.

Task "Warning" skipped, due to false condition; (('$(_ExtractPlatforms)' == 'true' and '@(StoreAssociationFile)' == '' and '$(AppxBundlePlatforms)' == '')
                         or ('$(_ExtractPlatforms)' == 'true' and '@(StoreAssociationFile)' != '' and '$(_Platforms)' == '')) was evaluated as (('false' == 'true' and '' == '' and 'x86|arm' == '')
                         or ('false' == 'true' and '' != '' and '' == '')).

• Working scenario: 

Notice that ('@(StoreAssociationFile)' != '') was evaluated as ('Package.StoreAssociation.xml' != ''). Which means the StoreAssociation file was found and evaluated correctly.

Task "Warning" skipped, due to false condition; (('$(_ExtractPlatforms)' == 'true' and '@(StoreAssociationFile)' == '' and '$(AppxBundlePlatforms)' == '')
                         or ('$(_ExtractPlatforms)' == 'true' and '@(StoreAssociationFile)' != '' and '$(_Platforms)' == '')) was evaluated as (('false' == 'true' and 'Package.StoreAssociation.xml' == '' and 'x86|arm' == '')
                         or ('false' == 'true' and 'Package.StoreAssociation.xml' != '' and '' == '')).

Solution

To successfully generate the .appxupload file we require the following:

• The project must be associated with the Store app (Project > Associate with Store…) or use packaging wizard, and select ‘Yes’ when asked to associate the app with the store.
• Verify that the store association file is present in your project. The file needs to be present on disk and must be referenced in the appropriate .csproj; that’s where we get the file path.
• The content type of the file must be set to “None” and should look like this in the .csproj file:

          <ItemGroup>
                <None Include="Package.StoreAssociation.xml" />

          </ItemGroup>

• The xml above is for verification purposes. You shouldn't need to enter these values manually since it gets added automatically when you associate the app with the store.
• If using a build script, we recommend that you replace the flags “AppxPackageIsForStore” and “BuildAppxUploadPackageForUap” with the new flag “UapAppxPackageBuildMode=StoreUpload”
• The BuildMode flag will set the other required flags and invoke the right validations (including checking for store association) to produce a .appxupload package.

A network trace of a Windows Store app connecting to a resource residing inside the VPN will show an initial connection that goes out through the external network adapter, trying to get to the internal address but eventually failing.  After the failure, there is a retry which then goes through the VPN and succeeds.  The wait for failover is the cause of the latency, but the real problem is that it tries to connect via the external adapter. This issue only occurs with Windows Store apps.

The root cause of the problem is that devices which support Connected Standby try to use the AOAC-enabled adapter first for Store apps, in every case.  A machine which is presently using AOAC and VPN will have at least two listed network adapters - at least one that performs the actual network connectivity operations (sending packets back and forth over the wire/wifi), and the VPN connection to the remote destination.  There may be others, and they may also be negatively affected by this issue. 

The problem is that the Store app always tries to first connect to a resource inside the VPN via the AOAC adapter, which will fail.  Only after the failure occurs will the retry happen.  In a default-configured network, the failure takes approximately 21 seconds: 

• The first attempt at SYN, then timeout after 3 seconds. 
• The second attempt, then timeout after 6 seconds. 
• The third and final attempt, timeout at 12 seconds.  3+6+12 = 21 seconds until the connection is aborted.
• The VPN adapter is then tried, and it takes that time as well to get connected.

An interesting thing about AOAC is that it does not work if HyperV is enabled on the machine, and that's how we can resolve this problem. Unfortunately, because there is no way to explicitly disable AOAC on a network adapter, you can enable HyperV which will disable AOAC and prevent the problem from occurring.  More information here: https://answers.microsoft.com/en-us/surface/wiki/surfpro3-surfnetwork/work-around-for-surface-pro-3-issue-where/bd7c8bde-439b-45d6-8d9d-2776913e45e9

Steps to turn on Hyper-V:

1. Open an administrative command prompt and type:

bcdedit /set hypervisorlaunchtype auto

2.  Restart your device

After restarting, Hyper-V will again be active (and Connected Standby will no longer function). 

We've seen this issue reported with Surface Pro 3 since Connected Standby is default on that device.  You also may find that this issue goes away after installing Visual Studio 2013.  That's because Phone emulators are installed into HyperV, at which time HyperV is enabled, which causes AOAC to be disabled. Also, there is an active bug on this issue with the Windows Networking development team at the time of this blog post.  We expect that this should be resolved in Windows 10.

Don’t forget to follow the Windows Store Developer Solutions team on Twitter @wsdevsol. Comments are welcome, both below and on twitter.

I was working in our MSDN Forums and found a post from a user trying to detect shake events for Windows Phone 8.1.  I quickly realized this event is not built into the SDK, so I set out to create a helper class to raise a Shake event for Windows Phone 8.1.

The Accelerometer class in Windows Phone 8.1 has an event you can subscribe to that will be raised each time new data is available.  This event is raised quite  frequently to provide near real time data from the Accelerometer.  I chose to poll for Accelerometer data because reading data in real time is not needed to detect a Shake event.  The interval can be changed, but after trial and error I settled on  200ms.  The class is written so you can configure the polling Interval, however  I would not go greater than 200ms for the interval.  The class also exposes a Threshold property which can be modified to configure the type of Shake motion needed to raise the event.

The below code is the class I implemented to detect and Raise Shake events.

using System;
using System.Collections.Generic;
using System.Diagnostics;
using System.Linq;
using System.Text;
using System.Threading;
using System.Threading.Tasks;
using Windows.Devices.Sensors;

namespace PhoneShake
{
    public class ShakeDetector
    {
        public event EventHandler Shaken;
        Timer _timer;
        protected static ShakeDetector _instance = new ShakeDetector();
        double _lastX;
        double _lastY;
        double _lastZ;
        double _currentX;
        double _currentY;
        double _currentZ;
        
        bool _bFirstUpdate;
        bool _bShake;

        protected void OnShaken(EventArgs e)
        {

            if (Shaken != null)
            {
                Shaken(this, e);
            }
        }

        protected ShakeDetector()
        {
            Interval = 200;
            Threshold = 3.00f;
            _bShake = false;
            _bFirstUpdate = true;
        }

        public static ShakeDetector Instance
        {
            get { return _instance; }
        }

        /// <summary>
        /// Interval that we will use for shake.  Should probably not be > 200ms
        /// </summary>
        public int Interval { get; set; }
        /// <summary>
        /// Force threshold to trigger Shaken event off of 
        /// </summary>
        public double Threshold { get; set; }

        /// <summary>
        /// Called to start monitoring for Shake Events.  Attach an event handler to shaken event before calling
        /// </summary>
        public void Start()
        {
            //  Set up timer for interval
            _timer = new Timer(IntervalTimer_Task, null, 0, Interval);
   
            
        }

        /// <summary>
        /// Called to stop monitoring and Firing Shake Events.
        /// </summary>
        public void Stop()
        {
            //  Stop the timer
            _timer.Dispose();
            _timer = null;

            _bFirstUpdate = true;
        }

        private void UpdateAccelerometerValues(double x, double y, double z)
        {
            if(_bFirstUpdate)
            {
                _lastX = x;
                _lastY = y;
                _lastZ = z;
                _bFirstUpdate = false;
            }
            else
            {
                _lastX = _currentX;
                _lastY = _currentY;
                _lastZ = _currentZ;
            }

            _currentX = x;
            _currentY = y;
            _currentZ = z;

        }

        private bool CheckAccelerationChanged()
        {
            double xChange = Math.Abs(_lastX - _currentX);
            double yChange = Math.Abs(_lastY - _currentY);
            double zChange = Math.Abs(_lastZ - _currentZ);

            // Debug.WriteLine("Accel: {0}", xChange+yChange+zChange);

            if (xChange + yChange + zChange > Threshold)
                return true;
            
            return false;

        }

        private void IntervalTimer_Task(object state)
        {
            AccelerometerReading current = Accelerometer.GetDefault().GetCurrentReading();         
            DateTimeOffset now = current.Timestamp;

            UpdateAccelerometerValues(current.AccelerationX, current.AccelerationY, current.AccelerationZ);

            //   Check and raise Shake
            if ((!_bShake) && CheckAccelerationChanged())
            {                                     
                _bShake = true;
            }
            else if ((_bShake) && CheckAccelerationChanged())
            {
                _bFirstUpdate = true;  //  Reset Detection
                OnShaken(new EventArgs());
            }
            else if ((_bShake) && (!CheckAccelerationChanged()))
            {                           
                _bShake = false;
            }

        }

    }
}

The following code is a simple XAML Page that starts/stops the ShakeDetector, and logs the Date/Time of the event to the UI.

Copy Code:

<Page
    x:Class="PhoneShake.MainPage"
    xmlns="https://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="https://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:local="using:PhoneShake"
    xmlns:d="https://schemas.microsoft.com/expression/blend/2008"
    xmlns:mc="https://schemas.openxmlformats.org/markup-compatibility/2006"
    mc:Ignorable="d"
    Background="{ThemeResource ApplicationPageBackgroundThemeBrush}">

    <StackPanel>
        <Button x:Name="btnStart" Content="Start" Click="btnStart_Click"/>
        <Button x:Name="btnStop" Content="Stop" Click="btnStop_Click"/>
        <TextBlock x:Name="txtEvent" />
    </StackPanel>
</Page>

Copy Code:

using System;
using System.Collections.Generic;
using System.Diagnostics;
using System.IO;
using System.Linq;
using System.Runtime.InteropServices.WindowsRuntime;
using Windows.Foundation;
using Windows.Foundation.Collections;
using Windows.UI.Core;
using Windows.UI.Xaml;
using Windows.UI.Xaml.Controls;
using Windows.UI.Xaml.Controls.Primitives;
using Windows.UI.Xaml.Data;
using Windows.UI.Xaml.Input;
using Windows.UI.Xaml.Media;
using Windows.UI.Xaml.Navigation;

// The Blank Page item template is documented at https://go.microsoft.com/fwlink/?LinkId=391641

namespace PhoneShake
{
    /// <summary>
    /// An empty page that can be used on its own or navigated to within a Frame.
    /// </summary>
    public sealed partial class MainPage : Page
    {
        public MainPage()
        {
            this.InitializeComponent();

            this.NavigationCacheMode = NavigationCacheMode.Required;
            btnStop.IsEnabled = false;
        }

        /// <summary>
        /// Invoked when this page is about to be displayed in a Frame.
        /// </summary>
        /// <param name="e">Event data that describes how this page was reached.
        /// This parameter is typically used to configure the page.</param>
        protected override void OnNavigatedTo(NavigationEventArgs e)
        {
            // TODO: Prepare page for display here.

            // TODO: If your application contains multiple pages, ensure that you are
            // handling the hardware Back button by registering for the
            // Windows.Phone.UI.Input.HardwareButtons.BackPressed event.
            // If you are using the NavigationHelper provided by some templates,
            // this event is handled for you.
        }

        private void btnStart_Click(object sender, RoutedEventArgs e)
        {
            ShakeDetector.Instance.Start();
            ShakeDetector.Instance.Shaken += Instance_Shaken;
            btnStop.IsEnabled = true;
            btnStart.IsEnabled = false;
        }

        void Instance_Shaken(object sender, EventArgs e)
        {
            Debug.WriteLine("Device Shook");
            Dispatcher.RunAsync(CoreDispatcherPriority.Normal, () =>
            {
                txtEvent.Text = string.Format("Shake Detected at {0}", DateTime.UtcNow);
            });
            
        }

        private void btnStop_Click(object sender, RoutedEventArgs e)
        {
            ShakeDetector.Instance.Stop();
            ShakeDetector.Instance.Shaken -= Instance_Shaken;
            btnStop.IsEnabled = false;
            btnStart.IsEnabled = true;
        }
    }
}

I hope this article helps those developers writing for Windows Phone 8.1 to use the Shake gesture for something fun.  Until next time have fun coding!

Don’t forget to follow the Windows Store Developer Solutions team on Twitter @wsdevsol. Comments are welcome, both below and on twitter.

- Bret Bentzinger(Microsoft) @awehellyeah

Use this with care and thought!

Happy users give good reviews. Irritated users give bad ones. An occasional prompt after the user has successfully completed a task will likely get better reviews than frequent prompts which get in the way of getting things done (I admit it: I've filed bad reviews just to make the darn things go away).

Consider prompting after the user beats a friend's high score, completes a lesson with a good grade, or meets a fitness goal.

Avoid prompting when the user does poorly on a game, or initially launches the app: the user opened the app to use it and may be irritated to get pushed off elsewhere.

There isn't a good way to tell if the user actually filed the review. I'd stop asking after sending the user to the review page once.

    await Windows.System.Launcher.LaunchUriAsync(new Uri("ms-windows-store:reviewapp));

For Windows 8.1 (see Linking to your app in the Promote Windows Store apps docs  )

    await Windows.System.Launcher.LaunchUriAsync(new Uri("ms-windows-store:review?PFN=" + packageFamilyName));

We'll update this entry with Windows 10 information when the unified Windows Dev Center is fully up and running.

Sometimes though, you want your app to be able to control where the audio is getting routed. That is where the AudioRoutingManager comes in handy. The AudioRoutingManager allows you to specify one of the supported audio endpoints. There are usually four possible endpoints but not all of them may be available. They are: None, earpiece,  speakerphone and Bluetooth. For more detail on how these are related check out Matthew van Eerde’s blog on the subject.

There are two keys to successfully using the AudioRoutingManger.

Key #1) You need to add the ID_CAP_VOIP capability to your app.

You can do this using the manifest editor for Windows Phone Silverlight apps but it’s not quite as easy to do this for Windows Phone 8.1 Runtime apps.

Here’s what you need to do for your Windows Phone 8.1 Runtime app:

1. Create a new XML file and name it WindowsPhoneReservedAppInfo.xml
2. Add the new file to the root of your Windows Phone 8.1 Runtime project in Visual Studio
   
   
3. Add the following XML to the file:

 1: <?xml version="1.0" encoding="utf-8"?>

 2: <WindowsPhoneReservedAppInfo xmlns="https://schemas.microsoft.com/phone/2013/windowsphonereservedappinfo">

 3:   <SoftwareCapabilities>

 4:     <SoftwareCapability Id="ID_CAP_VOIP" />

 5:   </SoftwareCapabilities>

 6: </WindowsPhoneReservedAppInfo>

Key #2) You need to make sure the audio is streaming before you change the endpoint.

This means that if you re using an audio technology like WASAPI you need to call:

IAudioClient::Start

Before you call:

AudioRoutingManager.SetAudioEndpoint

If the stream is not started and you call SetAudioEndpoint you will get an error and the endpoint won’t change. Of course this does have the potential for the audio to come out of the wrong endpoint a few milliseconds before the endpoint gets switched. Unfortunately there is no way around this other than to roll silence before switching the endpoint.

Other things to consider:

• When you specify the ID_CAP_VOIP in your app the default endpoint may change. For most audio apps the external speaker will be the default unless Bluetooth is available. When you have ID_CAP_VOIP set then the earphone becomes the default endpoint unless bluethooth is available.
• The AudioRoutingManager.SetAudioEndpoint API doesn’t work in the emulator. Basically it is a “no-op” but luckily it doesn’t appear to cause an error.
• If you are getting the following exception: HRESULT: 0x80070005 (E_ACCESSDENIED) when calling SetAudioEndpoint  you don’t have your WindowsPhoneReservedAppInfo.xml file setup correctly or the file is not getting parsed properly at runtime. Make sure the file is flagged as “Content” with an item type of XML.
  
  

I hope this helps,

James

Follow the Windows Store Developer Solutions team on Twitter @wsdevsol. Comments are welcome, both below and on twitter.

Recently I was writing a simple HttpClient to interface with a REST API.  Typically I just pass the response string to a JSON converter and get my object out the other end.  However, in my case I was getting the following error from my converter:

Newtonsoft.Json.JsonReaderException was caught
  _HResult=-2146233088
  _message=Unexpected character encountered while parsing value:  . Path '', line 0, position 0.
  HResult=-2146233088
  IsTransient=false
  Message=Unexpected character encountered while parsing value:  . Path '', line 0, position 0.
  Source=Newtonsoft.Json
  LineNumber=0
  LinePosition=0
  Path=""
  StackTrace:
       at Newtonsoft.Json.JsonTextReader.ParseValue()
       at Newtonsoft.Json.JsonTextReader.ReadInternal()
       at Newtonsoft.Json.JsonTextReader.Read()
       at Newtonsoft.Json.Serialization.JsonSerializerInternalReader.ReadForType(JsonReader reader, JsonContract contract, Boolean hasConverter)
       at Newtonsoft.Json.Serialization.JsonSerializerInternalReader.Deserialize(JsonReader reader, Type objectType, Boolean checkAdditionalContent)
       at Newtonsoft.Json.JsonSerializer.DeserializeInternal(JsonReader reader, Type objectType)
       at Newtonsoft.Json.JsonSerializer.Deserialize(JsonReader reader, Type objectType)
       at Newtonsoft.Json.JsonConvert.DeserializeObject(String value, Type type, JsonSerializerSettings settings)
       at Newtonsoft.Json.JsonConvert.DeserializeObject[T](String value, JsonSerializerSettings settings)
       at Newtonsoft.Json.JsonConvert.DeserializeObject[T](String value)
       at WSDSForumAPI.StackOverflow.<GetPostsForTag>d__0.MoveNext() 
  InnerException:

When I looked into the issue the string being passed to the converter looked like this:

"�\b\0\0\0\0\0\0��ko�6��\n��ɌD….."

I attached fiddler, and then realized that my response content was compressed, as the response had the following header:

Content-Encoding: gzip

So I set out to figure out how to decompress the content.   It turns out this is fairly simple.   Just create a HttpClientHandler and set its AutomaticDecompression to the type of compression used in the response.  The following code snippet is what I ended up with for my scenario:

Copy Code:

HttpClientHandler handler = new HttpClientHandler(); handler.AutomaticDecompression = System.Net.DecompressionMethods.GZip; _client = new HttpClient(handler);

That is it for this blog post.  Simple and to the point.  Until next time have fun coding!

Don’t forget to follow the Windows Store Developer Solutions team on Twitter @wsdevsol. Comments are welcome, both below and on twitter.

- Bret Bentzinger(Microsoft) @awehellyeah

This blog discusses the basic problem most customers report.

OK, so here we go….

After the device has been setup with the initial HTTP request/response message exchange, the SyncML session starts with a HTTP request to the server which includes the basic device information.

In response to the server’s message, if the server expects that the client should continue further communication (such as the response of a command status), the server MUST ensure that the HTTP response – SyncML XML content is sent as a single line without extra line breaks or spaces in between the XML document.

If your server response contains new lines and/or extra spaces between the XML tags, we have noticed that the MDM Agent will just stop without issuing any further HTTP requests. At that point, the server does not quite know why there was no further communication from the client.

For example if your server was to send the following SyncML (I have taken out the actual sections and kept it short for brevity):

<SyncML xmlns="SYNCML:SYNCML1.2"> 

  <SyncHdr> 

    <VerDTD>1.2</VerDTD> 

    <VerProto>DM/1.2</VerProto> 

    ...other elements... 

  </SyncHdr> 

  <SyncBody> 

    <Status> 

      ...other elements...

    </Status>

    <Replace>

      ...other elements...

    </Replace>

    <Get>

      ...other elements...

    </Get>

    <Final/>

  </SyncBody>

</SyncML> 

You will notice that although the SyncML response looks syntactically correct and is visually very appealing, the XML parser tries to parse the above XML but actually fails with a XML parsing error! When the parsing error happens, the MDM Client just fails silently and the parsing error does not get relayed back to the server in the form of a HTTP request.

To resolve the problem and avoid the headaches of trying to comprehend why the MDM Agent does not communicate back to your server, you must ensure that your HTTP server response MUST be sent back as a single line without any extra spaces or new lines between the XML tags. Taking the above as an example, your “XML parser friendly response” MUST look like this:

<SyncML xmlns="SYNCML:SYNCML1.2"><SyncHdr><VerDTD>1.2</VerDTD><VerProto>DM/1.2</VerProto>...other elements...</SyncHdr><SyncBody><Status>...other elements...</Status><Replace>...other elements...</Replace><Get>...other elements...</Get><Final/></SyncBody></SyncML>

Hopefully this blog helps get you over the very first hurdle in the MDM implementation puzzle – which looks quite daunting at first, but then it’s quite simple…or not :)

Until your next MDM issue, wishing you good luck!

- Prashant H Phadke

For security reasons, there are some activities on Facebook (like sending invites for games or applications to a friend) that can’t be performed directly by calling some APIs, but they need to be managed with a web view that is offered by Facebook. The purpose of this approach is to avoid, for example, that an application could send automatically hundreds or thousands of invites without the explicit permission of the user. However, the developer has access to some tools to properly generate the web view and to receive the information about the outcome of the operation made by the user (like the list of friends that have been invited).

In this post we’re going to see how to integrate Facebook invites in a Universal Windows app, by reusing the knowledge we’ve acquired in the previous post about integrating the Facebook authentication mechanism.

Register the application on the Facebook developers’ portal

The first step, before writing some code, is to properly configure the Facebook application which we have created in the previous post and that it’s connected to the Windows application. It’s important to remember that every application (no matter if it’s a website, a mobile app or a desktop app) that needs to interact with the Facebook APIs needs to be properly registered in the developers’ portal provided by the social network. In this post we’re going to reuse the same application we’ve created in the previous post to support the authentication. In addition to the configuration we already did, we need to perform a few additional steps:. The trick to to integrate Facebook invites, in fact, is to treat the application like if it’s a web game, which has its own Facebook canvas (which is the area where Facebook renders the web application inside its pages). Every Facebook canvas is associated to a unique URL, which is invoked after that the procedure to send invites is completed: thanks to this URL, we’ll be able to determine the status of the operation and to retrieve the list of invited friends.

To configure the Facebook canvas we need to click, in the Settings section of our Facebook app, the Add platform button and add a new application, which type is Facebook Canvas. The only setting we need to setup is called Secure Canvas URL, which is the address that is invoked by Facebook when the operation is completed. We can use any custom URL; the only requirement is that it has to use the HTTPS protocol, like in the following sample.

Now we are ready to write some code and to integrate invites in the Windows app.

Display the web view

To show the code that is needed to display the invites’ view we’re going to reuse the project we’ve created in the previous post. I’ll take for granted that you’re already familiar with the FacebookClient and WebAuthenticationBroker classes and that you’ve already used them to perform the authentication and to retrieve the access token, which is needed to perform any further interaction with the Graph APIs.

For our purposes we’re going to use again the FacebookClient class, which is included in the Facebook SDK that you can install in your project by using NuGet. It’s important to remember, at this point, that, in a Universal Windows app, the shared project is just a “placeholder” for all the files that are needed by the application and not a real class library. Consequently, you’ll have to add the Facebook SDK both to the Windows and Windows Phone projects.

The FacebookClient class offers a method called GetDialogUrl() which, given as parameter the kind of dialog we want to display, returns the URL we need to display inside a web view. Since we are in a Universal Windows app, we’re going to use the WebView control to achieve this goal.

The following sample shows how to use the GetDialogUrl() method:

private void OnInviteFriendsClicked(object sender, RoutedEventArgs e)
{
    FacebookClient client = new FacebookClient(AccessToken);
    dynamic parameters = new ExpandoObject();
    parameters.app_id = ClientId;
    parameters.message = "Invite your friends";
    parameters.title = "Invite friends";
    parameters.redirect_uri = "https://wp.qmatteoq.com/";

    Uri dialogUrl = client.GetDialogUrl("apprequests", parameters);
    RequestView.Visibility = Visibility.Visible;
    RequestView.Navigate(dialogUrl);
}

The parameters to pass to the GetDialogUrl() method are managed with a dynamic object, which is defined with the following properties:

• app_id is the identifier of the Facebook application, which you can retrieve from the Facebook developers’ portal and that we have already used, in the previous post, to perform the login. You can find it in the Settings page of the application; the field is called App ID.
• message: it’s the message that explains to the user the purpose of the invites and it’s displayed in the web view.
• title: it’s the title of the web view.
• redirect_uri: it’s the Secure Canvas URL, which we have specified in the beginning of the post.

After we’ve properly configured the parameters, we can pass them to the GetDialogUrl() method, together with the kind of dialog we want do display. In this case, since we’re working with invites, we need to use the apprequests identifier. In return, we receive the URL of the view to display in a WebView control, which has been added to the page of our application, like in the following sample:

<Grid>
    <WebView x:Name="RequestView" Visibility="Collapsed" Width="400" Height="800" NavigationCompleted="RequestView_OnNavigationCompleted"/>
    <StackPanel Margin="12, 20, 0, 0" x:Name="AppContent">
    <!-- the content of the page -->
    </StackPanel>
</Grid>

When we call the GetDialogUrl() method we also take care of displaying the WebView (which, by default, is hidden), by setting the Visibility property to Visible. Then, we call the Navigate() method of the WebView control, passing as parameter the URL returned by the GetDialogUrl() method. The application will display a view similar to the following one:

Process the invitations

In the web view the user will have the chance to select one of more his friends. After pressing the Send button, the operation will be completed and the invites will be sent. From the Facebook point of view, the operation is completed; however, as developers, we probably want to know more details about the outcome, like the list of friends that have been invited to use the application. We can achieve this goal by subscribing to the Navigation_Completed event of the WebView control, which is triggered when a web page is fully loaded.

After that the user has pressed the Send button, Facebook invokes the URL that we have defined as Secure Canvas URL in the app configuration. It’s the URL we need to intercept in the Navigation_Completed event to understand when the operation is completed. In this scenario, in fact, the URL will contain the list of all the friends that have been invited. Let’s take a look at the following sample code:

private async void RequestView_OnNavigationCompleted(WebView sender, WebViewNavigationCompletedEventArgs args)
{
    if (args.Uri.DnsSafeHost == "wp.qmatteoq.com")
    {
        sender.Visibility = Visibility.Collapsed;
        AppContent.Visibility = Visibility.Visible;

        FacebookClient client = new FacebookClient(AccessToken);
        dynamic result = client.ParseDialogCallbackUrl(args.Uri);

        if (result.error_code == null)
        {
            var items = (IDictionary<string, object>) result;

            ObservableCollection<FacebookUser> invitedFriends = new ObservableCollection<FacebookUser>();

            foreach (KeyValuePair<string, object> value in items)
            {
                if (value.Key != "request")
                {
                    string query = string.Format("/{0}", value.Value);
                    dynamic user = await client.GetTaskAsync(query);
                    FacebookUser facebookUser = new FacebookUser();
                    facebookUser.FullName = user.name;
                    invitedFriends.Add(facebookUser);
                }
            }

            Friends.Visibility = Visibility.Visible;
            FriendsHeader.Visibility = Visibility.Visible;
            Friends.ItemsSource = invitedFriends;
        }
        else
        {
            MessageDialog dialog = new MessageDialog("The user has canceled the operation");
            await dialog.ShowAsync();
        }
    }
}

If the Uri of the page loaded by the WebView control is the same we have defined in the Facebook developers’ portal as Canvas Secure Url, it means that the operation is completed and we need to parse the result. The parsing procedure is simplified by a method offered by the FacebookClient class called ParseDialogCallbackUrl(), which requires as input parameter the full Uri of the page and returns a dynamic object (we use, again, the dynamic keyword to store the result). The first step is to check if the operation has completed successfully. In this case, the error_code property of the result will be empty, otherwise, it means that the operation has been cancelled by the user (the web view, in fact, offers also a Cancel button, which can be used to abort the operation). If it’s not the case, we can move on and retrieve the list of invited users. We are able, in fact, to manage the result as a Dictionary<string, object> collection, which contains:

• As first value, an item identified by the request key, which contains the unique identifier of the request.
• A series of numeric values: each of it is the unique Facebook identifier of the friends invited by the user.

In the sample code we process all the items of the collection with a foreach iterator; we discard the item identified by the request key (since we don’t need it for our purposes) and we use only the ones with the Facebook identifier. For all the friends that the user have invited, we issue a request to the Graph APIs to retrieve the friend’s profile. We use the GetTaskAsync() method of the FacebookClient class, passing as parameter the Graph API’s path (which is simply the symbol / followed by the identifier of the user, like /123456789).

In the end, it’s up to us to decide what we want to do with this information. In the previous sample, we create a new FacebookUser object (which is a custom class) for each friend and we store, in the FullName property, the name of the friend that we have retrieved using the Graph API. Here is a sample definition of the FacebookUser class:

public class FacebookUser
{
    public string FullName { get; set; }
}

All these objects are included in a collection called invitedFriends, which type is ObservableCollection<FacebookUser>. This way, by using a ListView control, we can display to the user the list of the names of all the friends he has invited in the web view. The following code shows the simple template used for the ListView control:

<ListView x:Name="Friends" Margin="0, 20, 0, 0" Visibility="Collapsed">
    <ListView.ItemTemplate>
        <DataTemplate>
            <StackPanel>
                <TextBlock Text="{Binding Path=FullName}" Style="{StaticResource BodyTextBlockStyle}" />
            </StackPanel>
        </DataTemplate>
    </ListView.ItemTemplate>
</ListView>

Wrapping up

In this post we have seen how to integrate Facebook invites in our Universal Windows app. You can download the sample code we’ve seen in this post from the following repository on GitHub: https://github.com/qmatteoq/FacebookSample-Universal. It’s important to remember that, before using the sample, you’ll have to change the various Facebook parameters (like the App Id or the Canvas Secure URL) with the ones you have configured for your application in the Facebook developers’ portal.

Follow the Windows Store Developer Solutions team on Twitter @wsdevsol. Comments are welcome, both below and on twitter