In the classic 1939 movie The Wizard of Oz, Dorothy has just arrived and is looking around awed at the splendour. She says to her dog “Toto, I’ve a feeling we’re not in Kansas any more”. Well some of you seasoned Microsoft developers are going to feel exactly the same way when you get to the gates of developing your first Windows Store app.

Obviously, it’s different from what you know and love as .NET developers and Windows Store apps are different to those many programs that are now rather cruelly described as “legacy apps”. It’s different in some fairly obvious ways but there’s also some other perhaps more subtle “gotchas”. I’ll try and cover all these here.

Firstly, you can create Windows Store apps using C++, C# and new for Windows 8 Javascript, which is now a fully supported language. Such HTML, CSS and Javascript apps are rapidly becoming the solution for many developers who want to write cross-platform apps between different mobile devices (phones and tablets) as well as desktops. Beware though that a Windows 8 RT app is not a Windows Phone app – although if you write in Javascript it’s fairly easy to create them both. In this blog I’m assuming you are using Javascript.

Navigation Model

Unlike a web site which can contain a mixture of links to its own pages and other pages on the net, a Windows Store app can only refer directly to its own local pages, and for various reasons I strongly recommend that you actually build your app as a single page. This means that all the Javascript is loaded only once, and that changes to the user interface are done by programmatic manipulation of the DOM. Which leads us nicely to

Gotcha 1: You can’t just assign any old string to innerHTML.

You have to turn it into a special sort of trusted string by passing it through the toStaticHTML method. And if the string contains something like
<button onclick=’handleClick()’>Press me</button>
then the onclick handler will get stripped out.

There are various other ways round this restriction which is intended to stop script injection attacks.

Promise me

Within Javascript you have access to the Windows Library functions: these work on both Windows 8 for Intel and ARM chips. All of them return a result in the form of a promise, which is a rather elegant mechanism for providing asynchronous operations. Instead of opening a file (and keeping everyone waiting while you do so) and subsequently requesting the first few bytes of that file (and again waiting) the whole library works asynchronously. Essentially the developer goes “open that file and let me know when you’re done”, and then “OK now read some data and let me know when it’s ready”.

Thus some (imaginary) code to open a file might go
There are two useful calls that can act on a promise, then and done – more details here. They take success and fail functions and it’s very important that you always provide them both, as you find yourself in

Gotcha 2: When your program isn’t in the foreground it isn’t running.

So timeouts are very likely to happen. The user requests some data that causes a network transaction, and then slides to read their mail. They find lots of interesting things there and spend maybe half an hour or so, and then return to your app. You won’t have run for 30 minutes and your TCP/IP connection may well have timed out.

There are ways to have your app run in the background, but not more than every 15 minutes. In the interest of battery life and minimising network traffic, in general when the user isn’t looking at your app then it ain’t running.

Offline working

How many times have you seen a little spinning ball or a message “Waiting for server” or a terse message “Can’t use this app as not online”? I don’t like these and I’m sure other users are equally unimpressed.

Gotcha 3: You have to work well offline

Windows 8 actually provides you with no excuse not to offer a decent offline experience – that’s the whole point of the promise mechanism. You set up a transaction of some sort and then allow the user to carry on working, interacting with your app. Of course this may cause another transaction to be queued, so you will need to keep track of the replies when they come back, but you’ll have a happy user.

Consider my favourite scenario. A user is sitting on the Tube, using your app to read messages or tasks and then making suitable replies. If they are between stations then there’s no signal, and they certainly don’t want to be confronted with a “Please wait” message once they have finished their first task. Instead they want to carry on through the list. As the train comes into a station the WiFi connection is made, the data waiting to be transmitted is sent and any new messages are uploaded. All in the background, automatically.

Quick and dirty debugging

You may well have used a quick alert(val) to find out what some value is taking – well surprise!

Gotcha 4: You can’t use alert()

There’s an alternative call to do this sort of thing which is asynchronous – create a new Windows.UI.Popups.MessageDialog with your text and then call the showAsync() method on the result. In order to make this work you have to handle the promise returned from showAsync() by calling the then() method on it. All your other Javascript code will continue to run while the user reads your message. Our old friend console.log works while you have Visual Studio around, but this isn’t any good if you want to detect an unexpected event in the wild.

You are not going to believe this

If you are still with me you aren’t going to believe the next bit, but trust me we have tested this extensively. If you are writing for a mobile device such as a Microsoft Surface then you can’t trust that network stalwart, TCP/IP, to deliver your data reliably.

Gotcha 5: You can’t trust TCP/IP

Hush while I hear that intake of breath. The man’s insane of course TCP/IP works. Well it does, very well, between two IP addresses. But devices that you can move around between WiFi hotspots (and cellular networks when that feature is provided) get a different IP address every time.

