Book Image

NativeScript for Angular Mobile Development

By : Nathan Walker, Nathanael J. Anderson
Book Image

NativeScript for Angular Mobile Development

By: Nathan Walker, Nathanael J. Anderson

Overview of this book

NativeScript is an open source framework that is built by Progress in order to build truly native mobile apps with TypeScript, JavaScript or just Angular which is an open source framework built by Google that offers declarative templates, dependency injection, and fully featured modules to build rich applications. Angular’s versatile view handling architecture allows your views to be rendered as highly performant UI components native to iOS and Android mobile platforms. This decoupling of the view rendering layer in Angular combined with the power of native APIs with NativeScript have together created the powerful and exciting technology stack of NativeScript for Angular. This book focuses on the key concepts that you will need to know to build a NativeScript for Angular mobile app for iOS and Android. We’ll build a fun multitrack recording studio app, touching on powerful key concepts from both technologies that you may need to know when you start building an app of your own. The structure of the book takes the reader from a void to a deployed app on both the App Store and Google Play, serving as a reference guide and valuable tips/tricks handbook. By the end of this book, you’ll know majority of key concepts needed to build a successful NativeScript for Angular app.
Table of Contents (24 chapters)
Title Page
About the Authors
About the Reviewer
Customer Feedback
Integration Testing with Appium

The module benefits

Using a similar organization provides several advantageous things for you and your team:

  • High degree of usability: By designing a low-level CoreModule, you and your team have the opportunity to design how you like to work with commonly used services, in a unique way, across not only the app you are building now but more in the future. You can easily move CoreModule into a completely different app and gain all the same unique APIs you have designed for this app when working with low-level services.
  • Viewing your own app code as a 'Feature Module': Doing so will help you focus on just the unique abilities your app should provide outside of what the CoreModule provides as well as reduce the duplication of the code.
  • Encourages and enhances rapid development: By confining commonly used functionality to our CoreModule, we relieve the burden of having to worry about those details in our feature modules. We can simply inject those services provided by our CoreModule and use those APIs and never repeat ourselves.
  • Maintainability: In the future, if an underlying detail needs to change because of how your app needs to work with a low-level service, it need only be changed in one place (in the CoreModule service) versus having redundant code potentially spread across different sections of your app.
  • Performance: Splitting your app into modules will allow you to load only the modules you need at startup, then later, lazily load other features on demand. Ultimately, this leads to a faster app startup time.


You may be thinking, why not just combine the player/recorder modules together into one module?

Answer: Our app is only going to allow recording when a registered user is authenticated. Therefore, it is beneficial to consider the potential of authenticated contexts and what features are only accessible to authenticated users (if any). This will allow us to further fine tune the loading performance of our app to what is needed when it's needed only.

Getting started

We are going to assume that you have NativeScript installed properly on your computer. If you do not, please follow the install instructions at Once installed, we need to create our app framework using a shell prompt:

tns create TNSStudio --ng

The tns stands for Telerik NativeScript. It is the primary command-line user interface (CLI) tool you will use to create, build, deploy, and test any NativeScript app.

This command will create a new folder called TNSStudio. Inside is your primary project folder including everything required to build an app. It will contain everything relating to this project. After the project folder has been created, you need to do one more thing to have a fully runnable app. That's, adds the runtimes for Android and/or iOS:

cd TNSStudio
tns platform add ios
tns platform add android

If you are on a Macintosh, you can build for both iOS and Android. If you are running on a Linux or Windows device, Android is the only platform you can compile for on your local machine.

Create our module shells

Without writing the implementation of our services yet, we can define what our CoreModule will generally look like with NgModule by starting to define what it should provide:

Let's create app/modules/core/core.module.ts:

// angular
import { NgModule } from '@angular/core';
export class CoreModule { }

Injectable services

Now, let's create the boilerplate we need for our services. Note here that the injectable decorator is imported from Angular to declare that our service will be made available through Angular's Dependency Injection (DI) system, which allows these services to be injected into any class constructor that may need it. The DI system provides a nice way to guarantee that these services will be instantiated as singletons and shared across our app. It's also worth noting that we could alternatively provide these services on the component level if we didn't want them to be singletons and instead have unique instances created for certain branches of our component tree, which will make up our user interface. In this case, though, we want these created as singletons. We will be adding the following to our CoreModule:

  • LogService: Service to funnel all our console logging through.
  • DatabaseService: Service to handle any persistent data our app needs. For our app, we will implement the native mobile device's storage options, such as application settings, as a simple key/value store. However, you could implement more advanced storage options here, such as remote storage through Firebase for example.

Create app/modules/core/services/log.service.ts:

// angular
import { Injectable } from '@angular/core';
export class LogService {

Also, create app/modules/core/services/database.service.ts:

// angular
import { Injectable } from '@angular/core';
export class DatabaseService {

Consistency and standards

For consistency and to reduce the length of our imports as well as prepare for better scalability, let's also create an index.ts file in app/modules/core/services, which will export a const collection of our services as well as export these services (in an alphabetical order to keep things tidy):

import { DatabaseService } from './database.service';
import { LogService } from './log.service';

export const PROVIDERS: any[] = [

export * from './database.service';
export * from './log.service';

We will follow a similar pattern of the organization throughout the book.