Windows Store Developer Solutions

Dealing with Documents: How (not) to use the documentsLibrary capability in Windows Store apps

Rob Caplan — Thu, 09 May 2013 19:12:49 GMT

Many people posting in the forums express confusion over the documentsLibrary capability's "Special Use" categorization.

This capability is highly restricted and not intended for general use, and apps which try to use it generally will fail certification.

While the requirements that business accounts are required to declare the Special Use capabilities and that only specifically declared file types can be used are what usually catch the eye, the limitation most apps run into is that "the only acceptable use for the documentsLibrary capability is to support the opening of embedded content within another document". This capability is not intended to allow apps to use the documents library as general storage or to allow programmatic browsing of the library. We strongly recommend you avoid using this capability.

What does an app do if it needs to store user-facing documents?

The good news is that most apps will be better off without the documentsLibrary. Instead, allow the user the flexibility to choose which folder to use. The first time a document needs to be saved pop up a FolderPicker to let the user choose where to place it. Remember the location in the FutureAccessList so the user only has to choose the first time.

Users can choose the Documents folder if they want. Users who prefer other locations can choose them. For example: I keep most of my documents in my SkyDrive folders!

For more information on the FolderPicker see Quickstart: Accessing files with file pickers and the File picker sample. For more information about caching the file access see How to track recently used files and folders and the File access sample.

--Rob

Follow the Windows Store Developer Solutions team on Twitter @wsdevsol.

Your Windows Phone 7/8 application tests fine, but fails after publishing to Marketplace or after private app distribution

Mark Chamberlain - MSFT — Wed, 08 May 2013 14:53:00 GMT

So, you tested your application using the Windows Phone SDK tools. Everything ran flawlessly. You publish your app. You download your published app. Users download your app and report that the app crashes during its splash screen on start-up. What to do?

This scenario may occur if:

the app was published to Marketplace, but the app is failing on a phone model that the marketplace testers did not use when validating your app.
you have deployed your own private Company app distribution, and therefore the task of testing the app after it has been signed and published is up to you.

Here is a checklist to help you identify the root cause and solve it.

Make sure that when you built your solution, you did so in Release mode, i.e. not Debug mode. In Visual Studio, check this using BUILD->Configuration Manager…
Make sure you built your solution targeting the Device not the Emulator. The Emulator compiles to the X86 platform while the device compiles to ARM.
Make sure the XAP file contains all the DLLs needed. For example if using the Windows Phone Toolkit or other third party libraries, make sure the references to those DLLs indicate CopyLocal=True.
In Visual Studio, under the PROJECT menu, choose Open Store Test Kit. Execute the automated and manual tests. Make any necessary corrections. More information is available here.
Your XAP file can be found in the Bin/Release folder of your project. Inspect its contents by renaming it from .XAP to .ZIP. Then double click on the newly named file to inspect its contents. You also can inspect it by using a third party tool such as WinZip.
Also while inspecting the XAP, make sure all the DLLs that are present are known, expected DLLs, and those DLLs have been compiled specifically for use with your particular version of Windows Phone app and build environment. You might need to launch a clean build to ensure there are no stray DLLs.
In the Dashboard, inspect the list of Capabilities for your published app, and ensure that Marketplace didn’t remove any. This problem can occur owing to the various ways Marketplace audits the app in order to identify what capabilities are needed. The solution depends on which capability is missing. As a Windows Phone 7 example, for MediaElement to be detected, its name needs to exist in the xaml itself (x:name). Find more information about Capabilities here.
Make sure all debug APIs such as ScheduledActionService.LaunchForTest are not included in your release build.
See if the failure is specific to a particular phone model or manufacturer. For example, determine if the problem is related to the amount of memory available in the phone.
Before Marketplace deploys the app, its ingestion process changes the ProductID in the WMAppManifest.xml. Perhaps your app has some dependency on the ProductID that existed beforehand. An example is if your app has a hard copy of the old ProductID in a string constant. Your app may need to explicitly open WMAppManifest.xml and then inspect the ProductID in order to get the correct value.
You can submit to Marketplace an “instrumented” version of their app as a private Beta app, which is not distributed to the public. This version could have logging etc. to make it easier to analyze; particularly if the failure is occurring after the main page has successfully launched.

You should be able to download the call stacks for the crash, by reviewing your App Hub Dashboard crash dump logs. However, sometimes the log results are of limited value. Follow the procedure below in order to enable crash reporting.

For the phone being tested, go to settings->feedback and set it to ON.
Make sure the phone has Wi-Fi access.
Launch the app.
Inspect the crash dumps in your App Hub dashboard.

Hope this helps!

Follow the Windows Store Developer Solutions team on Twitter @wsdevsol

WebView Magic Tricks: Highlight a Search Term

Matt Small — Tue, 07 May 2013 17:52:00 GMT

WebView continues to be a hot topic in the Windows Store Apps forums. The ability to bring in web content and manipulate it as you wish is a strong desire for many developers. With this blog post, I am starting a series of short videos which demonstrates some simple techniques to make the WebView content more interesting.

Today's topic is how to highlight search terms in any page which you load into a WebView by injecting and invoking custom-written JavaScript from your C# application. Source code is attached to this post. Enjoy!

If you enjoyed this video, please check out our other videos (more coming soon!) at our YouTube channel and be sure to follow us on Twitter @wsdevsol

Windows Phone 8: Steps to acquire an Enterprise Mobile Code Signing Certificate required to sign LOB or company apps

RashmiA-MSFT — Wed, 01 May 2013 20:22:00 GMT

If you are developing a Windows Phone 8 LOB application to distribute to the users in your company, then the company must acquire an enterprise mobile code signing certificate from Symantec. The company needs this certificate to generate an Application Enrollment Token (AET) and sign company apps.

Here are step-by-step instructions to acquire an enterprise certificate from Symantec for use on Windows Phone 8.

Step 1: Open a Company account and obtain its Publisher ID

Enterprise certificates can be acquired for any Dev Center account of type Company (the account can’t be an Individual or Student account). As part of establishing the account, the company is validated by Symantec. For
more information about registering for a Dev Center account, see Registration info .

Step 2: Identify the account

Open Enterprise Mobile Code Signing Certificate Web site in the browser.

