Sharing code between Web and Native App with Nativescript and Angular2

 

At the very first version of Devfest Toulouse, Sebastian Witalec gave us an introduction to a framework which brings a new way to build Cross-device Applications : the NativeScript.

NativeScript is a framework for building truly native mobile apps with JavaScript”. Calling it “truly native” means that it is not a website encapsulated in a “webview”. NativeScript translates its own UI components into device native UI. The JavaScript code is interpreted by the device’s js engine (v8 for android and WebKit JavaScriptCore for iOS). Moreover an API can communicate with the native API during runtime, using a conversion between the metadatas and the native types.

nativescript-2-0-developing-native-mobile-apps-with-angular-2-javascript-framework

We write JavaScript or typescript in Nativescript, a “native language” for Web apps. The code sharing becomes natural. Here comes the interesting part of using of NativeScript with Angular2. I find Angular 2 very benefiting in this case. With the new ES6 features (class, module etc), Angular 2 brings a type safe and object oriented approach, which helps to make clean and well structured projects. It is really something that we should adopt today.

So let’s see what is actually shared :

  • Models and logical parts written in JavaScript are fully shared. (Typescript explicitly said for angular2), since app will be executed in a Javascript engine. That is however the core of an application.
  • The UI part is partially shared. In a web application, HTML would be used as usual for the ui. On the other hand, for mobile app, NativeScript UI components are not using Dom. The components are then translated to native UI components for different devices. For example, we want a text field, we may have something like this:
    • in the web app template : “<input type=’text’>”
    • in native apps template : “<TextField></TextField>”, that will be translated differently :
      • in Android : android.widget.EditText
      • in iOS : UITextField

Meanwhile, the styling is something to be shared. NativeScript supports CSS style in a similar way as in a web application. However, the supported css properties are limited, the most common styles are included like color, font, border, padding etc (more info can be found here : http://docs.nativescript.org/ui/styling), which could be somehow enough to build a homogeneous visual identity. Css implementation could be customized for devices as Sebastian mentioned in a later conversation.

  • Server side is obviously shared. The client-server communication could be shared thanks to the dependency injection in Angular 2. To create a provider in Angular 2, we can use an Angular Http api in the shared service class. That makes the normal web app use browser XHR requests. Next thing to do is to change the native project to import the “NativeScriptHttpModule” which is a Angular Http wrapper, and makes the native calls.
    Finally the code sharing story becomes something like this:

typescriptWe should be familiar with this “write once, run everywhere” approach. It has proofed its development efficiency and maintainability during the past years. Even if the concept that we are discussing here is not exactly the same thing as the JVM, the benefit of sharing code is obvious. Hoping that the js engines could keep their performance and their lightness.

Something we always worry about with a “not native app”, is the native api access. Well Nativescript makes the access totally available thanks to the metadata that I’ve mentioned before. An example of creation a file in android, we can make a call like
var file = new java.io.File(path)

The path is translated to a java.lang. String by the type conversion service. java.io.File() represents the metadata generated from the java native class. At run time, the call dispatcher discovers that a java native metadata is required, and a the java File object will be create at the native side. All the operations on the JavaScript side will be delegated to the native one through this proxy metadata object. And vice versa.

The Metadata Generating Process scans all native libraries like the sdk and injects them to the metadata libraries so that we can use them directly in the Nativescript. This mecanisme makes Nativescript have a full access of native libraries including third parties libs. Sebastian gave a demo of live robot controlling.

Nativescript is open source and extensible. Making the customized implementation is possible (like for CSS). The community is growing, such as the extensions and third-party libs.

Yet the Nativescript has a 10% performance penalty compared to the pure native code, according to Sebastien. Are we ready to sacrifice the 10% for the gain of code sharing? I believe that in most of case, the answer is yes.

Share
Zhe SUN
Zhe SUN

1834

Comments

  1. Maverick Says: May 18, 2017 at 11:54 am

    Awesome information!! Thanks

Leave a Reply

Your email address will not be published. Required fields are marked *