Building native Angular apps with NativeScript

Angular 2 is platform agnostic. That what makes it possible to “compile” it to other tech such as native mobile applications.

NativeScript: use JavaScript to build a native UI. It is not Cordova, PhoneGap..no browser, no DOM. It’s also not Xamarin. There’s no cross-compilation, the JavaScript runs and transforms at runtime. There are also no wrappers, but there’s direct access to the native API. Not cool enough? You can use npm packages! And it’s open source.

NativeScript modules can be “required” which then translate to the specific platform the code is running on. So it’s like an abstraction layer s.t. you don’t have to write iOS/Android specific JavaScript code.

Important, Web UI != Mobile UI: Mobile applications have different navigation scenarios, different requirements from the UI perspective than a web application.
Also, there are no <div> as there is no DOM/browser. The UI is made of custom components like

<StackPanel><Label...><Button></Button></StackPanel>

Although the elements are very HTML alike. A huge feature, LiveSync between the editor and Android emulator that executes the native components.

These are not the models you are looking for

What’s currently done by many that are developing Angular applications:

functionSomeController($scope){$scope.person={firstname:'Juri',lastname:'Strumpflohner'};$scope.changeName=function(newName){// some validationif(isValid){$scope.person.firstname=newName;...}...};}

The model is directly bound to the scope as plain JavaScript object. Furthermore note the changeName function that acts upon the model. Problem: the code sits within the controller and is therefore hardly reusable by other parts of the application. Instead, it’s the models’ responsibility to “change its name”.

What should I use today?

SystemJS loader + Angular2 bundles because it’s most used (Plunkers, in the docs,…).
But mostly choose the tool you’re most comfortable with.

Require vs. WebPack vs. JSPM

Advantages and disadvantages.

Some details

CommonJS output is much more concise than the CommonJS output. That’s because SystemJS tries to be “correct” with the ES2015 semantics. It also knows how to properly deal with circular dependencies.
CommonJS has less noise, but all kind of rich tooling around like WebPack and Browserify.
Bundling in SystemJS is as easy as concatenating files as it handles everything already internally by keeping a register of modules.

“System” insanity warning - lots of stuff packed into this term, from the original spec format, to the bundler, loading etc…

The (near) future will be different maybe and that might change how we think about bundling. HTTP/2, what bundler will be used in Angular 2 (CLI), …

Creating realtime apps with Angular 2 and Meteor

The kind of connected client architecture is still missing. People decouple it through request/response patterns and REST.

A connected client gets live updates from the server in real-time.

There are no spinners. The “facebook likes” happen immediately.

Want that kind of live updating experience on all devices (forget about spinners!)

Meteor is based on

connected client architecture

JavaScript everywhere

Complete, Open, Platform

Connected client architecture

Push live. On the usual architectures this would require a lot of work. Meteor builds this in with Livequery. It’s like a $watch on the database.
Then the synched client data cache takes care to propagate the changes from the Livequery to the application. This is done through publish/subscribe patterns. Communication happens through WebSockets. We should not care about network latency, just synch immediately.

JavaScript everywhere

Meteor takes care of the server, mobile, web clients. This is done by combining isomorphic JavaScript and optimistic UI (like button scenario).
When you click the Like button, changes update in the local cache and happen immediately, by executing the “addOne()” method. Through the synching approach, the same “addOne()” method is executed on the server as well. It’ll update the data and then later update the local cache again.

Complete, open, platform

Meteor is the infrastructure team you never had! it is the platform for JavaScript like the JVM is for Java or the CLR for .Net.

Angular 2 Meteor package

deeply integrate into the change detection process of Angular 2. When Meteor gets the change, it notifies the Angular 2 change detection mechanism.
Tutorial for having a full-stack Meteor+Angular tutorial, moving from Angular v1 to Angular v2 on http://angular-meteor.com/.

Takeouts

Backend revolution is happening (like Angular did to jQuery, Meteor is to DB)

What Rails did for REST, Meteor is doing for client connected architecture

Being a full stack developer is much easier

Using Web Workers for more responsive apps

60FPS is what you strive for to keep things smooth. Means you have 16ms to do your stuff, but the browser needs about 8ms do update the DOM.
Modern web applications require stuff like sound/image processing, running prediction algorithms etc…that’s stuff that easily takes more than 8ms.

A WebWorker is a separate execution context, running in a totally different process. Those processes don’t touch the DOM. Integration tests will be a lot faster.
Don’t just push heavy stuff to the server. May work for a webapp, but not for client apps. You pay for server CPU after all, not for the client ones! “It costs more to transmit a byte than to compute it”. Moreover transmitting means more energy cost, thus reduced battery live (radio transmitters consume a lot of battery).

Challenges

Challenges

no DOM access

no shared memory with UI

serialization

concurrency issues

Therefore the strategy is to..

run everything in a WebWorker

Let Angular care about updating the UI then

What are compatible components

no DOM Access

full access to angular APIs

can inject a renderer if really necessary

…

Communication between WebWorkers and UI happens through a Message Bus. MessageBroker helps dealing with that.

Will be beta the next months or so…Mainly work on tests and docs. Api isn’t going to change that much.

Observables

streams

subscribe/unsubscribe

…

The only thing Promises make sense for is Ajax. But there’s a problem. They are hardly cancellable which is often an issue when people quickly switch through different views where each is going to start some Ajax calls for loading data.

Observables can be cancelled: simply unsubscribe!

Creating an Observable is nearly identical as creating a Promise object. The moment subscribe is called, the Observable body is executed, not before (they’re lazy).

Huge plus. Observables can simply be retried calling

myObservable.retry(3);

With promises that’s doable but a bit more tricky.

Operators

“operations” that return Observables themselves. Observables work a bit differently when you pipe through different operators. Basically values are passed one by one rather then the entire data as the map function on an array would work like.

When the operations like filter/map are used (the traditional ones) they create intermediary data structures in memory which will need to be garbage collected. Observables instead process all of the values directly through the entire chain, one by one (don’t use it for small arrays though, tends to be slower).

There are buffering strategies like buffer, throttle, debounce, sample.

hot vs. cold observables

By default “cold”: when you subscribe, it sets up one producer for one consumer (for each consumer.

Calling .share() on it, there’s one producer for all consumers.

Multiplexed WebSocket

Basically sending multiple messages over the same stream, so there’s filtering going on.