Stop submitting App Studio created apps to the store - you're just highlighting the poor test process

App Studio is a tool from Microsoft that will allow you to "take your app from idea to Windows Phone in record time". Unfortunately the apps it creates shouldn't pass the store's certification testing.

App Studio is still in Beta but already many people are using it to build apps and submit them to the store. Seems reasonable enough as that's what it's for. The only issue is that the apps that it generates contain bugs that mean they shouldn't pass the testing that is done as part of the application certification process. Every time such an app is certified it highlights a failing of the publisher and the store test processes to identify the issues and stop them reaching the consumer.
Even if the person using the app can get past the, arguably, poor design of the generated apps, no one deserves an app that crashes.

So what's the issue?

We'll, the biggest and easiest to demonstrate is an issue that should cause the app to fail the technical certification requirement 5.1.2:

The app must handle exceptions raised by the any of the managed or native System API and not close unexpectedly. During the certification process, the app is monitored for unexpected closure. An app that closes unexpectedly fails certification. The app must continue to run and remain responsive to user input after the exception is handled.
Recommendations
When handling exceptions, an app should provide a user-friendly error message. You may present a message that is relevant to the context of the app.

So how do the apps fail this requirement?
Just follow these simple steps to recreate a crashing scenario:

1. Launch the app
2. Tap on an item loaded from the internet.
3. Pin that item (via the link in the app bar)
4. Disconnect the phone's network connection (enabling flight mode is easiest)
5. Tap on the pin created earlier.
6. Observe the app open for a few seconds without displaying any content before crashing/closing.

I documented this and other issues previously but they all appear to still exist.


Two important lessons:

1. Don't assume that a generated app is good enough to release to the store. Test it thoroughly yourself!
2. All apps will be used in an occasionaly connected environment. You MUST test the apps behaviour in all network connection scenarios.

If you want to use App Studio then by all means go ahead. Just be aware that if you want to submit the generated app to the store then be aware that there will be a need to modify the generated code before you do.

Fixing the styling of the WPToolkit ToggleSwitch

If you've ever done any XAML based development for Windows Phone you'll be aware of just how essential the WPToolkit is.

One of the most popular controls contained in the toolkit is the ToggleSwitch. Unfortunately though, its default styling doesn't play well when you want to use it with custom foreground and background colours.

Looking at this image we can see the same page in both light and dark themes. (At 50% in Blend)
The first pair of toggleswitches show the checked and unchecked states with the default theme colours.
The second pair shows what happens if with the default styling when the background and foreground are modified though.
This is almost certainly NOT what you want to see.
With a modified foregound and background I'd expect you want to see something like in the final pair of switches.

So, how to get the toggleswitch to display "properly"?
It's just a case of modifying both the `toolkit:ToggleSwitch` and the `toolkitPrimitives:ToggleSwitchButton`.
Add a `Foreground` reference to `ToggleSwitch` and then replace all the StaticResource references to PhoneForegroundBrush and PhoneBackgroundBrush with TemplateBinding references to `Foreground` and `Background`.
If that sounds complicated, don't worry. You can just copy it from https://github.com/mrlacey/WPMisc/blob/master/ToggleSwitchStyling.xaml (Which also contains the xaml used to create the above images.)

If you've developed an app where the toggleswitches look like the middle pair you now know how to update them.
Similarly, if you know of any apps where there are toggleswitches look like the middle pair above, point them to this article. :)

Portable Class Libraries (PCLs) now on all platforms

If you care about the legal issues of redistributing third party libraries - which of course you should - this is huge news.

Earlier this week Microsoft announced that the platform restriction on using portable class library reference assemblies on non-Windows platforms has been removed.

PCLs are a great invention. They allow us to create assemblies that can be used on multiple platforms. This means I can bundle up some code and refer to it from a Windows Phone app, a Windows 8 app, a website, a desktop app and more.
This means I can reuse code without having to test it on each platform.

PCLs are great. However there was one big issue. If I was also building an app for a non-Windows Platform such as Android or iOS using the Xamarin tools then, legally, I wasn't allowed to distribute those libraries. At best that was a bit of an inconvenience. Fortunately now this issue has gone away. You can now build libraries you can share with apps running on all platforms without that particular legal concern.

Note that this is on the newest release of the assemblies only so make sure you are using those when distributing to anything non-Windows.

Alternatives to long web requests with long timeouts

Earlier I posted about how you can't create a web request with a timeout of more than the internal maximum of 60 seconds.