Enter the Publisher ID obtained in Step 1, and the associated email address used for the Dev Center account.

Note: You have to complete Step 2 to Step 6 on the same computer.

Step 3: Provide order details and billing information

Once the account is identified, you then enter your billing information and accept the agreements and terms for both Symantec and Microsoft.

Step 4: Corporate Approval

Once the order is submitted, the Corporate Approver receives an email with a link to this site to approve or reject the certificate request.

Step 5: Certificate pick up

After the corporate approver has approved the request, the cert is generated and the submitter receives an email to pick up the certificate.

Note that before installing the certificate, the CA and Root certificates must be installed in the appropriate certificate store. See the knowledge base link below for the certificate store information..The process to do that is referenced in the email to the submitter, and the certs are attached to that email.

How to install the Windows® Phone Private Enterprise Root and Intermediate certificates

The below screenshots shows the certificate installation process.

Step 6: Find certificate in the Cert Store

The Enterprise Mobile code signing certificate will be installed in the Personal certificate store on your computer.

You can now export the certificate in PFX format and use this PFX file to generate an application enrollment token (AET) and sign company apps.

More information about signing and distributing company apps can be found in the below documentation:

Company app distribution for Windows Phone

“Follow us on Twitter @wsdevsol”

Incremental Loading of Data using Windows Azure Mobile Services

Jeff Sanders — Thu, 04 Apr 2013 15:47:00 GMT

When your data is in the cloud you should only download information that a user is actually looking at. In the case where you have thousands of items and you want to give the ability to scroll through them you should only fetch the data that the user will be viewing (yes, I know that is a horrible UI design – another blog opportunity). Chances are they will not make it through the whole list.

Our XAML controls support being backed by an Incremental loading scheme. I will show how to leverage this by modifying one of our existing samples and use Windows Azure Mobile Services as a backend (because it is really cool)!

Prep work:

Download the sample we will modify: XAML data binding sample (we will be modifying the C# example).
Get familiar with Windows Azure Mobile Services if you have not already and go through the Get started with data tutorial (Free Trial link is at the bottom of the page) in which you will install the Mobile Services SDK

Add a new Windows Azure Mobile Service for the project and configure it

Create a new Mobile Service
Choose the ‘Connect an existing Windows Store app’ option from the dashboard of your new project

Hit the ‘Create Item table’ button and we will use this for our data (note: this is a different table and will be a different schema than the TodoItem table that you would use for the ‘Create a new Windows Store app’ option).
Keep this page up (or return to it later) so we can copy the code listed into our project. You will cut and paste the information from step two here in the following instructions

Modify the existing sample to use our new Windows Azure Mobile Service

Build and run the existing sample to ensure there are no problems, try ‘Scenario 8’ as this is the section we will modify.
Follow the instructions from the Mobile Service portal to ‘Connect an existing Windows Store app’ from Step 2.

In your Visual Studio project, add a reference to the "Windows Azure Mobile Services Client" extension (did you install the SDK like I told you?).

Add "using Microsoft.WindowsAzure.MobileServices;", to your App.xaml.cs file, then copy and paste the following code into your App.xaml.cs file inside the App from the portal page you left open above into the class definition like this:

Build to check for any errors

Modify Scenario 8 to use our new Mobile Service

‘Scenario 8’ already uses an incremental loading class so we will modify that scenario and show how easy it is to use Cloud Storage instead of static data. The Mobile Services portal has some instructions on how to connect and existing app to the data.

Here is where we will deviate slightly from the instructions in your Mobile Service portal. We created a table called ‘Item’ but the columns do not match what we want for this sample code. Open Scenario8.xaml and look at the binding for the list view. You will see the data is bound to ‘Name’ and ‘Organization’. We could use the ‘Text’ field in our Mobile Service ‘Item’ table and remap it to either of these fields in the XAML and create a new column dynamically, but lets create and modify a new table instead.

Back to your Mobile Service portal.
Click on your newly created Mobile Service and hit the DATA tab. You should see the ‘Item’ table we created earlier.
Delete the Item table by hitting the DELETE icon at the bottom of the page
Then hit the CREATE icon right next to the DELETE icon and create a new table called ‘Employee’

Click on the Employee table after you have created it and you will see it has only one column which is the id column (we will add data with the required columns later).

Now lets modify some code we need to attach to our data source

There are three files we will be modifying. The first file is Scenario8.xaml.cs.

Open this file and find the constructor for GeneratorIncrementalLoadingClass<Employee>. This constructor takes a generator function that pre-populates data. We will be using a data source so lets remove all that garbage! You will see below where I added the new constructor that we will define and commented out the old one. Also, mark the function async and add and await for a new function we will add called initAsync():

Now we will modify the logic for the incremental loading behavior we desire and add the new constructor and initAsync method. This file: GeneratorIncrementalLoadingClass.cs implements the interface we are using and has the old constructor. Open that file and make the following changes:

Remove the old constructor and code public GeneratorIncrementalLoadingClass(uint maxCount, Func<int, T> generator)
Add the new constructor public GeneratorIncrementalLoadingClass(){ }
Remove Func<int, T> _generator; (it is in the State region at the bottom of the file)
In LoadMoreItemsOverrideAsync, Delete the code under ’//Wait for work’ and ‘//This code simply generates’.
Now your code should look like this (we will add only one line of code to get the table data later):

Add a reference to using Microsoft.WindowsAzure.MobileServices;
Define a private member that references the employees table from the Mobile Service (note that this is using the existing class definition we already had in our code… Pretty cool eh?):

Now we will define the ‘initAsync’ function. This function is used to get and set the number of rows in the data source to the variable _maxCount.

Finally we need to fetch the data from the employee table and return the values. Modify LoadMoreItemsOverrideAsync as pictured (This is only one line of code we added!).

The next and last code file we need to modify is Employee.cs.

Our table will have an Id member so we simply need to add that to the existing class definition: Modify Employee to have an id: public int Id { get; set; }

The final change is to the Manifest. We simply need to add ‘Internet’ so when we access the Mobile Service the call is allowed out.

Now compile and run the application. Go to Scenario8 and you should have no data but no errors!

Generate sample data

Now we need to generate some sample data for our app to show how it is incrementally fetching data. We will use the scheduler in our Mobile Service to do that.

Click on the ‘SCHEDULER’ item and choose ‘CREATE A SCHEDULED JOB’

Use ‘prepopulate’ for the name and chose the ‘On demand’ radio button

Add this code to insert 1000 records (thanks to Paul Batum for this script)

Some notes on this script:

I chose to use the same data as the original sample which results in ‘Name1’ and ‘Organization1’ etc… Feel free to get more creative.

This script avoids an issue that you could hit if you iterate over a simple loop and insert the items. Since the insert is asynchronous you could run out of connections to the SQL backend (this is limited in our scheduler on purpose) and hang your service. So… use this script which waits for completion before resuming the insert (Paul developed this script for me).

Note that I am inserting ‘Name’ and ‘Organization’ columns and this happens automatically for me thanks to the Dynamic Schema ability of Mobile Services (you can turn that off BTW).

‘Save’ the script
Hit ‘Run Once’ and after you get notification that the job has submitted
Go to the ‘LOGS’ area of your Dashboard and refresh the page periodically until you see the two messages shown (which the script will write to the log).

The sample data has be populated!
Go to the ‘DATA’ tab and see the new records and columns added

See the data in action!

Now you should be able to Run the app (or hit the refresh button if the app is still up) and see the records incrementally loading! Note how the incremental loading only loads what the user is scrolling to (note the weird scroll bar behavior too since the control does not ask for the total count).

Summary

You saw how with very few lines of code and very little effort we could add a Cloud based data source using Windows Azure Mobile Services to our existing incremental loading sample. I leave details like updating and records to you but as you learn more about Windows Azure Mobile Services and go through the tutorials you will see how easy that is. Again, loading thousands of items in a list box probably is not the best design for accessing data, however you can see how even loading a few hundred can be more efficient using incremental loading. Attached is a zip that has the code I modified for this example.

Good luck programming with Windows Azure Mobile Services and Windows Store apps! Be sure to post any questions or comments as you play with these technologies up on the forums (where I hang out a lot lately): Windows Store apps and Windows Azure Mobile Services

Special thanks to Matt Small and Paul Batum for helping me overcome issues when developing this Blog! Don’t forget to follow the Windows Store support team on Twitter @wsdevsol.

Using WCF classes to consume a WebService using Plain Old XML (POX) in a Windows Store app

Prashant H Phadke — Tue, 26 Mar 2013 01:29:00 GMT

You can leverage WCF functionality from a Windows Store app to call a WebService using Plain Old XML (POX) style of messaging. This blog and the sample included below documents the steps a Windows Store app should perform to consume such a service.

The sample is based off the topic of Interoperability with POX applications mentioned here: http://msdn.microsoft.com/en-us/library/aa738456.aspx Since Windows Store apps do not have an app.config file, this sample shows how a Windows Store app creates a CustomBinding through code. The CustomBinding is created in such a way that we do not use any Message Encoding and just use plain XML to transmit data. The app calls the Web method synchronously, but you can change it to call asynchronously using the BeginRequest/EndRequest methods.

The blog only covers the Windows Store app implementation and does not cover the implementation of the service. The service code included with this sample exposes the Add, Subtract, Multiply and Divide operations of a Calculator and requires the client to communicate with it using the following XML input body:

<Calculator>
  <Method>Add</<Method>
  <d1>2.1</d1>
  <d2>3.2</d2>
</Calculator>

Likewise, the response from the service has the following XML output payload:

<CalculatorServiceResponse>
  <Method>Add</Method>
  <ReturnValue>5.3</ReturnValue>
</CalculatorServiceResponse>

The Windows Store app communicates with the Service using the below steps.

1.) We start off with a “Blank App (XAML)” template using the Visual C# language and name it POXMessagingClient.

