fbpx Skip to content

Aquent | DEV6

An Introduction to NativeScript

Written by: James McGeachie

Native application development is costly for business. There are currently 2 major platforms – Android and iOS, that dominate the mobile market. If an organization wants their app to be available on both, typically they’d have to create 2 separate codebases and employ 2 teams of staff to build and maintain them. That comes at a price.

Now, what if the org in question has previously built a web application? They may want their web devs to be involved in building the native application, but chances are they’re going to be in unfamiliar territory and will take some time to adapt. To develop quickly, the business will need to hire specialized native developers. This means potentially having 3 separate teams – Web, iOS and Android, all trying to build the same core application.

This problem is one that the development community has been trying to solve for years. Many different solutions have been created – you may have heard of frameworks like React Native, Ionic and Xamarin. Today we’re going to look at a relatively new and exciting solution called ‘NativeScript’.

What is NativeScript? 

NativeScript is a framework for building native applications through writing JavaScript. It was created by a company called Telerik and is an open source project and available for use under the Apache 2 license. It’s set apart by the following features:

  • Write once, run anywhere (use the same code for all platforms)
  • Write your app using Angular, TypeScript or vanilla JavaScript
  • Touch native APIs directly in your JS

What this means is that you can have a team of Angular developers build a NativeScript application for both Android and iOS, and within that application those developers can spend virtually all their time writing the JS code that they’re familiar with.

For both a business looking to make efficient use of resources, and for web developers who want to get into writing native apps, this is a win-win. 

Getting Started

Installation & Environment Set-up 

So we’ve told you what NativeScript is. Now let’s look at how you kick-off a NativeScript project.First, you’ll need to install the NativeScript CLI. Note – we’re focusing on Mac set-up in this post.

npm install -g nativescript

This will install the CLI globally which you can utilize by typing ‘tns’ (Telerik Native Script).

Next, if you haven’t previously set-up your environment for Native iOS and Android support you will need to do so. This can take some time normally, but the NativeScript team understands this pain and created a handy script to take care of the installation.

ruby -e "$(curl -fsSL https://www.nativescript.org/setup/mac)”

At this point you can verify if your environment has been set-up correctly by entering a command provided by the CLI.

tns doctor

If there are any environment issues they will be pointed out to you now in order to be resolved. 


Generate a Project

With the above installation complete, we can jump straight into creating a project. We mentioned earlier that NativeScript projects can be Angular, TypeScript or plain JS. The recommended approach is writing your app as an Angular project and at DEV6 we also encourage this as Angular is a very powerful framework.

The CLI allows us to generate a new project quickly.

tns create ExampleApp —ng 

The above command spins up an NativeScript application with an Angular template. If you want, you can run this immediately without adding a single line of code. Simply cd into the ExampleApp directory and enter one of the following commands:

tns run ios
tns run android

Running this will build the app and launch it in your default iOS simulator or Android emulator. With this app template you’ll see a list of mock-data and you can navigate to detail views for each item in the list.

Project Structure

Now that we’ve generated an app and have proven it works, let’s have a look at the generated folder structure. 

Folder Structure

We’ll focus on the contents of the app folder. For anyone coming from Angular (2+) development, these files will be immediately familiar. We have a main file, an app component, route definitions and an app module. This is the fundamental structure of an Angular application.

What about the contents of these files – are those also familiar? Let’s peer into the app component TypeScript file.

import { Component } from "@angular/core";
 
@Component({
    selector: "ns-app",
    templateUrl: "app.component.html",
})
 
export class AppComponent { }

Here we can see an Angular component in NativeScript still uses the @Component decorator to supply metadata for its selector and template. Components are also still built using TypeScript classes and I’ll note that we would implement their functionality the same way we normally do – by adding methods to the class and then binding them to our component template. Basically, there are no surprises – this is Angular.

So you may be wondering – if this is just regular Angular like we would write for the web, how does it achieve building for Android and iOS? Well, the answer is that there are some differences.

NativeScript UI

Within the application we just generated there’s a folder named ‘item’. In here you’ll find a file named ‘item-detail.component.html’, which is the template for the item-detail component. Let’s open this up.

<ActionBar title="Details" class="action-bar"></ActionBar>
 
<FlexboxLayout flexDirection="column" class="page">
 
    <FlexboxLayout class="m-15">
 
        <Label class="h2" [text]="item.id + '. '"></Label>
 
        <Label class="h2" [text]="item.name"></Label>
 
    </FlexboxLayout>
 
    <Label class="h4" [text]="item.role"></Label>
 
</FlexboxLayout>

Ok, now we have some surprises. Instead of familiar html elements, we have some things named ‘ActionBar’ and ‘Label’. These are built-in NativeScript UI Widgets and they take the place of html elements as the basic building blocks of your application. 

So why are we using these instead of html? Because these widgets are NativeScript’s mechanism for mapping to the appropriate native UI element on your target platform. For example, the <Label> tag we see there maps to a ‘UILabel’ on iOS and ‘android.widget.TextView’ on Android. It’s important to note that there is no ‘DOM’ in a native app. We’re not rendering these templates in a browser. That’s why this step of mapping a template to corresponding native UI is crucial and is a core part of how NativeScript achieves ‘write once, run anywhere’.

What about this ‘FlexboxLayout’? NativeScript has a number of layout wrappers that allow you organize your content onscreen. This one allows you to layout your content in the same way you do with the css flexbox module, which is once again familiar territory for web devs. 

The above should make one thing clear – Writing templates for a NativeScript app is different from the web, but does offer a tempting alternative to learning native UI libraries as you only need to master one set of elements rather than 2. 

Next Steps

From this post you’ve learned what NativeScript is, how to get started with a new NativeScript project and what some of the similarities and differences are for an Angular web developer coming to a NativeScript project. This is the tip of the iceberg for NativeScript development, but you may be starting to see why it could be an exciting option when considering a new native project, especially if you’re looking to have one codebase and have web developers involved. 

If you wish to get hands-on and start building an application with NativeScript, we currently suggest going to their docs and taking the get started tutorial – available here http://docs.nativescript.org/. We also recommend though that you keep an eye on our DEV6 site and blog as you may see further NativeScript content down the line.