Switch the guide to use the fetch() API and various small changes

getting-started/chapter-1.md

@@ -114,7 +114,7 @@ tns run android --emulator
 
 > **WARNING**:
 > * You must have at least one Android AVD (Android Virtual Device) configured for this command to work. If you get an error, try [setting up an AVD](https://www.genymotion.com/#!/) and then run the command again.
-> * If you're using Genymotion, launch your Genymotion virtual device, and then run `tns run android --emulator --geny`. 
+> * If you're using Genymotion, launch your Genymotion virtual device, and then run `tns run android`.
 
 If all went well, you should see your app running in an Android emulator:
 
@@ -167,7 +167,7 @@ E/TNS.Native( 2063): File: "/data/data/org.nativescript.groceries/files/app/./vi
 If you find continuously running `tns run` from the terminal to be tedious, you may be interested in trying one of the following workflows:
 
 * The `tns livesync` command instantly transfers XML, CSS, and JavaScript files to a running NativeScript app. If you set the command's `--watch` flag (`tns livesync ios --emulator --watch` or `tns livesync android --emulator --watch`), the NativeScript CLI will watch your app for changes, and apply those changes automatically after you save files. Be warned, however, that the `livesync` command currently does not show `console.log()` output or stack traces. So during debugging you may want to switch back to `tns run`.
-* For Sublime Text users, [this build script](http://developer.telerik.com/featured/a-nativescript-development-workflow-for-sublime-text/) lets you type `Cmd`/`Ctrl` + `B` to start a build without returning to the terminal. (This is the workflow used for this guide.)
+* For Sublime Text users, [this build script](http://developer.telerik.com/featured/a-nativescript-development-workflow-for-sublime-text/) lets you type `Cmd`/`Ctrl` + `B` to start a build without returning to the terminal.
 * Emil Öberg's [nativescript-emulator-reload npm module](https://github.com/emiloberg/nativescript-emulator-reload) adds a Gulp watcher that relaunches the emulator after every change you make.
 
-Now that you have created an app, configured your environment, and set up your app to run on iOS and Android, you're ready to start digging into code.
+Now that you've created an app, configured your environment, and set up your app to run on iOS and Android, you're ready to start digging into the files that make up a NativeScript app.

getting-started/chapter-2.md

@@ -13,6 +13,8 @@ To keep things simple, let's start by looking at the outer structure of the Groc
 └── sample-Groceries
  ├── app
  │ └── ...
+ ├── node_modules
+ │ └── tns-core-modules
  ├── package.json
  └── platforms
  ├── android
@@ -22,10 +24,12 @@ To keep things simple, let's start by looking at the outer structure of the Groc
 Here's what these various files and folders do:
 
 - **app**: This folder contains all the development resources you need to build your app. You'll be spending most of your time editing the files in here.
+- **node_modules**: This folder contains your app's npm module dependencies. All new NativeScript projects start with a single dependency on tns-core-modules.
+- **node_modules/tns-core-modules**: This folder contains your app's NativeScript modules, which are a series of NativeScript-provided JavaScript modules you'll use to build your app. Each module contains the platform-specific code needed to implement some feature—the camera, http calls, the file system, and so forth—exposed through a platform-agnostic API (e.g. `camera.takePicture()`). We'll look at some examples momentarily.
 - **package.json**: This file contains your app's configuration details, such as your app id, the version of NativeScript you're using, and also which npm modules your app uses. We'll take a closer look at how to use this file when we talk about using npm modules in [chapter 5](#plugins-and-npm-modules).
 - **platforms**: This folder contains the platform-specific code NativeScript needs to build native iOS and Android apps. For example in the `android` folder you'll find things like your project's `AndroidManifest.xml` and .apk executable files. Similarly, the `ios` folder contains the Groceries' Xcode project and .ipa executables. Note, users on Windows machines will not have an `ios` folder.
 
-The NativeScript CLI manages the `platforms` folder for you as you develop and run your app; it's a best practice to treat the `platforms` folder as generated code. The Groceries app includes the `platforms` folder in its `.gitignore` to exclude its files from source control.
+The NativeScript CLI manages the `platforms` folder for you as you develop and run your app; therefore, it's a best practice to treat the `platforms` folder as generated code. The Groceries app includes the `platforms` folder in [its `.gitignore`](https://github.com/NativeScript/sample-Groceries/blob/master/.gitignore) to exclude its files from source control.
 
 Next, let's dig into the `app` folder, as that's where you'll be spending the majority of your time.
 
@@ -38,8 +42,6 @@ Next, let's dig into the `app` folder, as that's where you'll be spending the ma
  │ │ └── iOS
  │ ├── shared
  │ │ └── ...
- │ ├── tns_modules
- │ │ └── ...
  │ ├── views
  │ │ └── login
  │ │ ├── login.js
@@ -53,7 +55,6 @@ Here's what these various files and folders do:
 
 - **App_Resources**: This folder contains platform-specific resources such as icons, splash screens, and configuration files. The NativeScript CLI takes care of injecting these resources into the appropriate places in the `platforms` folder when you execute `tns run`.
 - **shared**: This folder, specific to the Groceries app, contains any files you need to share across views in your app. In the Groceries app, you'll find a few view model objects and a `config.js` file used to share configuration variables like API keys.
-- **tns_modules**: This folder contains the NativeScript-provided modules you'll use to build your app. Each module contains the platform-specific code needed to implement some feature—the camera, http calls, the file system, and so forth—exposed through a platform-agnostic API (e.g. `http.getJSON()`). We'll look at some examples momentarily.
 - **views**: This folder contains the code to build your app's views, each of which will have a subfolder in `views`. Each view is made up of an XML file, a JavaScript file, and an optional CSS file. The groceries app contains three folders for its three views.
 - **app.css**: This file contains global styles for your app. We'll dig into app styling in [section 2.3](#css).
 - **app.js**: This file sets up your application's starting module and initializes the app.
@@ -179,7 +180,7 @@ Let's start by adding a few application-wide CSS rules.
  <b>Exercise</b>: Create global styles
 </h4>
 
-Paste the following code in `app.css` file:
+Paste the following code in the `app.css` file:
 
 ``` CSS
 Page {
@@ -233,7 +234,7 @@ Let's break down what just happened. First, NativeScript supports CSS's `@import
 
 There's one other change here we need to discuss, and that's the `cssClass` attribute you added to this button:
 
-```
+``` XML
 <Button text="Sign up for Groceries" cssClass="link" />
 ```
 

getting-started/chapter-3.md

@@ -23,21 +23,21 @@ Let's look at what you can do in a code-behind file with a simple example.
 Open `login.xml` and add a `loaded` attribute to the `<Page>` UI component at the top. It should look like this:
 
 ``` XML
-<Page loaded="load">
+<Page loaded="loaded">
 ```
 
-Next, paste the code below in `app/views/login/login.js` to define a `load()` function:
+Next, paste the code below in `app/views/login/login.js` to define a `loaded()` function:
 
 ``` JavaScript
-exports.load = function() {
+exports.loaded = function() {
  console.log("hello");
 };
 ```
 <div class="exercise-end"></div>
 
-> **NOTE**: The keyword `exports` is part of [CommonJS](http://wiki.commonjs.org/wiki/Modules/1.1), the standard on which both NativeScript and Node.js' implementations of modules are based. In CommonJS-based JavaScript modules, a free variable called `exports` is an object to which a module might add properties and methods to configure its external API. Using `exports` in a code-behind file exposes the function for use in the view, or XML file. That is, the `exports.load` assignment in the code-behind file is what makes `loaded="load"` in the view work.
+> **NOTE**: The keyword `exports` is part of [CommonJS](http://wiki.commonjs.org/wiki/Modules/1.1), the standard on which both NativeScript and Node.js' implementations of modules are based. In CommonJS-based JavaScript modules, a free variable called `exports` is an object to which a module might add properties and methods to configure its external API. Using `exports` in a code-behind file exposes the function for use in the view, or XML file. That is, the `exports.loaded` assignment in the code-behind file is what makes `loaded="loaded"` in the view work.
 
-When you run the app with this change, NativeScript triggers the `load()` function you created in the code-behind file, and you should see the word “hello” logged in your terminal.
+When you run the app with this change, NativeScript triggers the `loaded()` function you created in the code-behind file, and you should see the word “hello” logged in your terminal.
 
 ![](img/cli-getting-started/chapter3/terminal-1.png)
 
@@ -142,16 +142,16 @@ var email;
 
 > **NOTE**: This line of code imports the [view module](/ApiReference/ui/core/view/View.html), which is the base class for all UI components. The module provides a lot of functionality, including the ability to control properties of a view and its children. You're going to use it to get access to the email text field.
 
-Next, edit the `load()` function in `login.js` to get a reference to the email address text field:
+Next, edit the `loaded()` function in `login.js` to get a reference to the email address text field:
 
 ``` JavaScript
-exports.load = function(args) {
+exports.loaded = function(args) {
  var page = args.object;
  email = viewModule.getViewById(page, "email_address");
 };
 ```
 
-There are two things to note here. First, because the `load()` function handles the page's `loaded` event, NativeScript passes it a reference to the `<Page>` in the function's argument, which is named `args` by convention. Second, you use the view module's [`getViewById()`](/ApiReference/ui/core/view/View.html) function to get a reference to the text field component.
+There are two things to note here. First, NativeScript passes `loaded` event handlers a reference to the `<Page>` in the function's argument, which is named `args` by convention. Second, you use the view module's [`getViewById()`](/ApiReference/ui/core/view/View.html) function to get a reference to the text field component.
 
 Finally, edit the `signIn()` function to log the contents of the text field:
 
@@ -198,10 +198,10 @@ var user = new observableModule.Observable({
 });
 ```
 
-Now, replace the existing `load()` function with the one below, which sets `user` as the binding context for the page.
+Now, replace the existing `loaded()` function with the one below, which sets `user` as the binding context for the page.
 
 ``` JavaScript
-exports.load = function(args) {
+exports.loaded = function(args) {
  var page = args.object;
  page.bindingContext = user;
 };
@@ -221,4 +221,4 @@ Simply put, properties placed on a page's binding context are available to XML e
 
 What's really cool is that the binding is two-way. Meaning, when the user types text in these text fields, those changes are immediately applied to your view model.
 
-To use these values, and to make this login functional by tying the your app into a backend service, you're going to need the ability to make HTTP calls. And to make HTTP calls in NativeScript you use the NativeScript http module. Let's look at how NativeScript modules work.
+To use these values, and to make this login functional by tying your app into a backend service, you're going to need the ability to make HTTP calls. And to make HTTP calls in NativeScript you use the NativeScript fetch module. Let's look at how NativeScript modules work.