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.