2.) With the blank project created, we add a Class called Calculator.cs in the client project. This class defines the input XML that the WebService expects (see above), so we will create the class with the same structure like this:

    [System.Runtime.Serialization.DataContract(Namespace = "http://tempuri.org/Calculator")]
    class Calculator
    {
        [System.Runtime.Serialization.DataMember]
        public string Method;
        [System.Runtime.Serialization.DataMember]
        public double d1;
        [System.Runtime.Serialization.DataMember]
        public double d2;
    }

3.) Similarly, we create a class that will correspond with the WebService response/ output format. To do that, create a class and name is CalculatorServiceResponse.cs and add the following contents:

    [System.Runtime.Serialization.DataContract(Namespace = "http://tempuri.org/CalculatorServiceResponse")]
    public class CalculatorServiceResponse
    {
        [System.Runtime.Serialization.DataMember]
        public String Method;
        [System.Runtime.Serialization.DataMember]
        public String ReturnValue;
    }

4.) With the input and output structures declared, the next step is to implement a class that will actually call into the remote WebService. Add a class called CustomCalculatorClient.cs and then inherit it from the ClientBase<IRequestChannel> class. You also need to add the references to System.ServiceModel and System.ServiceModel.Channels as follows:

    using System.ServiceModel;
    using System.ServiceModel.Channels;
    ...
    class CustomCalculatorClient : ClientBase<IRequestChannel>
    {
    }

5.) Add a method called CreatePoxBinding that will generate a CustomBinding used to invoke the WebService. In this function we first create a TextMessageEncodingBindingElement and pass the first parameter to its constructor as MessageVersion.None. This indicates that a SOAP envelope will not be required. Then we create an HttpTransportBindingElement and then create a CustomBinding instance and pass in the 2 binding elements we just created. The function looks like this:

        private static Binding CreatePoxBinding()
        {
            TextMessageEncodingBindingElement encoder = new TextMessageEncodingBindingElement(MessageVersion.None, Encoding.UTF8);

            HttpTransportBindingElement transport = new HttpTransportBindingElement();
            transport.ManualAddressing = true;

            return new CustomBinding(new BindingElement[] { encoder, transport });
        }

6.) To associate this CustomBinding with our class, we add a constructor to our CustomCalculatorClient like this:

        public CustomCalculatorClient(Uri baseUri)
            : base(CustomCalculatorClient.CreatePoxBinding(), new EndpointAddress( baseUri ) )
        {
        }

