Tag: Windows Phone 8

Windows Phone: Don’t write to the InstalledLocation Folder

Crashes that occur not during development, but only after the application is installed by the Windows Phone store are among the most difficult to troubleshoot. This is one of those bugs.

Windows Phone 8 expanded the file storage APIs to include the StorageFile class support for parity with Windows 8. This class gives you access to ‘special folders’ including the folder where the application is installed. You can get to this folder as follows:

Windows.ApplicationModel.Package package = Windows.ApplicationModel.Package.Current;
Windows.Storage.StorageFolder installedLocation = package.InstalledLocation;

During development you can read and write from this folder, however after installing from the Windows Phone store, any write attempts to this folder will result in a file exception being thrown. Again, this bug will not occur if the app is sideloaded, only when the app is installed from the store. Most likely this is a security precaution to prevent any tampering with the installed files. 

This type of scenario, makes a strong argument for using the beta testing feature of Dev Center that allows you to test the store presentation and installation experience of your app to a specific list of users. By looking at the Dev Center generated crash logs (yes these are generated for beta apps as well as production), you can find the cause of the crash. 

Instead if using the InstalledLocation, you can read and write to the Local Folder. See here for more information.



WP8: Lock Screen Notifications Sample



Having your app update the lock screen is one of the cool features of Windows Phone 8. It’s pretty easy to add this functionality to your app. See the documentation here for the details. I wrote sample code which you can download here.

The following are a couple of interesting things I found when putting together this sample:

To invoke the emulator’s lock screen press F12. Then press any button. The emulator will then be locked.






You can also invoke the lock screen via the new and cool ‘Simulation Dashboard’. Click on the ‘Locked’ radio button to lock the emulator. (see below)


The docs say the following ‘The lock screen’s app icon, count, and text are pulled directly from the app’s primary Tile.’ I found that the lock screen does not use the app icon from your primary tile. Instead it uses the a separate 38×38 image in your app, specifically for the lock screen, specified in the manifest file.










To have the lock screen update, you need to go to the device settings and enable it. The sample includes a button which will take you directly to the settings page for the lock screen. (Using the new WP8 API LaunchUriAsync.)


In the lock screen settings, select your app’s lock screen icon in the ‘Choose apps to show quick status’ control and specify your app in the ‘Chose app to show detailed status’ drop down. Unless you do this you will not see the lock screen update. (see to the left)








The lock screen uses the .BackContent and .Count properties of the main tile StandardTileData to display status and count. To update the main tile:

void UpdateTile(DateTime time)
    ShellTile tile = ShellTile.ActiveTiles.FirstOrDefault();
    var data = new StandardTileData();
    data.Count = time.Second;
    data.BackContent = string.Format(time.Second.ToString() + " seconds have elapsed.");


WP8: App Capabilities are now in Your Hands

imageIn Windows Phone 8, you are responsible for specifying the correct capabilities that are used by your application in the WMAppManifest.xml file. This is a departure from Windows Phone 7, where capabilities are detected during ingestion, with the capabilities being written to the WMAppManifest.xml file – overwriting what you specified during development. There are good and bad aspects to the WP7 approach, in WP7 you and your customers got the correct list of capabilities ensuring an accurate shopping and installation experience. The drawback was that in some cases, the capabilities detection would not properly detect an assembly in your app, resulting in a failure during certification testing due to the app not functioning properly or crashing.

For the Windows Phone 8 Store Test Kit, capability detection is no longer part of the automated tests. This is still available for Windows Phone 7 apps.

With the change in capability detection, you may be tempted to just include all of the capabilities. The problem with this is certain capabilities trigger different prompts in the install experience. For example, if you have specified the ID_CAP_LOCATION capability, during installation the user will be prompted with the ‘This application is using the location API, are you sure you want to install this?’ (I’m paraphrasing) prompt. If your app is not using the Location API, the user will get a misleading prompt during installation.

Additionally the capabilities of your app are listed in the Windows Phone Store catalog.  This list is generated from the manifest file. Specifying the capabilities of your app accurately will reflect the true functionality of your app to your potential customers.


See the Windows Phone 8 documentation topic ’App capabilities and hardware requirements for Windows Phone’ for information on capabilities and their related assemblies.