I was asked on Twitter about how to have the server tell the app that there was new data for the app to display.

As I said in the original post, the exact method to use will depend on the application but here are the main techniques to consider.

Direct notification
If the app is still running and the server has some new data for the app to display the server can tell the app directly. Either by telling the app to get it or sending it directly.

• Via a push notification (raw or toast)
• Via a socket connection - like with SignalR ;)

Smart polling
Having the app just check if there is new data on a predetermined periodic basis isn't the best we can do.

• If we've told the server we want some data and the server is indicating that it will be some time before the data is ready, the server should be able to provide an indication of how long it will be before the data is ready (based on typical load time, current queue size, etc.) The app can check back after that time. And, of course be given a new time if it isn't ready by then.

Offline notification
Of course if the server is taking it's time to generate (or prepare) the data the app needs then it's possible that the app might not still be running when the data is ready. In this instance the server may want to tell the user that there is data to view when they re-launch the app.

• The obvious option here is with push notifications (toast and tile)

But less platform specific options may also be valid too. Especially if combined with a custom schema to launch directly into the app.

• SMS
• Email

Of course a better alternative to any of the above would be to have the data ready when the the user/app wants it. This could be done either by preparing the data in advance so it's ready when needed or by being able to prepare it very quickly.

Get GRD3 now, in just 3 easy steps

If you're a developer and want to get Windows Phone 8.0 Update 3 on a device now, just follow these simple steps.

Step 0 - Make sure your device is developer unlocked. I'm assuming that as a developer you already have this, but it's probably worth noting.

Step 1 - Download and install this app: http://www.windowsphone.com/s?appid=178ac8a1-6519-4a0b-960c-038393741e96

Step 2 - Got to settings on the device and check for updates: It should find and download this:

Step 3 -Select "install" and wait. You'll see the spinning cog icons and a progress bar. It took just 7 minutes for me.

Done!

Making web requests with long timeouts on Windows Phone

It's quite common (I've seen/heard it several times) for people to want to make web requests from their app and have a very long time out. I.E. a timeout longer than 60 seconds.

Despite what you try there's no way to do this though.

That's right. Internally your web request will time out after sixty seconds. This means that while you can create a shorter timeout, you can't create one longer than this.

This shouldn't matter!
60 seconds is a lifetime on a mobile device. As a user, would you want to stare at your device for over a minute while your wait for new data to be loaded? Of course not.

But what if the server takes a long time to generate the data to return?
Then I'd suggest that this should be addressed in different ways:

• Have the server process faster.
• Have the server return some of the data initially while it prepares the rest for later.
• Have the server return some cached data while it gets the latest.
• Have the server push the data when it is available rather than relying on the app making requests for it.

Ultimately the "best" solution for this scenario will depend on your app, the data and the server. What you shouldn't do though is have the person using your app wait any longer than they absolutely have to.


Update: See a follow up post at Alternatives to long web requests with long timeouts

IE credential caching in Visual Studio (Error: F30063)

I get to work on a bunch of different projects that are stored in different Version Control systems on different servers. For the most part this is fine, despite the fact that Visual Studio (2012 - it may be better in 2013) doesn't like it when you have multiple instances open and they're connecting to different TFS servers.

Anyway, this morning I was trying to connect to open a project on a machine I hadn't used before. I did this by going to the TFS web portal and clicking on the "Open new instance of Visual Studio" link. Unfortunately, rather than seeing the project open in Visual Studio I was presented with this:

TF30063: You are not authorized to access https://XXXXXXX.visualstudio.com/defaultcollection.

After much investigation it seems that while I was viewing TFS in IE with one set of credentials, the embedded browser within Visual Studio was previously logged in to a different TFS server with a different set of credentials. As the set of credentials cached/remembered in VS weren't valid for the new server I got this error.

Simple solution:
Open the web browser window in Visual Studio.
Log out of the old server and log in to the new one with the correct credentials.
The "Open new instance of Visual Studio" link now works.


I hope this knowledge being documented here helps someone else avoid this issue or solve it faster than me if they do hit it and then find this post.

Gotcha when adding a Resources library to a project

Here's a fun fact I've just spent half an hour learning. Hopefully knowledge of it can save you some time in the future by avoiding the same issue.

"Resources" is a special (reserved) name when it comes to including things in a XAP file. If you name a file "resources" it will never be included in the XAP. (Noted thanks to this answer on StackOverflow)