7.) Add a method called PostAsync that will create the underlying WCF Channel request and call the remote service asynchronously. In this function call Message.CreateMessage where we pass in the entityBody for the request. The entityBody parameter will be an instance of the Calculator class with the Method, d1 and d2 parameters that the service expects. The actual conversion of an object to an XML payload will be handled internally. The functions look like this:

        public IAsyncResult PostAsync(Uri requestUri, object entityBody, AsyncCallback callback, object state)
        {
            Message request = Message.CreateMessage(MessageVersion.None, String.Empty, entityBody);
            request.Headers.To = requestUri;

            HttpRequestMessageProperty property = new HttpRequestMessageProperty();
            property.Method = "POST";

            request.Properties.Add(HttpRequestMessageProperty.Name, property);
            return this.Channel.BeginRequest(request, callback, state);
        }

8.) Notice that since this function is asynchronous, the BeginRequest function expects a callback function as well as a state object that will be used when the function call completes. These parameters are passed from the calling functions in MainPage.xaml. The callback function is called RespCallback and you can find it in the MainPage.xaml page and its implementation is as follows:

        private async void RespCallback(IAsyncResult asyncResult)
        {
            try
            {
                IRequestChannel channel = (IRequestChannel)asyncResult.AsyncState; 
                Message response = channel.EndRequest(asyncResult);
                CalculatorServiceResponse oCalcResp = response.GetBody<CalculatorServiceResponse>();
                String strOutput = "Result of "+ oCalcResp.Method +"=" + oCalcResp.ReturnValue;

                await this.Dispatcher.RunAsync(Windows.UI.Core.CoreDispatcherPriority.Normal, new Windows.UI.Core.DispatchedHandler(() =>
                {
                    txtOutput.Text = strOutput;
                }));
            }
            catch (Exception oEx)
            {
                // handle the exception
                this.Dispatcher.RunAsync(Windows.UI.Core.CoreDispatcherPriority.Normal, new Windows.UI.Core.DispatchedHandler(() =>
                {
                    txtOutput.Text = "There was an exception: " + oEx.Message;
                })).AsTask().Wait();
            }
        }

9.) The other two functions that are present in the CustomCalculatorClient.cs file – GetStatusCode and GetStatusDescription only extract the HTTP response code and the status description of the HTTP response.

10.) MainPage.xaml has 4 buttons that handle each of the 4 operations - Add, Subtract, Multiply and Divide, 2 textboxes that accept the input parameters and a TextBlock that displays the output.

11.) The click of the Add button has the following implementation:

        private void btnAdd_Click(object sender, RoutedEventArgs e)
        {
            try
            {
                Calculator oCalc = new Calculator();
                CustomCalculatorClient oCalcClient = new CustomCalculatorClient(serviceLocation);
                oCalc.Method = "Add";
                oCalc.d1 = double.Parse(txtInput1.Text);
                oCalc.d2 = double.Parse(txtInput2.Text);

                IAsyncResult result = oCalcClient.PostAsync(serviceLocation, oCalc, RespCallback, oCalcClient.InnerChannel);
            }
            catch (Exception oEx)
            {
                txtOutput.Text = "Add exception: " + oEx.Message;
            }
        }

The above function creates an instance of the Calculator class – that populates the requested method (Add) and then assigns the input parameters: d1 and d2.

An instance of the CustomCalculatorClient class is then created where we pass in the location of the remote service – serviceLocation that is set to http://localhost:8001/CalculatorService.

Note: The server address here is set to localhost and is for demonstration purposes only. For an actual Windows Store app, you cannot use localhost as the server address.

Next the PostAsync method is called, which will be responsible for sending the HTTP request asynchronously to the Service. The response processing happens in the RespCallback function as described in Step 7 that will extract the response body and display the results to the user.

To run the project, compile the solution and start an elevated command prompt from where you will start the POXMessagingService service. By default, the service starts listening on the http://localhost:8001/CalculatorService URI location. If you have other applications listening on port 8001, please change the port references to another port in both the projects. Alternately, start Visual Studio as an Administrator and then set the Startup Project to the POXMessagingService project (Right click on the POXMessagingService Project, and then select "Set as Startup Project").

Once the service is started, you can start your POXMessagingClient Windows Store app and then use the Add, Subtract, Multiply, Divide operations on the remote service.

This shows how you can consume a WebService using simple XML from a Windows Store app.

Datagram Socket Communication in Windows Phone 8

Mark Chamberlain - MSFT — Tue, 19 Mar 2013 20:53:00 GMT

New to Windows Phone 8 is the Windows.Networking.Sockets namespace. This namespace is also used in the Windows Store app development environment, which makes it convenient for developers who wish to port networking applications to both targets.

Windows.Networking.Sockets is the replacement for the older System.Net.Sockets namespace used in the Windows Phone 7 network model. System.Net.Sockets is provided for Windows Phone 7 compatibility purposes and is not recommended for new Windows Phone 8 projects.

This blog includes a Windows Phone 8 sample sockets application, Datagram Demo.

Datagram Demo implements UDP Datagrams (Unicast and Multicast), and demonstrates direct phone-to-phone communication using WiFi.

Procedure

Download and unzip the project file found at the end of this blog.
Obtain two Windows Phone 8 devices. Compile and then deploy the sample application to both phones.
Connect both phones to the same WiFi access point. The access point must support DHCP in order to automatically assign IP addresses to the phones.
Launch the application on both phones.
Touch the Multicast Inquire button on one phone, to discover other phones on the local WiFi access point, by transmitting a Multicast UDP packet (“WhoIsThere”). All phones (including the inquiring phone) respond by sending a Unicast UDP packet (“AckHereIam”) back to the phone that made the inquiry. The inquiring phone will report the IP address of each received AckHereIam packet to the main screen of the app.
The user can then choose and tap an IP address on the screen in order to communicate with that phone.
A second screen appears, “Communication Log”. Touch the Ping button. This will send a Unicast UDP packet (“Ping”) message to the chosen phone. The chosen phone will receive that message and respond by sending a unicast UDP Packet (“Pong”) back to the inquiring phone that originated the communication.

Responses from a multicast inquiry may include packets from seemingly unexpected sources.