Windows Phone 8 SDK Launched Today!

Here is a quick summary of Windows Phone 8 announcements made today at the Build 2012 Conference and elsewhere.

The Windows Phone 8 SDK is now available for download here.

The updated Windows Phone Toolkit is available via NuGet here.

The updated Windows Phone Toolkit source and documentation is available on Codeplex here: http://phone.codeplex.com.

OData Client Tools for Windows Phone Apps has been updated and can be installed from here. See the blog post here. OData V3 now supported in Windows Phone apps!

Windows Phone Dev Center Accounts $8 for 8 Days: Developers can register for a Window Phone Developer Account for $8 (regularly $99) for the next eight days. (Register at http://dev.windowsphone.com) If you have an MSDN subscription, be sure and use the Window Phone Dev Developer Account included with your subscription.

Windows Phone Developer Blog kick-off post here.

Watch Webcast: Windows Phone 8 Launch here.

Watch Build Keynotes and Sessions here.

Windows Phone Push Notifications: Frequently Asked Questions

Updated March 3, 2013 – added clarifications around the use of certificates.
The following is a collection of FAQs regarding Windows Phone Push Notifications.

Q: How can I get started with Push Notifications?
A: A good way to approach Push Notifications is using a known working sample. Entire sample including client and server code here. Once you get the sample working, you can transfer that to an actual application. This way you can be sure you are composing the push notifications correctly. I would they suggest they get the sample working and then compare that to how they are doing the same notification type.

Q: Do we have to get a new URI if the original URI was received more than 30 days ago?
A: No. As long as the URI has not changed, you can continue to use the URI.

Q: How do we know if the URI has changed?
A: When the app starts, do an HttpNotificationChannel.Find and compare to the previously received channelURI stored in isolated storage. If different, update the web service registration with the new channelUri. If empty, recreate the Channel. See the file MainPage.xaml.cs in the sample here where this logic has been implemented. Note that it is a best practice to send along with the URI information that uniquely identifies the device (DeviceExtendedProperties.GetValue("DeviceUniqueId"). You can use this information when re-registering channel URIs with your web service to replace the existing (invalid) URI with the new one.

Q: How can we tell at the web service if the URI we are sending to the MPNS is still valid?

A: The MPNS will return a 404 response code with one the following notification statuses if the URI is not valid:

Response Code NotificationStatus DeviceConnectionStatus SubscriptionStatus
404 Not Found Dropped Connected Expired
404 Not Found Dropped Temporarily Disconnected Expired
404 Not Found Dropped Disconnected Expired

Note that your web service should stop sending notifications to this URI and un-register it, if the MPNS returns 404 (Dropped).

Q: What causes the MPNS to return the 404 (expired) response code?
A: The following conditions will cause a channel URI to become expired:
1) No activity for 30 days (the channel uri is not used).
2) The device is unable to connect with the MPN server for 30 days. In this case, MPN will return the 412 (inactive) response code, if it cannot connect within 30 days, it will return 404 (dropped).
3) If the xml payload of the notification request is not valid, MPNS will invalidate the channel uri and return 404.

When the application restarts it will receive a new channel URI, which should replace the current (expired) channel URI registered with the web service.

Q: What causes the MPNS to return the 412 (inactive) response code?
A: If the device has been off or otherwise cannot connect with the MPNS it is considered ‘temporarily disconnected’. When the device is in this state, the MPNS will return:

Response Code NotificationStatus DeviceConnectionStatus SubscriptionStatus
200 OK Received Temporarily Disconnected Active

If the web service sends another notification to this URI and at least 90 minutes have passed since the last ‘temporarily disconnected’ notification, MPNS flags the URI ‘inactive’ and will return the 412 response code. In this state, MPNS stops attempting to connect to the device. Note that temp disconnected and inactive are both natural states for a mobile device and shouldn’t be viewed negatively. Commonly 30-40% of devices show temp disconnected at any one time and 10-20% show inactive because mobile devices transition between network conditions and situations frequently.

Q: Besides sending a notification request to MPNS, is there any other way to know if a channel uri (device) has transitioned to the ‘inactive’ state?
A: No. Previous documented was a callback mechanism where authentication notifications could receive a callback if the device transitioned from active to inactive. This has been deprecated and removed from the documentation.

