In this chapter, we are going to introduce you to Telerik's NativeScript, and discuss how NativeScript is totally unique in the cross-platform mobile device market, and how it is radically revolutionary for mobile JavaScript development. We will also walk you through the prerequisites of how to install the NativeScript command-line tool. Once the NativeScript tool is installed, we will walk you through the basic usage of the tool and briefly describe the most common parameters. Finally, we wrap up the chapter by creating and running our first NativeScript application.
In this chapter, we will be covering the following topics:
What is NativeScript?
NativeScript and TypeScript
Common modules
Installing NativeScript
The NativeScript command line
Creating your first application
If you are looking at this book, maybe you want to know why you should use NativeScript and what sets it apart from the crowded competition. Why shouldn't you use any of the other cross-platform tools? Let us dig in, and I'll explain why NativeScript is the answer to the best way of executing cross-platform mobile development.
Telerik's NativeScript is a fairly new open source development system for creating cross-platform mobile applications almost entirely in JavaScript, with some optional CSS and XML to simplify developing the display layout. You can find the main location of each of the different projects that make up NativeScript at https://github.com/NativeScript. Even though it is new to the market, it is already fully compatible on Apple's iOS and Google's Android. In addition, Microsoft's Windows 10 Mobile is currently in development by Telerik, and others are working on Firefox Mobile. NativeScript uses the V8 engine (as used by Google Chrome and node.js) on Android and Apple's JavaScriptCore engine on iOS devices.
Now, there are several other competing JavaScript development systems for mobile devices. Some of these competitors have been established for a while. Other development systems may have large companies working on them. But neither of those will make any of the other tools the best choice. What makes NativeScript stand out from the crowd of other JavaScript environments is its unique design. Every other JavaScript environment requires a special bridge, or a compiled extension of some sort, which basically exposes some part of the native functionality of the host operating system to your JavaScript code. A lot of them are actually just web browsers wrapped in an application shell, so all the work you do is actually in a browser. If you decide you want Bluetooth on your iOS phone in one of the other products, you have to find someone who has made the iOS Bluetooth bridge or extension module in some other non-JavaScript language. In a lot of cases, you will even have to compile the module, and then you will still be hoping that the module has all the functionality you need.
NativeScript is unique because it allows you to access the native elements of the host platform via JavaScript. In NativeScript, you can still see if someone has written a convenient JavaScript library to access the Bluetooth API. If so, since you understand JavaScript, you can easily make any changes you need. If not, then you can make your own JavaScript module to access all the host platforms of Bluetooth API. NativeScript is not a wrapper around a web view; it literally allows your JavaScript to work directly with the host platform APIs.
For example, to find out if a file exists, we can just call the native Android method in JavaScript:
var javaFile = new java.io.File('/some/file/name.ext'); var exists = javaFile.exists();
Or the native iOS Objective C code in JavaScript:
var fileManager = NSFileManager.defaultManager(); var exists = fileManager.fileExistsAtPath('/some/file/name.ext');
Since NativeScript allows you access to the full operating system libraries and third-party libraries from your JavaScript code, you do not need to wait for someone else to create a wrapper or bridge to talk to any part of any iOS or Android API. You can now fully use any of the APIs as a first-class citizen, which even includes using any new APIs when they are first released.
Now, before you get worried about having to know both iOS and Android to make your application, NativeScript has that covered. To simplify things, NativeScript already has a wide number of components, or modules, that wrap the most common things a developer will need, which are called the NativeScript common core modules. So, instead of having to write any Android or iOS specific code like I did above to see if a file exists, you can just write the following code:
var fs = require('file-system'); var exists = fs.File.exists(path);
The NativeScript filesystem module has each of the native platforms' API wrapped up so all you have to do is write to a common interface. But when you need to do something outside of the built-in modules and components, NativeScript is the only environment that allows you to easily have full access to everything the device offers right from JavaScript.
We are going to explain how parts of NativeScript are developed in TypeScript and what that means for you in terms of developing your awesome application using NativeScript.
In 2012, Microsoft released an interesting language called TypeScript. This language is fully open sourced because the company felt it was something the JavaScript community needed. It is, in a nutshell, a superset of JavaScript with types and several other additional language features. If you write any code in TypeScript, you then have to use the TypeScript transpiler to convert the code from TypeScript back into JavaScript. One of the primary reasons people use TypeScript over regular JavaScript is that TypeScript offers the ability to do static type checking at the point it converts the code to JavaScript. So, you don't have a runtime hit, and you don't have to do a lot of runtime parameter checks if the code is all in TypeScript. This feature alone eliminates a type of bug that is very easy to access in JavaScript. In addition to static typing, it has several class/object type features that make inheritance and class definition considerably simpler and safer.
Note
Types possess the ability to add markup to code denoting the type expected:
private validateMe(name: string, password: string): boolean { };
The string
and boolean
are declarations telling what the exact parameter types and expected return type are. This allows the transpiler to verify that the code matches the static types during the building stage.
Transpiler is a shortened term from translation compiler used to mean the code is converted from one language to another language. So, in this case, we are translating the code from TypeScript into JavaScript.
The NativeScript command-line utility, common modules, and components are all written in TypeScript. TypeScript is then transpiled to JavaScript before it is distributed for all us developers to download, install, and use. So, unless you are actually pulling the open source code from the NativeScript repositories, then all the code you will see is in JavaScript.
Fortunately for us, the majority of the differences between TypeScript and JavaScript are fairly minor, so the code transpiled to JavaScript in almost all cases is very close to the original TypeScript, which still makes it very readable.
Note
Telerik just released a brand new module in v1.5.0 that will allow TypeScript to now be a first-class citizen in the development of your application. If you don't use this module, then you have to manually transpile all your TypeScript code each time before you build an application. After you execute a nativescript install typescript
command, when the NativeScript command does anything with your code, it will automatically transpile all your TypeScript code first. This makes your development a much more streamlined process.
Since the final output of all the code must be JavaScript, you are able to write any of your applications or modules in TypeScript, CoffeeScript, or any other language that can be transpiled into JavaScript. This book is going to focus on doing everything in JavaScript as this is what the final code output must be for all the devices, and it is the common language that binds everything together.
Common modules were created to solve the issue of JavaScript files polluting the global namespace with variables and functions that another JavaScript file could easily overwrite accidently. JavaScript allows you to redeclare or monkey patch your functions on a whim, which is part of what makes it so powerful. However, with that much power comes the ability to very easily shoot yourself in both feet simultaneously. Then, you are left scratching your head why you just lost both feet. To attempt to solve the issue of one included file function or variable being overwritten by another include file, developers came up with several techniques that evolved into the common module formats we use today. There are three standards available for you to use: the CommonJS
module format, which is what node.js
popularized; the AMD
module format, which was designed for the asynchronous resolution of JavaScript files in a browser environment; and the brand new ECMAscript 6
module format, which, when finally released, should become the de facto module format. All three of them wrap the source code so that none of the code in a module by default can interfere with the global namespace. NativeScript follows the CommonJS
module format where you use exports
and module.exports
to tell what parts of the code in the module you want to expose to outside parties. When you see var coolModule = require('cool-module');,
this is the syntax that the CommonJS
module format uses to load a module.
We are going to cover what you'll need for installation and development. Then, we will discuss how to install the NativeScript command, which you will use for anything relating to your NativeScript project.
To get started on our journey of using NativeScript, we first must have several tools installed. The primary tool you will use for virtually everything is the nativescript
command, or you can alternatively use the shorter alias of tns
(short for Telerik NativeScript).
For the nativescript
command to be installed and to make it work, you must first install node.js
, which can be downloaded and installed from https://nodejs.org/. The nativescript
command is also written in TypeScript and already pre-converted to JavaScript before you even download it. It uses node.js
and several other common modules to perform all its work.
If you are planning on distributing your app on any iOS devices, you will need to have access to an Apple Macintosh platform. This is a requirement by Apple as they only allow you to compile and upload the app to the app store from a Macintosh. The Macintosh must have the Xcode and Xcode command-line tools installed. It is also highly recommended that you have an iPhone 4s or better to test at least the final application before you distribute it. The iOS emulator is not very accurate and because it gives you an idea of how your app will look, an actual device will accurately show you what your customers will see. The specific install instructions for iOS can be found at http://docs.nativescript.org/setup/ns-cli-setup/ns-setup-os-x.html.
Android is a lot easier because you can execute development for Android on Linux, OSX, and Windows. For Android, you need to install Java JDK and then the Android SDK and tools. I also highly recommend that you install an optional third-party Android emulator rather than use the stock Android emulator. The third-party emulators are considerably faster than both the stock Android emulator and the add-on Intel HAXM emulator. The stock emulator and Intel HAXM can be downloaded via the Android SDK Manager. The instructions on the NativeScript site can walk you through installing all the tools that you will need for building and testing your application. The specific instructions for each of the platforms are located at http://docs.nativescript.org/setup/quick-setup#the-nativescript-cli.
Once you have node.js
installed, you just need to do a simple npm install –g nativescript
at a terminal shell (or known on Windows as a command prompt window). And then npm
will download and install the required NativeScript code and command-line tool. It will install it globally so that it can be used from any project you are working on.
Tip
With the command path on Linux and Macintosh, the global commands are normally placed in /usr/local/bin,
which is typically already in your path, so the nativescript
command should work right away.
On Windows, unfortunately, you might have to add the path where npm
installs the program globally. Type nativescript
and see if it runs. If it fails to run, then you need to add npm's global directory to your path. Type npm config get prefix
to get the current global directory.
Type systempropertiesadvanced
, then click the Environment Variables button, then click on PATH, and finally, click the Edit button. Then, you can type a semicolon and add in the directory path to the all the npm
global commands like the NativeScript command. So, your path might look something like this: C:\windows;c:\windows\system;c:\program files (x86)\nodejs
.
Once the NativeScript command and required support tools are installed, you are all ready to begin developing NativeScript applications.
Sometimes, getting NativeScript installed properly can be difficult because of all the differences between computers. Here are a couple places you can go to get help if you need it: https://groups.google.com/forum/#!forum/nativescript and https://plus.google.com/communities/117408587889337015711.
Now, before we get to the creating a project part, let us have an overview of the commands available from the new nativescript
command you just installed. If you forget any of these, you can easily type nativescript
alone without any parameters to see a help screen at a console window, or type nativescript /?
for a help screen in your browser.
These are just some of the most commonly used valid commands for the nativescript
command. Several of these we will be covering as we progress in the book.
Now that we have described some of the commands, let's use them to create your first mobile app via the nativescript
command tool.
I am going to walk you through how to create an application as it currently requires a couple steps that you need to do from a terminal shell. Then, we will show you how it looks.
Creating a project is actually a fairly simple process; we are going to start by creating the application we will develop throughout this book.
Make sure you are at a terminal shell and then type:
nativescript create crossCommunicator
This will create
crossCommunicator
as a subdirectory of the current directory you are running thenativescript
command in. This new project directory will have all the required files for developing your project.Next, you will need to switch to that new
crossCommunicator
directory that it created for you by typing:cd crossCommunicator
Then, type:
nativescript platform add android
And/or:
nativescript platform add ios
To add each of the target environment(s), you will be compiling your app from this machine:
If everything worked properly, you should see something like the preceding image results.
Now, I personally do all my development on the Windows platform using JetBrain's wonderful cross-platform PHPStorm development environment. You are free to use any JavaScript editor you are comfortable with. Since I am using the Windows platform, I do the majority of my testing and debugging on the Android platform and emulator. The Android emulator is basically a full Android in your computer, so it behaves like an actual device. However, since I am also targeting iOS, every so often I also copy or sync the code from my Windows app folder to a Macintosh and then verify that everything looks good and works as expected on the iOS emulator and eventually an iOS device. The very first time when I copy my code over to a Macintosh, I use the nativescript platform add ios
command as I need to add the iOS target on the Macintosh.
Note
First time requirements
The very first time you create a project or add a platform, you do need an active Internet connection so the nativescript
tool can download the current version of the runtime and platform libraries that it uses. In any future executions, it will first try to download the newest version, but if it fails, it will then use the currently cached version.
With those simple steps, NativeScript creates a framework for an application that you can already run on your mobile device. Now, to run the project, we execute:
nativescript run android --emulator
Or:
nativescript run ios –-emulator
NativeScript will then copy your application to the emulator, automatically start it up, and then you should see your first application running on the emulator screen like this:

We covered a lot in this chapter. You learned what NativeScript is and what makes NativeScript unique among all the different JavaScript mobile development systems. You also learned how to install NativeScript and explored a large number of different command-line parameters you will use. And finally, you actually created and ran a new project.
Now you have the tools you need installed, and most importantly, we now have a running application. Let's dive into what makes the whole project tick. We will explore all the different files and folders for your project and gain an understanding of how each file is used, and finally, we will enhance the default application in Chapter 2, The Project Structure.