Merge branch 'master' into myankov/merge-release-master

CodingConvention.md

@@ -205,7 +205,7 @@ let b = {"good": "code"
 
 ## Equality operator
 
-Use the [strict comparison operators][comparisonoperators]. The triple equality operator helps to maintain data type integrity throughout code.
+Use the [strict comparison operators][comparisonoperators]. The triple equality operator helps to maintain data type integrity throughout the code.
 
 *Right:*
 
@@ -341,8 +341,8 @@ the last row of a big room can comfortably read. So don't count on them having
 perfect vision and limit yourself to 1/2 of your screen height per function (no screen rotation :).
 
 ## Return statements
-There are few important considerations here:
+There are a few important considerations here:
-+ To avoid deep nesting of if-statements, always return a functions value as early
++ To avoid deep nesting of if-statements, always return a function's value as early
 as possible. In certain routines, once you know the answer, you want to return it to the calling routine immediately. If the routine is defined in such a way that it doesn't require any cleanup, not returning immediately means that you have to write more code.
 + Minimize the number of returns in each routine. It's harder to understand a routine if, reading it at the bottom, you're unaware of the possibility that it *return*ed somewhere above.
 
@@ -396,7 +396,7 @@ function getSomething(val) {
 
 ## Arrow Functions
 
-Use arrow functions over anonymous function expressions. Typescript will take care for `this`.
+Use arrow functions over anonymous function expressions. Typescript will take care of `this`.
 
 *Right:*
 
@@ -423,7 +423,7 @@ req.on("end", function () {
 
 Use the [JSDoc][JSDOC] convention for comments. When writing a comment always think how understandable will be for somebody who is new to this code. Even if it may look simple to you think how a guy that just joined will understand it. Always comment in the following cases:
 + When there is some non-trivial logic.
-+ Some "external" knowledge is needed which is missing in the context - workaround for driver, module bug, special 'hack' because of a bug and so on;
++ Some "external" knowledge is needed which is missing in the context - workaround for a driver, module bug, special 'hack' because of a bug and so on;
 + When you are creating a new class
 + Public methods - include all the arguments and if possible the types {String}, {Number}. Optional arguments should be marked too. Check the [@param tag][param]
 
@@ -432,7 +432,7 @@ Use the [JSDoc][JSDOC] convention for comments. When writing a comment always th
 
 ## File/module structure
 
-Typical module should have the following structure:
+A typical module should have the following structure:
 
 1. required dependencies
 2. module-private declarations - variables, functions, classes, etc.
@@ -442,7 +442,7 @@ Typical module should have the following structure:
 For more information see [this file](https://github.com/telerik/xPlatCore/blob/master/JS/BCL/CreateNewModule.md)
 
 ## File naming
-Use lower case for file names. Use dash to separate different words.
+Use lower case for file names. Use a dash to separate different words.
 
 *Right:*
 file-system
@@ -451,7 +451,7 @@ file-system
 FileSystem, fileSystem, file_system
 
 ## This, that, self
-When you **need** to keep reference to **this** use **that** as the name of the variable. Additionally, if you use the TypeScript lambda support, the compiler will take care of this automatically.
+When you **need** to keep a reference to **this** use **that** as the name of the variable. Additionally, if you use the TypeScript lambda support, the compiler will take care of this automatically.
 
 *Right:*
 ```TypeScript
@@ -470,7 +470,7 @@ doSomething(function(){
 ```
 
 ## Private (hidden) variables and methods
-Although there is the **private** keyword in TypeScript, it is only a syntax sugar. There is no such notation in JavaScript and everything is available to the users. Hence, always use underscore (**_**) to prefix private variables and methods. There are also methods which have the **public** visibility but they are meant to be used within our code ONLY. Such methods should also be prefixed with underscore.
+Although there is the **private** keyword in TypeScript, it is only a syntax sugar. There is no such notation in JavaScript and everything is available to the users. Hence, always use underscore (**_**) to prefix private variables and methods. There are also methods which have the **public** visibility but they are meant to be used within our code ONLY. Such methods should also be prefixed with an underscore.
 
 *Right:*
 ```TypeScript

WritingUnitTests.md

@@ -1,7 +1,7 @@
 # Writing Unit Tests for NativeScript Core Modules
 
 Unit tests for NativeScript Modules are written and executed with a custom lightweight test-runner and assertion framework.
-The purpose of this document is to get you familiar with it, so that you can unit-test your contributions to the NativeScript framework.
+The purpose of this document is to get you familiar with it so that you can unit-test your contributions to the NativeScript framework.
 
 # Run Unit Tests Project
 
@@ -19,7 +19,7 @@ tns run ios
 # Test Modules
 
 All unit tests are organized into test modules(bundles).
-By default the test app will run all the tests from all registered test modules. This happens in [`runTests()`](/tests/app/app/mainPage.ts#L26-L28) method in the main page of the test-app. By modifying this method, you can configure the app to:
+By default, the test app will run all the tests from all registered test modules. This happens in [`runTests()`](/tests/app/app/mainPage.ts#L26-L28) method in the main page of the test-app. By modifying this method, you can configure the app to:
 
 * **Execute only the tests from a specific test module**:
 
@@ -50,8 +50,8 @@ The test modules are actually TypeScript modules which export unit tests and hoo
 
 * All exported functions with a `test` prefix are unit-tests.
 * The `setUpModule()` hook is called once - before all the tests in the module.
-* The `setUp()` hook is called before each tests.
+* The `setUp()` hook is called before each test.
-* The `tearDown()` hook called after each tests.
+* The `tearDown()` hook called after each test.
 * The `tearDownModule()` hook is called once - after all the tests in the module.
 
 # Asserting
@@ -85,4 +85,4 @@ export function test_getJSON(done) {
 
 # Misc
 
-When looking into the code of the existing tests, you might encounter strange comments looking like this `// >> animation-chaining`. These are markers for code snippets generated in the docs documetation. They are not related to testing so you don't need to add any of those in your tests.
+When looking into the code of the existing tests, you might encounter strange comments looking like this `// >> animation-chaining`. These are markers for code snippets generated in the docs documentation. They are not related to testing so you don't need to add any of those in your tests.

tns-core-modules/application/application.d.ts

@@ -2,7 +2,9 @@
  * Contains the application abstraction with all related methods.
  * @module "application"
  */ /** */
+
 /// <reference path="../nativescript-error.d.ts" />
+/// <reference path="../tns-core-modules.d.ts" />
 
 import { NavigationEntry, View, Observable, EventData } from "../ui/frame";
 

tns-core-modules/ui/core/view/view.d.ts

@@ -2,6 +2,8 @@
  * @module "ui/core/view"
  */ /** */
 
+/// <reference path="../../../tns-core-modules.d.ts" />
+
 import { ViewBase, Property, InheritedProperty, EventData, Color } from "../view-base";
 import { Animation, AnimationDefinition, AnimationPromise } from "../../animation";
 import { HorizontalAlignment, VerticalAlignment, Visibility, Length, PercentLength } from "../../styling/style-properties";

tns-core-modules/ui/page/page.d.ts

@@ -3,6 +3,8 @@
  * @module "ui/page"
  */ /** */
 
+/// <reference path="../../tns-core-modules.d.ts" />
+
 import { ShownModallyData } from "../core/view";
 import { ContentView, EventData, Property, Color, CssProperty, Style } from "../content-view";
 import { Frame } from "../frame";