Q: If the PNS is no longer attempting to connect to the device, when does it start communicating again?
A: The PNS will attempt to connect to the device when the Web Service sends the next notification request. The response code returned reflects the devices state (200 – URI OK, 404, URI invalid, 412, URI OK, Device out of communication)

Q: What does the PNS response code 200 suppressed mean?
A: You can receive the suppressed status when for a:

  • Tile notification if the user hasn’t pinned the tile
  • Raw when the app is not in the foreground
  • Toast and Tile when the device is in low battery state

Q) What is the limit of notifications I can send to the users of my app?
A) By default, the limit is 500 notifications per channel URI per day. So if you have multiple notifications (say Toast and Tile) in your application, you can send 500 of each type. That is 500 of each type of notification per device / user. For example, if you have 100 users of your application and 1 type of notification, you can send up to 50,000 (1 * 500 * 100) notifications per day. Authenticated notifications are unlimited.

Q) How do I setup authenticated notifications?
A) Follow the guidance here: Setting Up an Authenticated Web Service to Send Push Notifications. Pay particular attention to the set up of the certificate. For more information on setting up the certificate, see here: No-quota push notifications using a root Certificate Authority.

Q) What can cause a 401 (Unauthorized) status returned when attempting to send an authenticated notification?
A) Can can get a 401 if the Service Name in the certificate does not match the service name parameter in the HttpNotificationChannel constructor. Also, the client will receive a URI with an ‘http’ prefix. If functioning properly HttpNotificationChannel  will return a Uri with an ‘https’ prefix.

Q) I am setting up authenticated notifications and am getting back a 403 status code in my web service code. What is going wrong?
A) Generally, a 403 (forbidden) status is what you would get if either you are not including a certificate in the POST request or it is not a valid/trusted cert. Note that the certificates need to be deployed onto the web servers sending the requests. These certificates should include the private key. (The certificate uploaded to Microsoft should NOT include the private key.) If using an intermediate certificate, ALL of the certificates in the chain should be added prior to the POST request (see below).  When submitting your application to Marketplace, you will also need to associate your application with the appropriate certificate. This is done in the ‘describe’ step.

Q) How do I include a certificate(s) in the POST request?
A) If you are using .NET in your server code, you can add the certificate to the HttpWebRequest as follows:

Request.ClientCertificates.Add(new X509Certificate2("[PathToCertificate]", "[Password]"));

If you are using Ruby, you can add the certificate as follows:



SERVER_CERT_FILE = "certs/freshCA.crt"

CERT_FILE = "certs/s2 at magnesium.crt"

CERT_FILE_KEY = "certs/s2 at magnesium.key"

require ‘net/https’

https = Net::HTTP.new(‘fresh’, 443)

https.use_ssl = true

#client certificates

https.cert = OpenSSL::X509::Certificate.new( File.read(CERT_FILE) )

https.key = OpenSSL::PKey::RSA.new( File.read(CERT_FILE_KEY), ‘panza’)

#server certificate

https.ca_file = SERVER_CERT_FILE

https.verify_mode = OpenSSL::SSL::VERIFY_PEER     #VERIFY_NONE

https.read_timeout = 120

https.start do |https|

  request = Net::HTTP::Get.new(‘/notes/test_auth’)

#  request.basic_auth ‘s’, ‘x’

  response = https.request(request)


  puts response.body



Q) In the code above, does this mean the private certificate (definition below) is sent as part of the request?
A) No. The private certificate is used to sign the request. The server then uses the included public cert to decrypt the request.

Q) When do I use a private certificate and when do I a public certificate?
A) First some definitions: a private certificate is one that includes the private key or is used along with a separate key (.key) file. A public certificate is one that does not include the private key. Note that with push notifications, you will use both private and public versions of your certificate.

Q) When do I use the public certificate? When do I use the private?
A) Upload certificate to Dev Center: Public
Install certificate on my web server certificate store: Private
Certificate included with POST request to MPNS: Private

Q) What can cause a 409 to be returned from the MPNS?
A) A 409 is returned when using authenticated notifications and the certificate has expired. You will need to submit a new certificate.