Understanding message dialogs in Windows Store apps and issues they might create.

Displaying popups is something you can’t avoid while developing Windows Store apps. No matter what kind of app you are developing, you’ll always have to notify your users about something when it comes to their interaction with your app. If you are a Javascript developer, you probably got used to displaying alerts in your web app, but when it comes to Windows Store app, alert() method won’t work. Many people would assume that alert() method is native Javascript method, but it is not. It is a method provided by the browser, so you can expect to use it in Windows Store apps. Hopefully, there is a quite simple alternative.

1: var popup = Windows.UI.Popups.MessageDialog(message, messageTitle);

2: popup.showAsync();

But, who would assume that such a simple API could potentially cause many frustration and app crashes? Yes, it is more than capable of crashing your app and if you are not familiar with the way it is implemented, you might have a really bad time. So, what the catch?

showAsync() is an obvious pointer that this method is executed asynchronously. And if you played with Windows Store apps before, you probably know that asynchronous calls are handled with Promise pattern. So, once this method is executed, it will return a promise object and application will continue working, regardless if the popup shows up or not. That’s totally expectable, given its asynchronous nature. But in case you try to display another popup, on top of this one (without doing it the “promise” way), your app is going down. It will crash and show you “access denied” error . If you don’t want that to happen, you’ll have to understand how promises work and how you should chain your async calls. That’s something that I am going to assume that you know, but in case you don’t, here you go.

So, if you want to display a new popup after you displayed one already, you’ll have to do it through the .then() or done() method (depending on how many calls you want to chain) and things will work fine. But there are number of scenarios when you can’t anticipate that your popups are going to appear simultaneously, or on top of each other, or you can’t chain them properly. For example, imagine this scenario.

You have some kind of twitter like app that lets users write some messages that other users can see. So, when implementing it, you’ll have methods like, writeMessage() and readMessages(). First one will contain the functionality of writing a new message and second one will display all the messages that are written before. And if you are doing things the right way, you’ll also have a checkConnection() method that checks for internet connection.

So, you’ll have something like this:

1: function writeMessage()

2: {

3: if(checkConnection())

4: {

5: //write message

6: }

7: else

8: {

9: showPopup("No connection","Error");

10: }

11: }


13: function readMessages()

14: {

15: if(checkConnection())

16: {

17: //read messages

18: }

19: else

20: {

21: showPopup("No connection","Error");

22: }

23: }

So far, it is fine. Now, when you want to send your message, you do this:

1: writeMessage();

2: readMessages(); // displays your message with other messages after you write it

Still fine… But what happens in case the connection dies?

You’ll get two popups telling you so, one from writeMessage() and one from readMessages(). And your app will crash, because you can display only one at a time. But since you can’t properly chain them via promise pattern, you have to go for the alternatives.

First of all, you can avoid chaining your popups by changing the architecture of your code. Also, you can implement some kind of popup tracking mechanism, so you can know when you are safe to display a popup. And finally, you can put your popups in try/catch block.

So, there it is. Really simple thing, but if you don’t understand how it works, you can get quite frustrated. So, try not to overuse the message dialogs and show them only when necessary. And besides having the potential of crashing your app if not handled properly, users can find them very annoying.

Happy coding!