NativeScript Angular 2 Introduction: Why NativeScript Matters
While there is a big buzz around Angular 2 and the Ionic Framework 2, a new force awakens in the shadow of the cross-platform development world. While this force has not yet reached the maturity level of other frameworks, the potential and the chances for success makes this force a worthy candidate to become one of the strongest frameworks on the cross-platform horizon.
Not another framework, cmon!
That was my first impression when my good friend Nic Raboy started to blog about NativeScript.
But some weeks ago on the German Developer Week conference I had the chance to sit down with the great Sebastian Witalec from the Telerik team, the creators of NativeScript. He gave me very good insight into what NativeScript is and what it isn’t, so today let’s explore what NativeScript can do for you!
What is NativeScript?
The great thing about it?
While Ionic 2 also uses Angular 2, the code of an Ionic 2 app is not completely the same like for an Angular 2 web app. With NativeScript, you code is actually very much the same, which gives you the chance to use shared code between your mobile and your web app. Pretty awesome!
We haven’t covered one of the most important parts about NativeScript yet: Native performance.
So in order to get native UI components on iOS and Android, NativeScript uses a special syntax for creating the views. This is not HTML, as it’s not running in a Webview (yeah Sebastian, I understand the reasons now!). The syntax for the view is like XML, but with Angular 2 support you can also use Angular 2 elements. It’s a bit confusing at this point and the documentation is not really good by now, but you will see it in action soon.
There is a lot more to say about the build system and other stuff related to NativeScript or the Telerik platform, but for now the knowledge is enough to dive into some hands-on stuff.
I am pretty new to NativeScript but wanted to give you the best possible impression, so like always we will develop a little app and see how it goes. Some people will like this way of doing things, others won’t and that’s fine.
No framework should target everyone, because that would in the end mean it won’t target anyone!
Let’s dive into some NativeScript code and build a little Pokéindex using the Pokémon API!
Starting a new NativeScript App
We start with an empty NativeScript app and pass the — ng flag to indicate we want to use Angular 2.
As the CLI is no that mighty at the moment, we need to create the folders and files we would like to have by hand, so feel free to copy the touch commands.
I’m using a Mac so I can add the iOS and Android platform, if you are not on a Mac you can only use Android!
// Install NativeScript if needed
npm install-g nativescript
tns create devdactic-pokemon — ng
tns platform add ios
tns platform add android
If you want to run your app on iOS, you need to apply a little change to the app/shared_resources/info.plist to have access to outside APIs. This is also one of the strengths of NativeScript, you can actually change the behaviour or settings for one platform quite easily!
Allow Transport security for iOS
If you want to run this demo you need this in some form, NSAllowsArbitraryLoads in this example just allows all outside connections which might not be the best practice for productive apps. It was introduced with iOS9 and needs to be added because Apple wants to make sure you are using secure connections. Read more about it here.
By now your app should already work, so give it a try and run the app on whichever platform you like:
tns run android
tns run ios
// or inside the emulator
tns run android — emulator
tns run ios — emulator
As said before, the app does not run in a Webview so we can’t just debug the app inside Chrome like with Ionic. Anyway, NativeScript offers livereload to improve the development flow. This is a bit slow at the moment but speed improvements are planned for the next releases!
We also need to apply a little patch to our app in order to use HTTP requests. This counts only for the current version 2.2 of NativeScript and will hopefully be fixed soon.
So open the app/main.ts and insert:
Setting up the Angular Router
Our app is currently empty, so let’s start with some logic for routing to our different views. As said before, NativeScript uses the actual Angular router.
Therefore, go ahead and open the app/app.component.ts and insert:
This looks a lot like Angular 2! We simply define 2 paths inside our app:
- /list: The path to our ListPage, the default page we show after starting the app
- /pokemon/:url: The details page for a specific Pokémon which is the PokemonPage
So this is the backbone of our app, let’s head on to the more interesting stuff!
Loading 150 Pokèmons inside a Listview
Because everyone knows that only the first 150 are the real Pokémon, we will simply load that amount from the PokéAPI.
Our ListPage loads the information and saves the data to an array, while also maintaining 2 loading states. These states are used for displaying a loading indicator and also fading in the list with the actual results.
Open the app/pages/list/list.component.ts and insert:
As you can see we also created the showDetails function which will be called once we want to drill down on a specific Pokémon of our list. We just need to get the selected object and then call the router and pass the URL for that Pokémon (the detail page will handle the rest of loading the new data).
So far everything looks like an Angular 2 app, but let’s see how the view is created.
Open the app/pages/list/list.component.html and fill in:
The list view for our 150 Pokémon
This is no standard HTML in a *.html file! Dafack is this?
You just met NativeScript!
At first sight, this looks a bit strange. Always keep in mind that this view component hast to be rendered as native components, not a webview.
So what’s happening here is that we use a simple GridLayout Layout container from the NativeScript layout options. This allows us to easily add different view components and they get positioned like in a table with rows and views.
Additionally we style our rows with a DockLayout to show a little image of the Pokémon in front of our row. Most of the rest is simply Angular 2 syntax!
Everything in NativeScript lives in these layout containers, and once you get used to it this actually helps you a lot to build views faster. Also, great guys are currently working on rendering of NativeScript components inside the web. This could really be a huge help as you most of the time need an app plus a website.
Think about the view component what you want; it’s a bit irritating the first time coming from ionic and standard HTML, but it’s a pill you have to swallow if you want to go the NativeScript way.
What are your first impressions? Let me know below!
To get a better appearance effect and some styling for the list we add some styling and animation inside app/app.css (there are better places for styling, but this works as well):
These are actually standard CSS animations, which will be mapped to native changes of the UI like described in this post.
Basically we are defining some general properties in the upper half of the file and an animation to fade in or out our list view in the lower half using @keyframes to define the animation. By using the name of the animation inside the definition for animation-name the animation is bind to that property. If you want to find out more about NativeScript animations, check out their documentation for Animations with CSS.
Crafting the Details View for a Pokèmon
Let’s finish up our little app by adding the details view for a Pokémon. This component will get the URL to a specific Pokémon so it needs to load all the data for it at first.
Once we got the data, we grab some data out of the response, which is what we want to display (I know the real Pokédex was a lot cooler, but hey that’s up to you to continue this post!).
We also have some loading states again, just to have a better looking UI. So open the app/pages/pokemon/pokemon.component.ts and insert:
Again very standard Angular 2, not really much more we need to say about it. The map logic might look a bit strange but that’s how you get the most power in as few lines as possible.
The view inside the app/pages/pokemon/pokemon.component.html should contain this:
This time we use a StackLayout as container, which is simply arranging every object below the previous one. We want to have our Bar at the top to navigate back to the list, two labels with the information and finally the image.
I found it a bit complicated which syntax to actually use, so sometimes we access Angular properties but sometimes they are normal properties of the object. Also, the documentation is not very helpful at this moment, which was also noted by Raymond Camden when he worked with NativeScript. But I think the team is aware of this and will constantly improve this!
Finally, we can actually apply some styling to our not-really HTML view with some CSS inside app/pages/pokemon/pokemon.component.css so let’s do it:
That’s it for our first NativeScript app!
Now run your app on iOS or Android and enjoy your childhood memories of 150 Pokémon and their images.
Why NativeScript matters
As said before, my initial thoughts were “Why should I learn another framework?“, and still get those thoughts when working with new stuff like React Native.
But if you think a bit different everything becomes easier:
All of the frameworks for cross-platform development have their strengths and weaknesses!
For me there is no single best framework, it always depends on the business case and requirements you have. While Ionic is great in many areas, it will always be a Webview and you will always lack some performance vs. a native app.
There will always be people who don’t like Angular at all, which are better suited with something they might already know like Xamarin for .NET or React-Native for ReactJS developers, or even Unity3D if you want to target even more devices.
So we shouldn’t fight the cross-platform war like we fought Apple vs. Android, they both exist and you have to target both.
Back to NativeScript
So these were some general thoughts, now back to the question what makes NativeScript strong and who should use it?
First of all, every framework that settles on Angular 2 is a potential candidate for something we want to use. Developing Angular 2 with TypeScript does not feel like old web development but like writing actual good code, plus the community is huge.
And, if you want to create a mobile app and website chances are very high you can share code between your NativeScript and web app! This is something that will become more and more important. And as NativeScript does not force you to have some special Angular stuff, you could really share that pieces sometimes 1:1 which is currently not possible with Ionic 2.
The next big plus is native performance coming from the native compiled UI components. Of course this makes NativeScript attractive to people who rely on good performance and fear the almighty Webview in hybrid apps.
One thing we haven’t really touched before is the use of native APIs, which comes pretty easy with NativeScript. This means, you can actually call the let’s say iOS UITableViewController directly from code!
Of course this means you need to have some native knowledge, but if you do have it this can sometimes offer you great possibilities as you don’t have to wait for some company to write a wrapper but just directly use it by yourself. For a better explanation, you can watch the NativeScript explanation video here.
Finally I would recommend to try NativeScript to everyone, but especially to those who:
- like Angular 2 and TypeScript
- want better performance for Cross Platform apps
- already have some native experience
These people might benefit the most from it, and that’s again the reason why I said there is space for many frameworks. What these people might like about NativeScript is not helpful at all for others, who are then suited better with a different framework.
My first adventure with NativeScript was interesting, I learned a lot about how things work and I can see the potential benefits for developing cross-platform apps with it. I will give it some more time and maybe more tutorials in the near future to see if it’s something I want to work with more often.
What are your first experiences with NativeScript? Would love to hear them!
A big thank you goes out to Sebastian Witalec again for porting my code from NativeScript 2.1 to 2.2. You can definitely count on the NativeScript team if you encounter any problems!
Originally published at devdactic.com on July 14, 2016.