If you run the app in the emulator, a multicast inquiry will return multiple devices. In fact the responses come from the same emulator instance. The emulator has more than one IP address assigned to it. An IPaddress of 127.0.0.1 is the local loopback (local host) address of the PC. An IP address starting with 169.254… is a Link-Local address. The app filters out those addresses. If you wish to see all the addresses you may comment out the filtering code.

If you run the app in a real phone, the IP addresses of interest typically begin with 192.168… on a standard WiFi network. However if your phone is connected to your mobile cellular service, on your inquiry screen you may also see an IP address corresponding to the cellular service. The IP address may begin with 10. That address does not appear to be useful for multicast inquiries.

UDP or TCP?

This sample demonstrates User Datagram Protocol (UDP) sockets. UDP has no built-in handshaking dialogs to guarantee packet delivery, which means that it is up to you, the developer to accommodate any unreliability in the network. Nor does it guarantee the order in which packets are received.

When using UDP socket connections, consider including your own mechanisms to properly order packets and retry sending packets etc. as needed, depending on your particular scenario and reliability requirements of your application.

You can leverage Transmission Control Protocol (TCP) to automatically provide reliable and correctly ordered delivery of a stream of data. Since only UDP supports multicasting, you can use UDP initially in order to discover other devices or computers to communicate with, and then establish a TCP connection using the StreamSocket and StreamSocketListener classes.

Some earlier phone brands did not properly detect multicast packets. If you find that multicasting is not working in a specific physical phone device, make sure the phone has the latest operating system version.

You can update the phone via Settings->system->phone update.

Happy networking!

--Mark

Additional resources

Sockets for Windows Phone

Code Project: DNS resolving and Parsing IP Address in Metro Style Applications(WinRT)

MSDN: How to detect network changes for Windows Phone

MSDN: How to get connection information about a socket for Windows Phone

Wikipedia: User_Datagram_Protocol

Channel 9: Building Apps for Windows Phone 8 Jump Start: (11) Network Communication

MSDN Developer Code Samples (Phone + networking)

Mixed Media – Audio & Video – Windows Store vs. Windows Phone 8

James Dailey - MSFT — Fri, 08 Mar 2013 00:57:00 GMT

As everyone knows, with the release of Windows 8 and Windows Phone 8 we have brought the two platforms closer together than ever before. The keyword here is “closer”. There are still some fairly major implementation and terminology differences between the two platforms particularly when working with digital audio and video. Hopefully this article will help you map and understand the media technologies between the two platforms. In this article I’m assuming that you are familiar with the media technologies on one platform or the other and just need some hints how to migrate your code to the other platform.

Audio / Video Playback Technologies

Audio / Video Playback – Technology Map
Windows Store	Windows Phone 8
MediaElement (XAML)	MediaElement (XAML)
IMFMediaEngine (C++ only)	IMFMediaEngine (C++ only) (Subset)
WASAPI (C++ only)	WASAPI (C++ only) (Subset)
XAudio2 (C++ only)	XAudio2 (C++ only)

The MediaElement will likely be your “go to” control on both platforms for playing audio and video. There are a few differences though. You can’t add audio or video effects (plug-ins) to the MediaElement on the phone. The DRM implementation is also quite different between the two platforms. If you are not doing anything “fancy” you should be able to port your MediaElement implementation with no problem.

The MediaEngine (different from the MediaElement discussed above) is new for both platforms in version 8. On both platforms the MediaEngine can only be used from C++ and is not currently supported from managed code. The phone also has slightly reduced functionality. On the phone the MediaEngine only supports frame-server mode. Also keep in mind that on the phone hardware acceleration will always be used.

WASAPI and XAudio2 are also supported on both platforms. Unfortunately at this time these audio only technologies can only be called from C++. They are not currently supported from managed code. While the full XAudio2 functionality is supported on both platforms keep in mind that XAudio2 only supports uncompressed PCM audio on the phone. It is extremely difficult to use XAudio2 with compressed media formats on the phone at this time. The phone also only supports a subset of the WASAPI Core Audio APIs as well.

References
Windows Store app		Windows Phone 8 app
Win32 and COM for Windows Store apps (multimedia)		Native audio APIs for Windows Phone 8
IMFMediaEngine interface (Windows)		Supported Microsoft Media Foundation APIs for Windows Phone 8
MediaElement class (Windows)		MediaElement Class

Background Audio

Background Audio – Technology Map
Windows Store (XAML / HTML5)	Windows Phone 8 (XAML)
MediaElement / Audio tag	BackgroundAudioPlayer
msAudioCategory="BackgroundCapableMedia"	AudioPlayerAgent
Windows.Media.MediaControl	Universal Volume Control (UVC)
Media Foundation Source (C++ only)	MediaStreamSource

The big difference playing background audio in a Windows Store app vs. Windows Phone 8 app is the use of the BackgroundAudioPlayer on the Phone and the MediaElement / Audio tag for Windows Store apps. The BackgroundAudioPlayer is a static class that can be used without needing instantiation. The MediaElement and Audio tags must be defined in markup before they can be used.

For your Windows Store app you must set MsAudioCategory=”BackgroundCapableMedia”. For your phone app you need to create an AudioPlayerAgent that will run in the background when your app gets swapped out.

The final thing to note is that on both platforms you need to handle user input from the lock screen media controls. On the phone we call these controls the “Universal Volume Control” (UVC) and in your Store app we call them the “media controls”. Different terms but the same basic functionality.

References

Windows Store app

Windows Phone 8 app

How to play audio in the background (Windows Store apps using JavaScript and HTML)

Background audio overview for Windows Phone

Sharing Media

Sharing Media – Technology Map

Windows Store (XAML / HTML5)

Windows Phone 8 (XAML)

DataTransferManager class

ShareMediaTask Class

The big difference here is that with Windows Store apps the user initiates the sharing process using the “share charm”. On the phone your app will need to invoke the ShareMediaTask directly from within your code.

In both cases you will likely never get confirmation that your data was successfully shared. In essence it’s a “fire and forget” operation.

Keep in mind that on the phone your app will be swapped out and may get shut down when the app you are sharing with takes up the full screen. Because of this you may need to save state.

References

Windows Store app

Windows Phone 8 app

Sharing and receiving content (Windows Store apps using JavaScript and HTML) (Windows)

How to use the share media task for Windows Phone

Where did all my gestures go?

