I am currently playing around with WinRT JavaScript applications. Starting out with a navigation application written from scratch, just to find out how it all fits together. The MSDN library is actually quite scarce when it comes to resources on WinRT. They give you the overall picture of how Metro style apps work, but, for JavaScript applications, the actual information is a bit meager. So I thought it would be nice to dissect a Metro style navigation app and see what code you need to get it up and running. Also beware that the information I will be giving here is based on the first developer preview of Windows 8 and Visual Studio 2011 Express Edition. Things are still very likely to change in the next couple of months.
What I did, was create two Metro style JavaScript applications, one based on a blank project template and one based on the navigation application project template. Let's first see what the navigation application gives us.
When you look at the project of the navigation application, you will see it gives you a couple of predefined html, JavaScript and css files. There are two html files present, a default.html and a homepage.html file. First let's take a look at the homepage.html file. In the head section it includes the JavaScript files you find in the solution, so nothing new or fancy there. In the body there is a div defined with content.
<!-- The content that will be loaded and displayed. -->
<div class="fragment homePage">
<header role="banner" aria-label="Header content">
<button disabled class="win-backbutton" aria-label="Back"></button>
<div class="titleArea">
<h1 class="pageTitle win-title">Welcome to NavApp!</h1>
</div>
</header>
<section role="main" aria-label="Main content">
<p>Content goes here.</p>
</section>
</div>
The main div has a couple of classes defined on it, fragment and homePage. The fragment class we will come back to later on, when we take a look at the JavaScript files of the project. Just remember that it's there on the main div of the homepage.
Within the main div there is a header tag defined. This shows that WinRT JavaScript applications make use of new HTML5 features. The header tag has a role attribute, with a value of banner. There is also a role defined on the section tag a bit further down the homepage, with a value of main. These role attributes are primarily used as selectors in the css and JavaScript files. There is no real functionality associated with them.
The last peculiar attribute values can be found on the button and the h1 tags. Their classes are set to win-backbutton and to win-title respectively. With WinRT JavaScript applications you will find there are a lot of these win-something attribute values. You would think these give you out of the box functionality. Well, they don't. You will find that all magic is really just JavaScript doing it's thing. Those win-something attributes again, are just selectors for the css and JavaScript files. When you run the appication, you will see that the win-backbutton is actually an arrow with a circle around it. That's just plain css:
.win-backbutton::before
{
font-family: "Segoe UI Symbol";
content: "\E0D5";
vertical-align: 50%;
}
So, let's take a look at the default.html page. The header again is just JavaScript and css file includes. The body is more interesting.
<body data-homePage="/html/homePage.html">
<div id="contentHost"></div>
<div id="appbar" data-win-control="WinJS.UI.AppBar" aria-label="Command Bar" data-win-options="{position:'bottom', transient:true, autoHide:0, lightDismiss:false}">
<div class="win-left">
<button id="home" class="win-command">
<span class="win-commandicon win-large"></span><span class="win-label">Home</span>
</button>
</div>
</div>
</body>
There is a data-homePage attribute on the body tag and it is set to our homePage.htm file. You will also find a contentHost and appbar div. The contentHost makes you suspect that the default.html page is actually the start page of your application and that other html pages will actually be loaded as fragment into it. That is indeed the case here. But then, why, as you run the application, don't I see the appbar that is defined at the bottom. You do get to see all the content of the homePage, but the appbar is nowhere in site. The reason is that, to see the appbar, you need to swipe up, or, if that doesn't work on your device, perform a right mouse click. There's the appbar for you.
So, where does all the magic happen? In the JavaScript files of course. Let's first take a look at the default.js file. There are a couple of functions defined here. Let's not start at the top, but at the bottom.
WinJS.Navigation.addEventListener('navigated', navigated);
WinJS.Application.start();
An eventlistener for the navigated event gets added and the application is started. That's simple, right. Right above these two statements we find the handler for activating the mainwindow.
WinJS.Application.onmainwindowactivated = function (e) {
if (e.detail.kind === Windows.ApplicationModel.Activation.ActivationKind.launch) {
homePage = document.body.getAttribute('data-homePage');
document.body.addEventListener('keyup', function (e) {
if (e.altKey) {
if (e.keyCode === WinJS.Utilities.Key.leftArrow) {
WinJS.Navigation.back();
}
else if (e.keyCode === WinJS.Utilities.Key.rightArrow) {
WinJS.Navigation.forward();
}
}
}, false);
WinJS.UI.process(document.getElementById('appbar'))
.then(function () {
document.getElementById('home').addEventListener('click', navigateHome, false);
});
WinJS.Navigation.navigate(homePage);
}
}
This code says as much as, when we launch the application, do the following things:
- Our homepage is set to the attribute value of the data-homePage attribute of the body element.
- If a user presses the alt key and the left or right button, navigate forward and backward.
- Find the appbar and attach a click handler to the home element. The navigateHome function is defined at the top of the JavaScript file and contains pretty straightforward code.
- And last, but not least, navigate to the homePage.
Right abobe this function, you will find another function definition.
function navigated(e) {
WinJS.UI.Fragments.clone(e.detail.location, e.detail.state)
.then(function (frag) {
var host = document.getElementById('contentHost');
host.innerHTML = '';
host.appendChild(frag);
document.body.focus();
var backButton = document.querySelector('header[role=banner] .win-backbutton');
if (backButton) {
backButton.addEventListener('click', function () {
WinJS.Navigation.back();
}, false);
if (WinJS.Navigation.canGoBack) {
backButton.removeAttribute('disabled');
}
else {
backButton.setAttribute('disabled', 'true');
}
}
WinJS.Application.queueEvent({ type: 'fragmentappended', location: e.detail.location, fragment: host, state: e.detail.state });
});
}
This tells us what happens when we navigate (remember, the previous function actually navigated to the homePage, so this gets called at the start of the application).
- It clones the current fragment state (I am guessing this remembers where we are coming from and in what state the page is at the moment).
- And, hey, next bit is some asynchrony. After the cloning is done, a function gets executed for the fragment.
- It finds the contentHost on the default.html page and appends the fragment to it. There you have masterview (default.html)- detailview (homePage.html) behavior.
- The backbutton also gets some extra functionality. Based on the fact whether we can go back or not, the button gets disabled or enabled and the click handlers get attached.
- Last bit is queuing the fact that the fragment got appended, so the WinRT runtime can do its thing.
On the one hand, that's all simple JavaScript code. On the other hand, if you are used to working with the regular .NET languages, this seems like quite some code you need to write for some basic functionality.
Let's find out, in a next post, what we need to do to navigate to a new page in our application.