Additionally (and this is the bit that caught me out) any file that ends ".resources" is also not included.

I had a library named like "MyApp.Resources.dll" that is referenced by my app but just wasn't being included in the XAP and so was leading to a spurious FileNotFoundException when running the code.
Fortunately it was just a case of renaming the outputted assembly to "MyApp.Res.dll" and all was fine again.

I hope this knowledge can save someone else from being caught out by this same issue.

How to put content on a lock screen image so it doesn't overlap with the text

I'm posting this for me own reference as much as for anyone else. ;)

When wanting to add lockscreen support to your app there is lots of useful information available about how to do this technically. Unfortunately there is little information about what you should put on the lockscreen or how you should position it to avoid it crashing into the text that may also be displayed over the lockscreen.
Today I'm going to look at the second of those issues.

Fortunately there are some values you can use to be sure your content won't overlap the text you can't control.
The values you need for WVGA screen devices are:
Left margin: 24px
Top margin: 56px
Space to use: 288px by 288px

If you're creating larger images for bigger screens that you don't want to be autoscaled then the values you need are:

For WXGA:
Left: 58px
Top: 90px
Space: 460x460px

For 720P:
Left: 36px
Top: 84px
Space: 432x432px

Here's an image to show the 720P values in situ.

At some point in the past I grabbed the above from a screencast. Sorry, I can't remember exactly where it's from but I think it was the Windows Phone design team. If anyone can help me point to the source that'd be great. Thanks :)

Of course, you may need to allow for variations due to language differences:

Linking to your app in the store

It's easy to create a link to an app in the store.
You just view it in a browser and then just copy the URI and then you can paste it for all to reuse. Don't you?

NO!

Unfortunately it's not that simple.
Let's consider the URI for the popular app, Facebook.

http://www.windowsphone.com/en-gb/store/app/facebook/82a23635-5bd9-df11-a844-00237de2db9e

The above is what I see. Notice the bit in bold? "en-gb" that's region specific and because the site knows I'm in the UK.

If I was I was in the USofA (or it didn't know where I was) then the "en-gb" would be "en-us". If I was in Finland then it'd be "fi-fi", etc. In theory this is a good thing. It means I can point people to appropriate, region specific, versions of the apps page so they can, if need be, see it in their language. Plus it lets me check how an app is displayed in different regions/languages.

So what's the problem?

The problem is what happens when trying do install an app from a region specific link that isn't your region.
Clicking install is fine, but then you'll see a screen like this.

That's not good.
But it's just an extra step as the user is redirected to their own regions store page. No big deal. Right?
In fact there are two problems here.

1. This is an extra step in the process. One important fact about the number of steps involved in a web based purchase is that the more steps there are the number of people who complete the process gets lower. In fact, taking steps out of a process means more people will complete it. Conversely, adding steps means more people don't complete it. (As an aside, this is one of the reasons that Amazon's 1-click purchase option is so important to them.)
   If someone has started the process of beginning to buy/install/download my app I want to do everything I can to help them to complete the process. It's worth money to me.
   While I can't change the windowsphone.com site, I can help potential customers avoid this situation by making sure they don't go to the wrong region in the first place.
2. Notice the text in the above screenshot. Particularly the term "buy". If I had a free app that someone was attempting to install I'd be worried that the introduction of the term "buy" would introduce doubt into their mind about what they were doing.
   "I though this was a free app. I don't want to pay for anything. Perhaps I'll stop."
   I don't want anyone who has expressed an interessed in installing one of my apps to end up thinking this.

So what can be done about this?

Fortunately there is a solution. 

The site provides a way for having a region agnostic URI that links to an app. These take the form:

http://www.windowsphone.com/s?appid={GUID}

So, for Facebook it'd be:

http://www.windowsphone.com/s?appid=82a23635-5bd9-df11-a844-00237de2db9e

It's very similar to the original one above as the largest part of the URI is the GUID anyway.

Just make sure you give people the region agnostic link when promoting your apps.

Does this really matter?

Well, in the grand scheme of things there are more important things to consider in terms of building and promoting a great app but it's so small it's easy to get right.

What about on device links?

On device it's a better story. Windows Phone will detect you're navigating to an app in the web version of the store and redirect you to the store app. At which point there are no region specifics to worry about other than the availability of the app in your region. If it's not available to you then you wont be able to purchase it regardless.

Again, this is so easy to do correctly and ensure a good experience for people who are viewing, and hopefully, ultimately, downloading your app then there should be no excuses.