Rob Caplan — Sat, 16 Feb 2013 06:17:00 GMT

A common problem we’ve seen from customers is how to handle pointer input and manipulations on elements inside of collection controls such as ListViews, GridViews, and FlipViews. The app can get the PointerPressed event on items inside the View, but after that the pointer events disappear and the app cannot convert them into gestures or manipulations.

So what is going on here?

The common element is that these controls all host a ScrollViewer, and the ScrollViewer takes over the pointer handling to run its scrolling. Once the ScrollViewer is in charge it handles all of the pointer and manipulation events without the app having its own chance at them.

This means that if an app needs to handle pointer events inside a scrolling control then it needs to disable the ScrollViewer (more on that below).

Why does the ScrollViewer take over the pointer handling?

Efficiency and responsiveness. Xaml applications compose and render their graphics on separate threads. The rendering thread is in charge of keeping the screen updating at a fluid pace. The composition thread is where the app’s UI code runs and which can update the layout of the controls. Whenever the layout isn’t updating the render thread can keep the visual display crisp and quick even while other work is being done. Non-layout updates such as independent animations and rendering transforms can be done on the rendering thread without slowing down to synchronize the two threads.

Because touch manipulations need to be very responsive, Xaml apps tap into a Windows feature known as Direct Manipulation to handle input at a low level on the render thread. Direct Manipulation detects touch input such as scrolling, panning, and scaling. The ScrollViewer uses it to scroll swiftly and cleanly, and the app can listen to Direct Manipulation via the Xaml Manipulation events to apply scaling, translation, and rotation render transforms responsively in sync with the render thread.

That is where the missing pointer events go. When the ScrollViewer handles the PointerPressed event the Direct Manipulation engine takes over the pointer handling and the app doesn’t receive any more pointer events until the current manipulation has ended.

So what can an app do if it needs the pointer messages?

The easiest way is to restrict the needed pointer messages to a sub-item which blocks the scrolling and set it to handle its own manipulations. For example, an Image in a FlipView’s ItemTemplate with ManipulationMode=”All” will not trigger the ScrollViewer for touches inside the image. The Image will receive both Xaml manipulation events and pointer events which can be passed to a GestureRecognizer.

If the app cannot scope the pointer messages to a sub-item then it is trickier. The next best is to restrict the messages to a sub-region or usage mode. In that case the PointerPressed handler can detect if it is in the sub-region or non-scrolling mode, and if so it can walk the visual tree to find the ScrollViewer and disable the ScrollViewer’s invocation of Direct Manipulation. To do this, change the ScrollViewer’s HorizontalScrollMode and VerticalScrollMode to Disabled. Likely you’ll only need to change one, depending on if you have a horizontally scrolling GridView or FlipView, or a vertically scrolling ListView:

ScrollViewer FindParentScrollViewer(DependencyObject start)
{
    DependencyObject item = start;
    DependencyObject parent = null;
    do
    {
        parent = (DependencyObject)VisualTreeHelper.GetParent(item);
        if (parent is ScrollViewer)
        {
            return parent as ScrollViewer;
        }
        item = parent;
    } while (item != null);

    return null;
}

bool InDisableScrollViewerRegion(PointerPoint pt)
{
    // For demonstration purposes, scroll at the top and block the rest
    return pt.Position.Y > 400;
}

private void OnPointerPressed(object sender, PointerRoutedEventArgs e)
{
    DependencyObject depObj = (DependencyObject)e.OriginalSource;

    if (InDisableScrollViewerRegion(e.GetCurrentPoint(this)))
    {
        DisableScrolling((DependencyObject)e.OriginalSource);
    }

    UIElement target = sender as UIElement;

    PointerPoint point = e.GetCurrentPoint(itemFlipView);
    gestureRecognizer.ProcessDownEvent(point);
    target.CapturePointer(e.Pointer);
    e.Handled = true;
}

ScrollMode _originalScrollMode;
bool _scrollingDisabled = false;
private void DisableScrolling(DependencyObject depObj)
{
       ScrollViewer parentElem;
       parentElem = FindParentScrollViewer(depObj);
       if (parentElem != null)
      {
            _originalScrollMode = parentElem.HorizontalScrollMode;
            _scrollingDisabled = true;
            parentElem.HorizontalScrollMode = ScrollMode.Disabled;
     }
}

private void RestoreScrolling(DependencyObject depObj)
{
     if (_scrollingDisabled)
     {
            _scrollingDisabled = false;
            ScrollViewer parentElem = FindParentScrollViewer(depObj);
            if (parentElem != null)
            {
                    parentElem.HorizontalScrollMode = _originalScrollMode;
            }
     }
}

Unfortunately there is no good solution if the app needs both scrolling and gestures (for example, to detect CrossSlides against the scrolling). In this case the only option to get the Pointer messages everywhere is to disable Direct Manipulation everywhere, but that disables scrolling as well. To get that back the app will need to detect the scrolling gestures itself and then navigate the ScrollViewer to the new location with ScrollToHorizontalOffset or ScrollToVerticalOffset or by updating the SelectedIndex. This is tricky and will be noticeably slower than letting the ScrollViewer do its thing. It should be avoided if at all possible.

--Rob

How to use HttpClient to post JSON data

Jeff Sanders — Tue, 05 Feb 2013 19:43:37 GMT

This is a common request in forums so I will show you how to use the new HttpClient class and the DataContractJsonSerializer to post JSON data to a web service. Posting serialized JSON objects to web endpoints is a common way to get data over HTTP and HTTPS to and end point and although this is extremely easy in the WinJS realm (when writing HTML5/JavaScript Windows Store apps), there is not a good example of how to do this using HttpClient for the .NET applications.

Step 1 – Find out what data you need to send

If you are sending JSON data to a WebService the service itself should have an example of what it expects. Often there is sample code that you can use to generate a POST. Start by capturing a successful POST to the web service and capture the HTTP or HTTPS traffic. This will allow you to compare your POST to something you know is correct. One tool that will help you immensely while developing apps using HTTP and HTTPS protocols is Fiddler. In my sample I captured the HTTP traffic to a Windows Azure Mobile Services endpoint.

Here is the HTTP traffic I captured with Fiddler from the sample application generated by Mobile Services when I POST data to the background database.

