I’m just passing this on because I’ve been stung by a couple of gotchas introduced with SL8.1 which only seem obvious after you’ve fixed them:-
If your application implements a custom Uri scheme you probably think you just have to add it to your WMAppManifest.xml as you always used to and the job is done. Well no, you see Silverlight 8.1 apps have two manifests – they also have a Windows Store Package.appxmanifest and this is the one the store uses. So if you have an app which handles say “myapp:” and you run an app which calls this Uri the store opens on the phone and displays no results. If you have the app installed then the association works as expected. You need to add the protocol to the Declarations tab of the Package.appxmanifest editor and submit an update. Once this is submitted it starts working even before your new version is necessarily available…
This leads onto the second issue. I always use the WMAppManifest.xml version and increment it and store it in source control. When I submit an 8.0 update I find it frustrating that the store doesn’t pick this up and I have to manually input it. If they don’t match my update prompter gets very confused (but that’s another issue). When I submitted a new SL8.1 app I was impressed that this version box is now greyed out and will populate the value from my submitted package. What I failed to notice when doing an update was that I now need to make sure I update both the WMAppManifest.xml and the Package.appxmanifest versions to keep these in step as the store uses the value from Package.appxmanifest…
If you haven’t already heard, we are running a developer event for Windows app developers in Manchester on the 16th and 17th May as part of the global //publish/ event. Pete has more details on his blog post here so I urge you to take a look and then
In Windows Phone 8.1 both the Silverlight and Windows App programming models introduce the WebAuthenticationBroker class. This is inherited from “big” windows but with a change to reflect differences in the app model. Rather than operate as an asynchronous method within the context of your app there is instead an AuthenticateAndContinue method. This closes your app and launches the authentication window in a separate process, returning to your app upon completion. You will find that AuthenticateAsync will throw an exception even though the method is in intellisense and not marked as obsolete. You then need to hook the ContractActivated event of your application instance to determine the result when your application is relaunched. This flow is used not just by the WebAuthenticationBroker but also file pickers and other contract operations.
In Windows Phone 8.0 projects I built my own WebAuthenticationBroker to match the desktop API and with the release of Windows Phone 8.1 I tweaked the look slightly to match and released it as part of the Charming Apps for Windows Phone project. You’ll find this in NuGet here. You can then add OAuth with a couple of lines of code e.g.:-
WebAuthenticationResult result = await WebAuthenticationBroker.AuthenticateAsync(WebAuthenticationOptions.None, requestUri, callbackUri);
if (result.ResponseStatus == WebAuthenticationStatus.Success)
// parse the token here (implementation specific)
The dialog displays the app name and uses as much space as possible for the web content:-
Some caveats – I’ve only used it with a couple of OAuth providers so I can’t guarantee it will support every variation. As with the Microsoft implementations you still have to do some manual parsing of the returned data to get your token. It doesn’t support WebAuthenticationOptions (other than None) and doesn’t read the HTML meta-tags Microsoft introduced to display a logo or background colour. It will however use the app logo and title as the built-in component does on 8.1.
While this does support 8.1 I would suggest that if you are starting a new project you use the built in component and ContractActivated event, if you want to target both 8.0 and 8.1 then you can use this component and the user experience is consistent with the built-in experience.
I came across this issue with a test app which had been working fine either when debugging or deploying the XAP file directly. Then I set up a beta and when installed the app just starts and immediately stops. Since it took me some time to try a few things to identify the issue I thought I’d share it here. The problem was that the app uses a background task. The Agent is added to the solution using the project template, added as a reference in the application project and the code to schedule the task is set up in App.xaml.cs. As I discovered I had neglected to add in the ExtendedTask element to my WMAppManifest.xml. Presumably as the .dll was not specified here it was not being correctly signed as part of the store ingestion and so the published beta app was in a broken state. Here is what the entry should look like. Remember you can’t set this through the GUI you have to view the raw XML file and make edits there:-
The latest addition to the “Build Charming Apps for Windows Phone” libraries addresses a couple of properties required to support different screen sizes. I decided I wanted a simple way to retrieve the DPI and Scale factor (real not emulated) while working smoothly on devices prior to GDR3 where 1080p support was added. The result is a single class – DisplayInformation which (true to theme) follows the Windows 8.1 object model.
Some of the properties found in the desktop implementation make no sense – there isn’t support for Stereoscopic output for example. So just three properties are exposed – RawDpiX, RawDpiY and ResolutionScale. One additional member is added to the ResolutionScale enumeration as desktop Windows has no concept of 2.25 scale factor but this is used for 1080p Windows Phone devices. It’s not always possible to provide a perfect API match to the desktop and this seemed like a good workaround. These will call into the extended properties in GDR3 where possible but will equally work correctly on older devices.
Windows Phone developers have received an email about the upcoming changes to make mobile operator billing available in more countries. In particular markets from March 2014 this means that there will be an additional deduction from your revenue for these specific markets when mobile billing is used (not for continued credit/debit card purchases). The markets in question are:-
Argentina, Chile, Colombia, Cost Rica, Malaysia, Mexico, Peru, South Africa.
For these purchases Microsoft will take an additional 13.9% of the receipt to cover processing costs leaving you with 56.1% of the "list price" rather than the usual 70%. A suggestion on Microsoft’s "Define pricing and market selection" page is to adjust the price for these markets, but then you’ll be penalising the end users and the increased price might deter customers. Hopefully the potential increase in sales from these markets will show that 56.1% of something is better than 70% of nothing and overall developers will see a benefit from reaching these markets.