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.
So let’s see what is actually shared :
- 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:
We 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 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.