POST https://sharemydata.azure-mobile.net/tables/TodoItem HTTP/1.1
Accept: application/json
X-ZUMO-INSTALLATION-ID: 8bc6aea9-864a-44fc-9b4b-87ec64e123bd
X-ZUMO-APPLICATION: OabcWgaGVdIXpqwbMTdBQcxyrOpeXa20
Content-Type: application/json
Host: sharemydata.azure-mobile.net
Content-Length: 31
Expect: 100-continue

{"text":"ddd","complete":false}

Instead of using the magic of the MobileServices classes provided, In the next step I will show how to use the new HttpClient classes to show how to POST the same data I captured above. You should then be able to extend this to your case when you need to POST using JSON. Again the intent is not to bypass the libraries we have provided for you, simply show how one JSON based web service can be analyzed and you can use this to troubleshoot and POST to it using the HttpClient and associated classes.

Step 2 – Understand what is being POSTED and duplicate it

Let’s walk through the trace I took above line by line and create code to duplicate this:

POST https://sharemydata.azure-mobile.net/tables/TodoItem HTTP/1.1

// I will create an HttpClient and POST to the Uri https://sharemydata.azure-mobile.net/tables/TodoItem

// Create HttpClient instance to use for the app
HttpClient aClient = new HttpClient();

// Uri is where we are posting to:
Uri theUri = new Uri("https://sharemydata.azure-mobile.net/tables/TodoItem");

// use the Http client to POST some content ( ‘theContent’ not yet defined).
aClient.PostAsync(theUri, theContent);

Accept: application/json

// I have to let the server know I accept json data when it replies so this will add that header

aClient.DefaultRequestHeaders.Accept.Add(new MediaTypeWithQualityHeaderValue("application/json"));

X-ZUMO-INSTALLATION-ID: 8bc6aea9-864a-44fc-9b4b-87ec64e123bd

I saw from the webservice documentation this is optional so I could leave it out (but I won’t).

aClient.DefaultRequestHeaders.Add("X-ZUMO-INSTALLATION-ID", "8bc6aea9-864a-44fc-9b4b-87ec64e123bd");

X-ZUMO-APPLICATION: OabcWgaGVdIXpqwbMTdBQcxyrOpeXa20

Set this header to let the service know what application is trying to insert data

aClient.DefaultRequestHeaders.Add("X-ZUMO-APPLICATION","OabcWgaGVdIXpqwbMTdBQcxyrOpeXa20");

Host: sharemydata.azure-mobile.net

aClient.DefaultRequestHeaders.Host = theUri.Host;

Expect: 100-continue

This is added by default so you do not have to do anything

The Content headers and information

You will notice I skipped Content-Type: application/json, Content-Length: 31 and {"text":"ddd","complete":false}.

All this is content related will be added by assigning ‘theContent’ as a StringContent object in the PostAsync call above. You can certainly send simple text and format it yourself to be a JSON string and this is fine for simple JSON posts. If you have a complicated object it is better to let our classes do the work for you!

Define a class that reflects the JSON data posted.

[DataContract]
   public class TodoItem2
   {
       public int Id { get; set; }

       [DataMember(Name = "text")]
       public string Text { get; set; }

       [DataMember(Name = "complete")]
       public bool Complete { get; set; }
   }

Here I defined a class to represent the JSON data I will post. The attributes ‘DataContract’ and ‘DataMember’ are necessary for the JSON serialization class. You will see that ‘DataMember’ further defines the name ‘text’ and ‘complete’ which are lower case representations of the public members of the class. This illustrates that you can adorn and existing class and change the Name of the DataMember used to generate the serialized JSON data. Also notice that the public int ‘Id’ does not have a DataMember attribute. This will hide this attribute from the serialization.

Create and Populate the class with data

You simply instantiate and assign the data to the is class:

//Class that will be serialized into Json and posted

TodoItem2 todoItem2 = new TodoItem2();

//Set some values
todoItem2.Text = "ddd";
todoItem2.Complete = false;

Add code to serialize the object to a string and create a StringContent object to pass to the PostAsync call

//Create a Json Serializer for our type
DataContractJsonSerializer jsonSer = new DataContractJsonSerializer(typeof(TodoItem2));

// use the serializer to write the object to a MemoryStream
MemoryStream ms = new MemoryStream();
jsonSer.WriteObject( ms, todoItem2);
ms.Position = 0;

//use a Stream reader to construct the StringContent (Json)
StreamReader sr = new StreamReader(ms);
StringContent theContent = new StringContent(sr.ReadToEnd(), System.Text.Encoding.UTF8,"application/json");

Step 3 – Validate your POST looks correct and works

This is all you need to do in order to stream the content of the object to the web service. Now when I run this code in my app and take a trace with Fiddler I see that the POST succeeded with a 201 and the POST indeed is practically identical to my previous successful case (the order of the headers is different and there is a charset attached to the Content-Type which is fine):

POST https://sharemydata.azure-mobile.net/tables/TodoItem HTTP/1.1
Accept: application/json
X-ZUMO-INSTALLATION-ID: 8bc6aea9-864a-44fc-9b4b-87ec64e123bd
X-ZUMO-APPLICATION: OabcWgaGVdIXpqwbMTdBQcxyrOpeXa20
Content-Type: application/json; charset=utf-8
Host: sharemydata.azure-mobile.net
Content-Length: 31
Expect: 100-continue
Connection: Keep-Alive

{"complete":false,"text":"ddd"}

Summary

If you realize that POSTing JSON data is simply providing the correct HTTP or HTTPS traffic to an endpoint, you can use the above code to build your own code that will communicate with whatever endpoint you want. You are really just sending a string with the appropriate headers. Receiving JSON data is similar and will be covered in a following POST if there is enough interest (however it is fairly well documented).

Note: I changed the data in this post to a fictional end point. You will need to create your own Windows Azure Mobile Services application to try this yourself or identify your own endpoint that accepts JSON data!

Completed Code:

C#

[DataContract]
   public class TodoItem2
   {
       public int Id { get; set; }

[DataMember(Name = "text")]
public string Text { get; set; }

       [DataMember(Name = "complete")]
       public bool Complete { get; set; }
   }

//Where we are posting to:
Uri theUri = new Uri("https://sharemydata.azure-mobile.net/tables/TodoItem");