Consider sending an email. You press send inside your favourite WiFi enabled coffee shop, shut your Surface and head for the door. The mail program has probably had time to hand the data over to Windows 8 which will be using TCP/IP to send your message to your mail transfer agent. But the WiFi connection is busy and there’s lots of retries needed – normally you would only see this as a slow transfer. But you are already heading down the street and the IP address allocated to you by the coffee shop WiFi hub isn’t going to work until you go back there. In the meantime you head into work and get a new IP address. The TCP/IP connection between the mail program and the coffee shop will eventually time out, and the data remaining in the TCP/IP pipe will be lost.

Now in fact your mail program uses another protocol called SMTP on top of TCP/IP (mainly because it used to work over other protocols that weren’t reliable) and so that mail will remain unsent in your outbox and will be resent when you open your mail program again. But naked TCP/IP connections aren’t so forgiving, so we come to

Gotcha 6: You can’t trust Ajax

Say you set up a call to send data via Ajax to a server. The HTTP message is sent and you wait for the reply. Given the scenario outlined above you may well get a timeout error – possibly much later depending on various factors. Now what do you do? Perhaps the data was delivered to your web service and you lost the reply, but on the other hand it’s just as likely that the data didn’t get there – or more accurately all of the data didn’t get there.

So what do you do? Some badly written apps simply put up a message saying “Timeout error” and leave the poor sucker user to work out what happened. Of course you could automatically send the message again, and if you knew that there wouldn’t be any trouble by doing so then that’s normally a good idea. So if the web service included a transaction id, or was otherwise idempotent then this would be fine. But many web services calls will do something twice if you call them twice, and hence this leads to trouble when resending Ajax data from mobile devices. And of course if you don’t resend the message then you will risk losing transactions held in TCP/IP streams to old IP addresses that are slowly timing out.

The web service has a similar problem. It has data it was trying to send as the result of an Ajax call but the TCP/IP channel times out. There’s nothing much it can do with the data other than throw it away and hope that it can be recreated again. But that data might be important - the receipt for an online transaction that has taken place, for example.

Sending data

The problem is even trickier in the other direction, such as when a backend server wants to send data to a mobile via TCP/IP. Let’s say you have a multi-player game which is sharing co-ordinates of players over TCP/IP. You send some data which is held in buffers in the server’s OS trying to be sent to an IP address in a coffee shop somewhere. It’s never going to be delivered and the socket will eventually time out. Your backend system has to handle this situation gracefully and it’s tricky. It’s pointless attempting to re-open the communication channel as there’s no-one at home at the last IP address. It must wait for the app to notice and re-open the channel, possibly sending back a note about how far it had got in the data transfer allowing the server to re-send the data. But this in turn means the server has to keep all the data it has sent so that it can re-send it, and there’s no obvious way that such saved data can be deleted, so you end up re-creating something like SMTP.

But even now you haven’t solved the problem, because your app might be in the background, and as explained above, not running. Or even more likely, the device has turned off its radio to save energy or has completely gone to sleep. Say it’s a chess game and you want to send the move from an opponent. Even without the problem of TCP/IP not working when changing IP addresses you can’t send data to a program that isn’t running.

Gotcha 7: You can’t send data to a device

The solution is for you to arrange to send a push notification to the device via Windows Notification Service, which also requires for you to register the app and extract a special URL which you have to send back to your backend system, which then calls WNS. If you want to use Windows Phone 8 beware that there is another, different push notification system called Microsoft Push Notification Service that needs different values. And of course if you want to make a cross-platform app there’s three other different push mechanisms.

These push mechanisms are not guaranteed to be delivered but are the approved way of alerting the user that they need to run your app.


You will have seen by now that the environment for Windows Store apps is really very different to what you may have been used to. There are several challenges.

· Saving the battery and hence coping with not running when in the background

· Saving network charges by not polling unnecessarily

· Coping with different IP addresses, and hence unreliable TCP/IP

· Managing sending data to mobile devices that may be asleep

For more details on these issues and ways to provide reliable mobile messaging please visit

About the Author

Tim King  - CTO - 5app LtdDr Tim King is a veteran computer scientist: he gained his degree at Cambridge in 1976 and later in 1979 for his PhD he wrote a relational database when this was a new concept. In 1984 he got the chance to write the disk operating system for the Commodore Amiga and can hence claim that more than two million people have used his software. He went on to found Perihelion Software, working with early UK entrepreneurs at Inmos (remember the Transputer?). He then founded ISP UK Online and since selling that in 1996 he has been advising people on whether to invest in various high-tech ventures.

More recently he has spent his time experimenting with mobile phone technologies and is the founder and CTO of 5app, a company that provides a way for developers to create mobile apps that communicate reliably. Here he and his team have spent many happy hours driving phones around the South Wales valleys where he lives, discovering what really happens to your data as the connectivity comes and goes.

He can be contacted via his personal website at or the 5app website, via Twitter as @DrTimKing and linkedIn via