- Your First Windows Store App
- Getting Started in Visual Studio 2012
- Controls, Binding, and Styling in Blend
- Navigation
- Networking in WinJS and WinRT
- Split App Template
- The Rest
- Where Are We?
Getting Started in Visual Studio 2012
Visual Studio is the premiere tool for Microsoft developers building apps for the Web and Windows, and has been for quite a while. It provides project management for keeping your app’s source files together; integrated build, deployment, and launching support; HTML, CSS, JavaScript, graphics, and Windows Store app manifest editing and debugging; and a whole lot more. There are several editions of Visual Studio, but we’ll use Microsoft Visual Studio 2012 Express for Windows 8 (a.k.a. VS), which is available for free6 and includes everything you need to build, package, and deploy your Windows Store apps.
To show you Visual Studio 2012 in action, we’re going to need something more interesting to build than an app with a static message (no matter how inspirational it may be). Developers new to any platform seem to have canonical apps that they build: Computer science students build text editors, compiler writers build Pascal compilers, web programmers build blogs, and, for some reason, mobile platform developers build news readers. So, let’s build ourselves a little Really Simple Syndication (RSS) Reader and start from my favorite template: the Navigation App (as Figure 1.3 shows us doing).
Figure 1.3. Creating a Windows Store Navigation App in Visual Studio 2012
The Windows Store app project templates provided with Visual Studio 2012 are as follows:
- Blank App: This is pretty much the smallest Windows Store app you can build with the correct manifest and graphics files that includes the Windows Library for JavaScript (a.k.a. WinJS). This is a good template for when you’d like to start from scratch and build up.
- Grid App: This is a simple but complete Windows Store app with three pages, navigation support, and the Windows 8 look and feel. This is a good template for starting with a full app that you’d like to modify.
- Split App: This is like the Grid App but with two different pages.
- Fixed Layout App: This is just like the Blank App template except that it allows you to build an app in a fixed-size area, like a casual game at 1024 × 768, and let Windows scale it up or down for you, based on the available space.
- Navigation App: This template is the core of both the Grid and Split App templates, except with a single blank page instead of a set of fully functioning pages. This template gives you the navigation support you often want in your apps, but it also lets you build up largely from scratch.
Running the Navigation App template produces a Visual Studio 2012 Windows Store app project file for JavaScript (.jsproj) along with nearly the same set of files used to create our first sample, as Figure 1.4 shows.
Figure 1.4. The files generated by the Visual Studio 2012 Windows Store Navigation App project template
The format and the contents of the package.appxmanifest file are the same as the .appxmanifest.xml file we’ve already seen, but the .appxmanifest extension allows the file to have a custom editor in Visual Studio 2012, as Figure 1.5 shows.
Figure 1.5. The Visual Studio 2012 Manifest Designer
The manifest editor gives you a much easier way to edit the metadata associated with your app than getting all of the angle brackets right in the raw XML file.
The other interesting artifact added to the project is the Windows Library for JavaScript SDK reference. This brings in a reference to WinJS, a set of JS libraries produced by Microsoft to bring together the web platform; that is, HTML5, JavaScript, and CSS, with WinRT to make for a productive app framework for Windows Store apps built with JavaScript. You’ll see a lot of both WinJS and WinRT in this book, but to get you started, take a look at the default.html file generated by the Navigation App template:
<!DOCTYPE html>
<!-- default.html -->
<html>
<head>
<meta charset="utf-8" />
<title>
RssReader</title>
<!-- WinJS references -->
<link href="//Microsoft.WinJS.1.0/css/ui-dark.css" rel="stylesheet" />
<script src="//Microsoft.WinJS.1.0/js/base.js"></script>
<script src="//Microsoft.WinJS.1.0/js/ui.js"></script>
<!-- RssReader references -->
<link href="/css/default.css" rel="stylesheet" />
<script src="/js/default.js"></script>
<script src="/js/navigator.js"></script>
</head>
<body>
<div id="contenthost" data-win-control="Application.PageControlNavigator"
data-win-options="{home: '/pages/home/home.html'}"></div>
</body>
</html>
In the head section of the HTML, you’ll notice the link and script elements that reference the styles and JS files that provide the functionality of WinJS. Part of that functionality is parsing the data-win-control and data-win-options attributes on the contenthost div toward the bottom of the file.
The data-win-control and data-win-options7 attributes enable declarative controls in Windows Store apps, essentially turning the HTML div element into an instance of a PageControlNavigator control from the RssReader namespace defined with this project. The data-win-options attribute is a simple JavaScript Object Notation (JSON) object passed to the control at runtime as constructor arguments. This declarative syntax allows programmers to easily lay out their controls using either the text editor built into Visual Studio 2012 or, as we’ll soon see, using visual tools.
In the case of the PageControlNavigator control, what’s happening is that the default.html file is really just a host for one or more logical pages that are loaded as your users navigate from one page to another. And, as you can see in the options for the control, the first page to be loaded is homePage.html, which the Navigation App template also generates:
<!DOCTYPE html>
<!-- homePage.html -->
<html>
<head>
<meta charset="utf-8" />
<title>homePage</title>
<!-- WinJS references -->
<link href="//Microsoft.WinJS.1.0/css/ui-dark.css""
rel="stylesheet" />
<script src="//Microsoft.WinJS.1.0/js/base.js"></script>
<script src="//Microsoft.WinJS.1.0/js/ui.js"></script>
<link href="/css/default.css" rel="stylesheet" />
<link href="/pages/home/home.css" rel="stylesheet" />
<script src="/pages/home/home.js"></script>
</head>
<body>
<!-- The content that will be loaded and displayed. -->
<div class="fragment homepage">
<header aria-label="Header content" role="banner">
<button class="win-backbutton" aria-label="Back" disabled
type="button"></button>
<h1 class="titlearea win-type-ellipsis">
<span class="pagetitle">
Welcome to RssReader!</span>
</h1>
</header>
<section aria-label="Main content" role="main">
<p>
Content goes here.</p>
</section>
</div>
</body>
</html>
The HTML in homePage.html is a little bit more complicated than in default.html because it provides a Back button, a title, and a section making it pretty clear where Microsoft recommends that you put your content. In addition, the generated HTML pulls in the homePage.js file, which is where you put the logic that governs how the home page for your app is going to function. The generated skeleton code looks like this:
// home.js
(function
() {"use strict"
; WinJS.UI.Pages.define("/pages/home/home.html"
, {// This function is called whenever a user navigates to this page.
// It populates the page elements with the app's data.
ready:function
(element, options) {// TODO: Initialize the page here.
} }); })();
The code inside homePage.js is wrapped in a self-executing, anonymous function, which is a JavaScript trick to keep everything in the function from leaking into global scope, providing the JavaScript equivalent of a private module. The "use strict" string is the JavaScript way of adding extra error checking at runtime, which is another good practice.8
Inside the module, the skeleton code provides a definition of a page control based on the ready function and the path to the HTML file associated with the page. A WinJS control is a reusable set of UI and behavior, whereas a page control is a control created around a logical page of HTML. The navigation support in the Windows Store app templates simply loads and unloads page controls as the user navigates between pages.
The ready event is fired when the page control is added to the HTML Document Object Model (DOM) and it’s an excellent place for us to show a list of feeds for our RSS Reader:
// home.js
...// define the feeds
window.feeds = [ { title:"Brandon Satrom"
, url:"http://feeds.feedburner.com/userinexperience/tYGT"
}, { title:"Chris Sells"
, url:"http://sellsbrothers.com/posts/?format=rss"
}, { title:"Channel 9"
, url:"http://channel9.msdn.com/Feeds/RSS"
}, ]; WinJS.UI.Pages.define("/pages/home/home.html"
, { ready:function
(element, options) {// show the feeds
var
section = element.querySelector("section"
); section.innerHTML =""
; feeds.forEach(function
(feed) {var
div = document.createElement("div"
); div.innerText = feed.title; section.appendChild(div); }); } }); ...
The ready function is passed the div that presents the page in the HTML DOM via the element argument, so it’s a good place to do a query for the section element to hold our list of feeds. The code inside the ready function is standard HTML DOM manipulation code using the global feeds data defined above the function.
Running the app provides a full-screen Windows Store app that looks like Figure 1.6.
Figure 1.6. A list of feed titles in a Navigation App template project
If, in the process of developing this slightly functional app, you find yourself with issues, you can debug your app using Visual Studio 2012 by choosing Debug | Start Debugging, which gives you the following debugging tools:
- Debugger: Set breakpoints, use the various step debugger commands, and watch JavaScript data and behavior.
- JavaScript Console: Interact with JavaScript objects at a command line.
- DOM Explorer: Dig through the HTML DOM and see styles by element.
- Call Stack: Drill into the current JavaScript call stack.
- Exceptions dialog: Turn on the option to break when a JavaScript runtime exception is thrown.
In addition to debugging your app on the local machine (which is the default), you have two other options: remote machine and the simulator. You can change these options by choosing Project | Properties and selecting the debugger to launch, as Figure 1.7 shows.
Figure 1.7. Choosing to debug against the local machine, the simulator, or a remote machine
The idea of remote machine debugging is that you can develop on a high-powered developer machine but debug on a more modest consumer-grade machine, like a tablet. This is handy to make sure your app works well on the type of machine you’re targeting.
The simulator option, on the other hand, creates a remote desktop session back to the machine on which you’re already running, providing a frame that lets you simulate various resolutions, landscape/portrait rotations, and touch, even if you’re not using a touch-capable device. Figure 1.8 shows our sample app running in the simulator.
Figure 1.8. A Windows Store app running in the simulator
And, as if that weren’t enough, Visual Studio 2012 is not the only tool you get when you install Visual Studio 2012 Express for Windows 8. If you’d like a WYSIWYG design experience for the visual portion of your app, you’ve got Microsoft Blend for Visual Studio 2012 (a.k.a. Blend).