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: }

12:

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!

Issues with loading and unloading CSS and Javascript files when performing page navigation in Windows Store apps

If you are a web developer, the way navigation works in Windows Store apps might look familiar to you, but unless you have some experience developing mobile apps, it probably isn't something you’ve encountered before. This especially applies to those developers whose background lies in developing multi-page web sites and applications.

But the way Windows Store apps are structured (or at least, the way they should be) is in the form of single-page application and their navigation model is tailored for this type of page structure. So, how does it work?

It is simple actually, whenever you navigate to a page, that page's respective html, css and javascript files will get loaded. As you move away from the page, its html is cleared from the DOM, but the css and javascript files remain loaded. Why is that?

The reason for that is to preserve the global namespace and context, by loading the necessary css and js files only once, so there is no room for all kinds of bugs and frustrations that might come as a result of inconsistency of global context.

But how do I know which files are getting higher priority over the other files?

Once again, the answer is simple. The last file to get loaded by the rendering engine has the highest priority and can potentially override older files. And this is something that can produce whole lot of bugs and issues, so here are couple of advices on how to prevent that from happening and how to solve it.

When it comes to Javascript, you’ve probably heard this before. Global namespace is evil and you should always write your namespaces and modules, so you could organize your code and avoid pollution of global namespace. The importance of this is explained extensively and I am not going to explain it here. But you really should do it, since it can lead to unimaginable frustrations.

But when we speak about css, things can get quite messy. As I said, as you navigate from page to page, css files are getting loaded and will stay loaded, even if you navigate away from the page. And this can get troublesome. Imagine this scenario:

You have page A that can navigate to Page B. When you start your app, your page A is loaded, with its pageA.html, pageA.css and pageA.js files. Then you navigate to page B, and pageB.html, pageB.css and pageB.js files will also get loaded. Now you move back to the page A and you expect that page B files got unloaded. But they didn’t just remain loaded, they also have higher priority over pageA.css and pageA.js files. What this means is that, in case you have conflicting css clauses in the respective css files, css clauses from page B will override css from Page A and mess up the appearance of page A completely.

So, how do we go around this?

There are couple of solutions. You might dynamically load and unload css files with javascript (by including and excluding script tags), but that paves a way for additional bugs and it isn’t a way I would recommend. What you should do is to write all the general css in the main file (default.css or whatever is the container for the other pages). But when there is a need for you to write page specific css, you should write it in that page’s respective css file and make sure that css applies only to that page. One of the ways this can be done is to use additional css selector, which is unique to that page and put it in front of every page specific css that you write. Something like this:
pageB button { display:block; }

That element with pageB class can be a simpl div>, that would act as the main wrapper over your page’s html code.

This is handy because, in case we wrote that css statement without the class selector, it would apply to all the buttons in your app and could wreak a havoc on your layout. This way, it applies only on Page B and won’t affect the buttons in page A, even if you do the navigation to Page B and return to A.

It is not the toughest concept out there to grasp, but it can lead to some serious problems and frustrations. So, when you write a Windows Store app using HTML and Javascript, make sure that you do not write conflicting code. When you mess it up with css, you’ll easily notice, because your page’s appearance will get wrecked. But if you write conflicting javascript code, then may the mercy be on your soul.

Welcome to Ghost

You're in! Nice. We've put together a little post to introduce you to the Ghost editor and get you started. Go ahead and edit this post to get going and learn how it all works!

Getting Started

Writing in markdown is really easy. In the left hand panel of Ghost, you simply write as you normally would. Where appropriate, you can use formatting shortcuts to style your content. For example, a list:

  • Item number one
  • Item number two
    • A nested item
  • A final item

or with numbers!

  1. Remember to buy some milk
  2. Drink the milk
  3. Tweet that I remembered to buy the milk, and drank it

Want to link to a source? No problem. If you paste in url, like http://ghost.org - it'll automatically be linked up. But if you want to customise your anchor text, you can do that too! Here's a link to the Ghost website. Neat.

What about Images?

Images work too! Already know the URL of the image you want to include in your article? Simply paste it in like this to make it show up:

The Ghost Logo

Not sure which image you want to use yet? That's ok too. Leave yourself a descriptive placeholder and keep writing. Come back later and drag and drop the image in to upload:

Quoting

Sometimes a link isn't enough, you want to quote someone on what they've said. It was probably very wisdomous. Is wisdomous a word? Find out in a future release when we introduce spellcheck! For now - it's definitely a word.

Wisdomous - it's definitely a word.

Working with Code

Got a streak of geek? We've got you covered there, too. You can write inline <code> blocks really easily with back ticks. Want to show off something more comprehensive? 4 spaces of indentation gets you there.

.awesome-thing {
    display: block;
    width: 100%;
}

Ready for a Break?

Throw 3 or more dashes down on any new line and you've got yourself a fancy new divider. Aw yeah.


Advanced Usage

There's one fantastic secret about Markdown. If you want, you can write plain old HTML and it'll still work! Very flexible.

That should be enough to get you started. Have fun - and let us know what you think :)