Angular has been around for a few years now and since its release it has been useful when creating many different categories of applications, including web as well as mobile. The problem, at least for me, has always been that the experience for creating these various applications has been inconsistent and often confusing even though the driving technology has always been the same.

Things have gotten better now that custom schematics can be used with the official Angular CLI. So what does that mean for us? We can take a project created with the Angular CLI, add a schematic, let's say for NativeScript, and end up with CLI compatible for both web and mobile.

We're going to see how to use the Angular CLI to build a web and mobile compatible application with the NativeScript schematics.

Before we can create and maintain NativeScript applications from the Angular CLI, we need to make sure we have the appropriate global NPM dependencies available on our computer. Assuming that you already have Node.js installed and configured, execute the following from your command line:

npm install -g @angular/cli@6.1.0-beta.0 npm install -g @nativescript/schematics npm install -g nativescript

The above commands will install the Angular CLI, the NativeScript CLI, and the NativeScript schematics for the Angular CLI. You have to remember that the schematics are only for creating and maintaining projects. The NativeScript CLI is still required for building and deploying the mobile applications.

Take note of the version of the Angular CLI being used. As of right now, 06/29/2018, beta.2 and rc.0 have some bugs that are scheduled to be fixed in rc.1. Until then, make sure you're using beta.0 instead.

We won't get into it in this tutorial, but your computer must also be configured for Android and iOS development if you wish to build locally. If you wish to do a cloud build and skip all the Android and iOS setup, you can check out NativeScript Sidekick.

With the proper dependencies in place, we can add NativeScript support to an Angular CLI project. While you can do it to an existing project, we're going to start with a fresh project for simplicity. From the command line, execute the following:

ng new angular-project

The above command will create a new Angular project, which by default, will be for web applications, not native mobile applications. We can add mobile application support by using the following, very simple, command:

ng add @nativescript/schematics

Make sure you had navigated into your project before executing the command above. You have to be in a project that was created with the Angular CLI, so if you had created a NativeScript project with the NativeScript CLI, I don't think schematics can be included.

In the scenario that you're truly creating a fresh code-sharing project, you can create an Angular with NativeScript project using the following single command as an alternative:

ng new --c = @nativescript/schematics --name = angular-project --shared

However, if you're adding schematics to an existing project, the prior command should be used. More information on the schematics for NativeScript can be found in the official @nativescript/schematics repository.

When you add the NativeScript schematics to your Angular project, you'll notice that it created quite a few files and even altered a few of the configuration files. Your original project should be in tact, so don't worry about something destructive happening.

The most obvious thing that you'll notice is that you have some .tns.ts and some .tns.html files. At first glance you'll probably think that you now have to manage two different code-sets, which is not entirely true. NativeScript is a native mobile application framework which means you can't use standard HTML markup for the UI. For this reason, yes you do have to maintain a web UI and a NativeScript UI. When it comes to the TypeScript, you could have a web version and a NativeScript version for everything, but you don't need to. Where it makes sense is in the modules and routing areas since there are services like NativeScriptRoutingModule and RoutingModule which accomplish the same, but are specific to platform.

Have I confused you yet?

Let's modify our new project so that we can see the power of having so many platforms under "almost" a single CLI. Starting with the project's src/app/app.routing.tns.ts file, clone it to src/app/app.routing.ts and make it look like the following:

import { NgModule } from '@angular/core'; import { RouterModule } from '@angular/router'; import { Routes } from '@angular/router'; const routes: Routes = [ { path: '', redirectTo: '/players', pathMatch: 'full' }, ]; @NgModule({ imports: [RouterModule.forRoot(routes)], exports: [RouterModule] }) export class AppRoutingModule { }

If you haven't noticed, the differences are in the naming of the modules being used. Since this file is for the web, we have removed the tns from the filename and used the vanilla Angular modules.

We're not quite in the clear yet. We need to alter our project's src/app/app.module.ts file to be more in line with the NativeScript version:

import { BrowserModule } from '@angular/platform-browser'; import { NgModule } from '@angular/core'; import { AppRoutingModule } from './app.routing'; import { AppComponent } from './app.component'; import { BarcelonaModule } from './barcelona/barcelona.module'; @NgModule({ declarations: [ AppComponent, AboutComponent ], imports: [ BrowserModule, AppRoutingModule, BarcelonaModule ], providers: [], bootstrap: [AppComponent] }) export class AppModule { }

If you're coming from an established Angular project, you'll likely be playing catchup with the NativeScript version instead. In other words the reverse of what we're doing.

The last step is to fix up the src/app/app.component.html file. As of now, June 2018, we have a default landing page with no routing in our Angular project. We need to finish with the routing setup. In the project's src/app/app.component.html, replace everything with the following:

<router-outlet></router-outlet>

We're only trying to match the behavior between the two applications. Since the application is fresh, the NativeScript version accomplished a lot more than the web version. The initial content further validated this.

At this point our project is done, but what if we wanted to use the Angular CLI going forward with our project? How about we create a new component with the following command:

ng g component about

The above command will use the CLI to create a component called about and as a result you'll end up with the following:

src/app/about/about.component.css src/app/about/about.component.html src/app/about/about.component.tns.html src/app/about/about.component.ts src/app/about/about.component.spec.ts

Where I'm going with this is that you can use the Angular CLI like you would any other Angular application. You'll end up with a .tns.html file that you can add your custom UI for mobile to. There are plenty of other commands beyond generating components, so don't feel that you're limited.

With the project created, altered, and ready to go, we can worry about running our application. In its simplest form, we can test that the project still works as a web application. From the command line, execute the following:

ng serve

When the command completes, you can visit http://localhost:4200 in your web browser to see it in action. To run the application on a mobile device, you can similarly run the following:

tns run ios --bundle

The above command will run the application on iOS. You can easily switch the ios part for android if that is better for you. The most important part of the command is the --bundle . If you don't bundle the application, it will crash with a lot of confusing errors.

You just saw how to use the Angular CLI with a NativeScript Android and iOS application. This was a long awaited and insanely requested feature by both the Angular and NativeScript community. Having separation of CLIs for development that used Angular was doing no one any favors.

It is important to remember that NativeScript projects build native mobile applications. For this reason you can recycle your logic, but separate UI components must exist. Even though it sounds like a bad thing, it is a good thing because you can give your mobile and web applications a separate, but very polished user experience. If you want to give NativeScript a quick try, check out the NativeScript Playground. You can build your first truly native mobile app deployed on your own device in 3 minutes.

This content is sponsored via Syndicate Ads.