//Create an Http client and set the headers we want
HttpClient aClient = new HttpClient();
aClient.DefaultRequestHeaders.Accept.Add(new MediaTypeWithQualityHeaderValue("application/json"));
aClient.DefaultRequestHeaders.Add("X-ZUMO-INSTALLATION-ID", "8bc6aea9-864a-44fc-9b4b-87ec64e123bd");
aClient.DefaultRequestHeaders.Add("X-ZUMO-APPLICATION", "OabcWgaGVdIXpqwbMTdBQcxyrOpeXa20");
aClient.DefaultRequestHeaders.Host = theUri.Host;

//Class that will be serialized into Json and posted
TodoItem2 todoItem2 = new TodoItem2();

//Set some values
todoItem2.Text = "ddd";
todoItem2.Complete = false;

//Create a Json Serializer for our type
DataContractJsonSerializer jsonSer = new DataContractJsonSerializer(typeof(TodoItem2));

// use the serializer to write the object to a MemoryStream
MemoryStream ms = new MemoryStream();
jsonSer.WriteObject(ms, todoItem2);
ms.Position = 0;

//use a Stream reader to construct the StringContent (Json)
StreamReader sr = new StreamReader(ms);
// Note if the JSON is simple enough you could ignore the 5 lines above that do the serialization and construct it yourself
// then pass it as the first argument to the StringContent constructor
StringContent theContent = new StringContent(sr.ReadToEnd(), System.Text.Encoding.UTF8, "application/json");

//Post the data
HttpResponseMessage aResponse = await aClient.PostAsync(theUri, theContent);

if (aResponse.IsSuccessStatusCode)
{

}
else
{
// show the response status code
String failureMsg = "HTTP Status: " + aResponse.StatusCode.ToString() + " - Reason: " + aResponse.ReasonPhrase;
}

VB

Public Class TodoItem2
    Private Property Id() As Integer
        Get
            Return m_Id
        End Get
        Set(value As Integer)
            m_Id = value
        End Set
    End Property
    Private m_Id As Integer

    Public Property Text() As String
        Get
            Return m_Text
        End Get
        Set(value As String)
            m_Text = value
        End Set
    End Property
    Private m_Text As String

    Public Property Complete() As Boolean
        Get
            Return m_Complete
        End Get
        Set(value As Boolean)
            m_Complete = value
        End Set
    End Property
    Private m_Complete As Boolean
End Class

Private Async Sub SendJsonPost()
'Where we are posting to:
Dim theUri As New Uri("https://sharemydata.azure-mobile.net/tables/TodoItem")

    'Create an Http client and set the headers we want
    Dim aClient As New HttpClient()
    aClient.DefaultRequestHeaders.Accept.Add(New MediaTypeWithQualityHeaderValue("application/json"))
    aClient.DefaultRequestHeaders.Add("X-ZUMO-INSTALLATION-ID", "8bc6aea9-864a-44fc-9b4b-87ec64e123bd")
    aClient.DefaultRequestHeaders.Add("X-ZUMO-APPLICATION", "OabcWgaGVdIXpqwbMTdBQcxyrOpeXa20")
    aClient.DefaultRequestHeaders.Host = theUri.Host

'Class that will be serialized into Json and posted
Dim todoItem2 As New TodoItem2()

    'Set some values
    todoItem2.Text = "ddd"
    todoItem2.Complete = False

'Create a Json Serializer for our type
Dim jsonSer As New DataContractJsonSerializer(GetType(TodoItem2))

    ' use the serializer to write the object to a MemoryStream
    Dim ms As New MemoryStream()
    jsonSer.WriteObject(ms, todoItem2)
    ms.Position = 0
    Dim sr As New StreamReader(ms)

    'Note if the JSON is simple enough you could ignore the 5 lines above that do the serialization and construct it yourself
    'then pass it as the first argument to the StringContent constructor
    Dim theContent As New StringContent(sr.ReadToEnd(), System.Text.Encoding.UTF8, "application/json")

'Post the data
Dim aResponse As HttpResponseMessage = Await aClient.PostAsync(theUri, theContent)

If (aResponse.IsSuccessStatusCode) Then

Else

'show the response status code
Dim failureMsg = "HTTP Status: " + aResponse.StatusCode.ToString() + " - Reason: " + aResponse.ReasonPhrase

End If
End Sub

Windows Store Developer Solutions

Dealing with Documents: How (not) to use the documentsLibrary capability in Windows Store apps

Your Windows Phone 7/8 application tests fine, but fails after publishing to Marketplace or after private app distribution

WebView Magic Tricks: Highlight a Search Term

Windows Phone 8: Steps to acquire an Enterprise Mobile Code Signing Certificate required to sign LOB or company apps

Step 1: Open a Company account and obtain its Publisher ID

Step 2: Identify the account

Step 3: Provide order details and billing information

Step 4: Corporate Approval

Step 5: Certificate pick up

Step 6: Find certificate in the Cert Store

Incremental Loading of Data using Windows Azure Mobile Services

Prep work:

Add a new Windows Azure Mobile Service for the project and configure it

Modify the existing sample to use our new Windows Azure Mobile Service

Modify Scenario 8 to use our new Mobile Service

Now lets modify some code we need to attach to our data source

Generate sample data

See the data in action!

Summary

Using WCF classes to consume a WebService using Plain Old XML (POX) in a Windows Store app

Datagram Socket Communication in Windows Phone 8

Mixed Media – Audio & Video – Windows Store vs. Windows Phone 8

Audio / Video Playback – Technology Map

Windows Store

Windows Phone 8

References

Windows Store app

Windows Phone 8 app

Background Audio – Technology Map

Windows Store (XAML / HTML5)

Windows Phone 8 (XAML)

References

Windows Store app

Windows Phone 8 app

Sharing Media – Technology Map

Windows Store (XAML / HTML5)

Windows Phone 8 (XAML)

References

Windows Store app

Windows Phone 8 app

Where did all my gestures go?

How to use HttpClient to post JSON data

Step 1 – Find out what data you need to send

Step 2 – Understand what is being POSTED and duplicate it

Step 3 – Validate your POST looks correct and works

Summary

Completed Code:

C#

VB