NativeScript for Angular Mobile Development

A good exercise for this is to sketch out a rough idea of one of your app views. You may not know what it will look like yet and that's okay; this is purely an exercise to think about the user expectations as a first step to guiding your thought process into the various sections or modules you need to construct to meet those expectations. It will also help you think about the various states the app needs to manage.

Take, for example, the app we are going to build, TNSStudio (Telerik NativeScript (TNS)). We will dive into more detail of what our app is and what exactly it will do inChapter 2, Feature Modules.

Starting from top to bottom, we can see a header with a menu button, a logo, and a record button. Then, we have a listing of user recorded tracks, each with a (re)record button and a solo or mute button.

From this one sketch, we may think about several services the app may need to provide:

We can also gain some insight into the various states the app may need to manage:

It's also advantageous to provide some low-level services that provide a convenient API to access things, such as HTTP remote requests and/or logging. Doing so will allow you to create unique characteristics that you or your team like to work with when interacting with low-level APIs. For instance, maybe your backend API requires a unique header to be set in addition to a special authentication header for each request. Creating a low-level wrapper around an HTTP service will allow you to isolate those unique characteristics and provide a consistent API for your app to interact with, to guarantee all the API calls are enhanced with what they need in one place.

Additionally, your team may desire an ability to funnel all the logging code to a third-party log analyzer (for debugging or other performance-related metrics). Creating low-level wrappers with the lean code around some framework services will allow your app to adapt to these potential needs quickly.

We can then think about breaking these services up into organizational units or modules.

Angular provides us with the @NgModule decorator, which will help us define what these modules look like and what they provide to our app. In an effort to keep our app's bootstrap/launch time as fast as possible, we can organize our modules in such a way to allow some service/features to be lazily loaded after our app has launched. Bootstrapping one module with a small subset of required code that our app needs to launch will help keep this launch phase to a minimum.

Here's how we will break down our app organization by module:

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.

We are going to assume that you have NativeScript installed properly on your computer. If you do not, please follow the install instructions at https://nativescript.org. 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.

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';
@NgModule({})
export class CoreModule { }

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:

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

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

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

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

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[] = [
  DatabaseService,
  LogService
];

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

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