Building Windows 8 Applications with JavaScript and HTML

Learn everyting you need to know to get started building Windows 8 JavaScript applications(Based on Windows 8 RTM).
Course info
Rating
(186)
Level
Beginner
Updated
Nov 13, 2012
Duration
4h 29m
Table of contents
Introduction
Application and Page Lifecycle
Namespaces
Navigation
Binding and Model View ViewModel
Layout
Controls
State Management
Using Managed Libraries and Components
Description
Course info
Rating
(186)
Level
Beginner
Updated
Nov 13, 2012
Duration
4h 29m
Description

Learn how to build Windows Store applications on top of the WinJS platform with JavaScript and HTML. Get acquainted with the design philosophy of the Modern UI and how it affects the design of your application. Work with existing and new WinJS controls to provide interaction, learn how to respond to layout orientation and view state changes. Learn the distinctions between traditional web development and WinJS development, and see how to take existing .NET development skills and apply them to Window Store applications.

About the author
About the author

Craig Shoemaker is a developer, instructor, writer, podcaster, and technical evangelist of all things awesome.

More from the author
HTML5 Fundamentals
Beginner
3h 47m
Mar 3, 2017
jQuery: Getting Started
Beginner
1h 40m
Jun 3, 2015
More courses by Craig Shoemaker
Section Introduction Transcripts
Section Introduction Transcripts

Application and Page Lifecycle
As I said in the introduction, one of the foundations required for a proper understanding of Windows Store applications are the concepts of application and page lifecycle. The lifecycle is particularly important in some of the design decisions that you make on how your application will behave when users first launch the app, as well as when they move on to other applications and then return. Further, you need to account for what happens when the system needs to shut down the app in the background. To make sense of what's happening during the lifecycles, you first must have an understanding of what some of the different ways the user, as well as the system, interact with Windows Store applications. Obviously, some of the time, the applications are started or activated by a user explicitly opening them. But there are other ways in Windows 8 of how these apps are started. The operating system makes the distinction between two different types of programmatic interaction with your app, which are extensions and contracts. Extensions are a way of extending Windows and allowing your application to tap into an array of extensibility points, of VOS. For instance, the protocol activation extension allows your application to register for a certain protocol scheme and launch when that scheme is run in the system. Contracts, on the other hand, are extensibility points between your application and other apps or the operating system. The contract behaves much like an interface in object oriented environments. The contract is an agreement by the source and the target to do things like share data, facilitate searching and the like. Now that you have some familiarity with extensions and contracts, the application lifecycle as a whole will make more sense in context.

Namespaces
The WinJS library adds support for namespaces in JavaScript. Now, if you come from a traditional dot net background, may be use to namespaces as being an inherent part of the language. But namespaces are not native to JavaScript and are implemented with an accompanying API in WinJS. But first, what is a namespace? Well, it's a logical named container for a set of classes or functions. Basically, namespaces make it easy to organize and discover code in your application. To make sense of one of the biggest reasons of why namespaces are even necessary, you need to first understand how scripts in a Windows store JavaScript application are often constructed. The Windows store apps make pervasive use of self-executing modules, and what you see on the slide here is an example of a self-executing module. The module pattern creates a logical container around variables, functions, and objects within JavaScript. So the container is implemented as a module, and it scopes the content to itself. Therefore, what's defined inside the containers are inaccessible to code outside the module, making building a fully-fledged application difficult. But, really, this is a good thing because the containment prevents us as development from polluting the global namespace and facing issues where libraries collide due to variable name overlaps or variables being mismanaged. So namespaces do the work of exposing the public APIs of modules created throughout the system, and that's something even fist-pump baby can get behind. Beyond just granting the access to the API, namespaces are composable, which means you can split different modules that are included in namespaces into different physical locations, as well as guarding against destroying existing objects even if they are redefined. And in this world of asynchronicity (assumed spelling), which Windows store applications are, that can be a very valuable piece of functionality.