Category Archives: Uncategorized

Awesome NativeScript

Sometimes I REALLY love NativeScript.

So I have a really hard time tracking my time. Tested multiple time tracking apps over the years and still have many issues with all of them. Always been a real pita for me. So about a year ago I wrote a very simple NS time tracking app which works pretty well for me when I remembered to use it. Meh, problem is I really hate time tracking…

My son, being the smart one and not as picky, found a fairly nifty time tracking app on Android that he liked and he showed me that when you unlocked the phone it would popup immediately. I'm like that is a awesome feature, makes it easy to make sure you don't forget to switch tasks; unlock and click on the new task.

So a couple searches later I added the ability to my own NS timer app. So now, unlocking my phone, the app immediately goes into the foreground and lets me switch the timer task if need be…

Of course I could stop their, but NOOOOO, not me…. I'm out to make this be very functional, so I will actually use it with much better consistency…

So, another thing I kept thinking about over the last year was the ability to control it with voice commands. However, I have always been very privacy focused and REALLY REALLY hated using remote servers for almost anything. Let alone sending Google (or Apple) any voice recognition data. So it has been a non-starter for a while for me…

A couple searches later this last weekend, and I found a awesome open source offline voice recognition system. Works on both Android & iOS (I only integrated the Android side, as that is all I need for my time tracking).

So now I can unlock my device (which of course immediately triggers my app to the foreground) and SAY: "Timer X". The app then searches all the timers for anything that matches, if it matches; it switches to that timer and then uses (also offline) Text to Speech to say: "Starting timer X", so I have a confirmation without having to look at the screen…

All in a simple NativeScript application… If I had to do this all in many other frameworks, this would have been a many day project -- NativeScript was only a couple hours to get it all working...

Optimization Gotcha's for for/i and forEach

So I mentioned something on my interview with Alex of NativeScripting.com that he did with me. And someone asked about this in the comments, so I decided to create a blog article on this specific optimization tip.

I am going to code this to a browser rather than in NativeScript because well JS in a browser is just plain easier to show the memory issues because you can plop the code in to a new browser tab and step through the code instantly. 🙂

<html>
<body><div id="stacklayout"></div></body>
<script type="application/javascript">

// Pretend Color class to be similar to NativeScript
class Color {
    constructor(val) { this._color = val; }
    toString() { return this._color; }
}

const <strong><em>colors </em></strong>= ["#ff0000", "#00ff00", "#0000ff"];
for (let i=0;i&lt;<strong><em>colors</em></strong>.length;i++) {
    const labels=["Wow","Awesome","Interview", "Alex", "Created!"];
    for (let j=0;j&lt;labels.length;j++) {
        const clr = new Color(<strong><em>colors</em></strong>[i]);
        const txt = <strong><em>document</em></strong>.createElement("div");
        txt.innerText = labels[j];
        txt.style.backgroundColor = clr.toString();
        const parent = <strong><em>document</em></strong>.getElementById("stacklayout");
        parent.appendChild(txt);
    }
}
&lt;/script>
&lt;/html>

And you should see something like this:

We are repeating the labels for each of the primary colors...

Or you might be used to doing something like this instead:

&lt;html>
&lt;body>&lt;div id="stacklayout">&lt;/div>&lt;/body>
&lt;script type="application/javascript">

class Color {
  constructor(val) { this._color = val; }
  toString() { return this._color; }
}

["#ff0000", "#00ff00", "#0000ff"].forEach((clr) => {
  ["Wow","Awesome","Interview", "Alex", "Created!"].forEach((word) => {
     const txtColor = new Color(clr);
     const txt = <strong><em>document</em></strong>.createElement("div");
     txt.innerText = word;
     txt.style.backgroundColor = txtColor.toString();
     const parent = <strong><em>document</em></strong>.getElementById("stacklayout");
     parent.appendChild(txt);
  });
});

&lt;/script>
&lt;/html>

Both have several issues, however the second one can be vastly worse than the first one depending on how many iterations. So lets walk through the issues.

So the Color class is fine, we are using it to show creating objects... So just ignore it for now.

const <strong><em>colors </em></strong>= ["#ff0000", "#00ff00", "#0000ff"];
for (let i=0;i&lt;<strong><em>colors</em></strong>.length;i++) {

These lines are fine, we allocated colors, then looped through them. So far so good. Lets proceed, what about:

const labels=["Wow","Awesome","Interview", "Alex", "Created!"];

Well here is the first issue; Fortunately for us, the v8 JS engine actually pre-allocates the 5 different string "Wow" through "Created!" when it parses the JavaScript however, each loop through it does create a brand new Labels array and then links those strings into it. So in this case it is small overhead; however in the 3 loops that still is 2 more sets of allocations and all new GC enties that have to be cleaned up after the loop is completed. If you were to put this single line of code outside the loop; your code runs the same, but no less memory usage and less processing.

 const clr = new Color(<strong><em>colors</em></strong>[i]);

What about this line, well in this case all 15 times it creates a brand new Color object. You can easily make this only be ran 3 times just by moving it outside the inner for (j) loop into the for (i) loop. In this example the Color class is very light weight. But many classes you create inside loops will be very heavy with lots of allocations going on when you allocate the class. So pay attention, 3 allocations vs 15 allocations, all by putting the line in the wrong spot...

Continuing on, most the rest of the lines has to be inside the loop; but I tossed another item into the loop, that wasn't needed... This line is very easy to accidentally end up in the loop because you needed it at that point.

     const parent = <strong><em>document</em></strong>.getElementById("stacklayout");

Yep, this has to do an expensive lookup in the dom to find this element, it never changes. It also has to allocate it to that "parent" variable 15 times. If you dropped it before/outside of both loops, you would have a single lookup and allocation...

---

Finally lets look at the last example; it suffers from the same issues. However, this one I used a Array.forEach rather than the simple for (i) loop. Why do I say it can be worse then? Well in small numbers, the difference is actually pretty tiny. The extra amount of memory it uses over a for (i) loop is also reasonable. But in larger loops (especially loops inside of loops inside of loops); the difference can end up being exponentially larger.

Your creating and calling functions, and all those functions now has added scopes and the engine has to setup all the callstacks for each and every iteration, additional error checking and just plain running a lot more code behind the scenes. So what is a simple for (i) loop in the first example, now became 15 EXTRA functions calls with all the extra overhead of cpu and memory that entails. Again in small chunks they are perfectly fine, but if you are wanting performance, every ms and gc adds up and sometimes they can add up very quickly when dealing with the Array helper functions that use callbacks...

As a better way to phrase this; imagine you have a for (i) loop that takes 5ms and a forEach loop takes 25ms to finish. Both are still dang fast, hard to even benchmark. But now you embed it in another forEach that also by itself takes 25ms. 25ms * 25ms = 625ms. More than half of a second. But, if you were to switch this to a for (i) loop each of them is 5ms. So, 5ms * 5ms = 25ms. Both are exponentially larger, but 25ms vs 625ms and the difference starts becoming much clearer. Now add a third loop; 5ms*5ms*5ms = 125ms. 25ms*25ms*25ms=15,625ms (or > 15 seconds!) In small chunks the time and memory used from a forEach is minuscule. But depending on how many times it is called; it can add up very quickly to be a major difference.

Please note this goes for all the nice Array helper functions, .map, .reduce, .filter, etc. Everyone of them that uses a callback, has somewhere between 2 times and 50 times as much overhead as a simple for (i) loop. Remember, despite this overhead; these functions are extremely fast. So don't be afraid to use them, but be more wary of using them in deeply nested code that can easily be called in loops when the datasets they are working against are also large.

As many items that you can actually move outside of your loop, the better off you are. This Includes any expensive calculations! You might be able to do 99% of the expensive calculation outside of the loop; and then finish off the last part of the calculation inside the loop...

I hope this answers the question about loops and performance. Every loop is a golden opportunity to greatly enhance your app,

Oculus and their horrible support policy, a tale of woe!

I've had a lot of bad experiences with companies over the years; but this one takes the cake (The cake is a lie!) for me, in how not to treat a customer (let alone a developer in your ecosystem).

For those who don't know who I am, I have written somewhere around a 100 plugins both open source and many for different clients. Primarily for the cross platform framework NativeScript. So I have plugins from making Unity run and communicate with NativeScript to even making ColdFusion be able to drive an NativeScript app. On the Hardware side, everything from mobile printers, credit card readers and just a week or so ago the cool SocketMobile barcode scanner. All of them work great with NativeScript. So in a nutshell, I play with lots of hardware and software and write a lot of code in a lot of industries, including optimizing business practices...

As such I have a number of phones, one of them is the Samsung Galaxy, which supports the GearVR, so as such I have been a Oculus developer for multiple years. I've been working on a couple ideas; and even created a couple concept Unreal apps on my GearVR devices.

So as many of you might not be aware of getting a Oculus Quest is a an experience in frustration, they are sold out everywhere (unless you want to be scalped and pay twice as much).

So, I thought I scored last week. I read an article that Oculus finally had some stock again. Connected to their site; found that they were already out of stock on the 64 gig version, so decided because I have no idea when they will be in stock again, I'd spring for the larger more expensive version... So placed my order, had an order number, everything seemed to be great...

Then the pain begins....

Two days later around midnight, I get this message:

I'm like what the HELL, I've been waiting forever and they just CANCELLED my order, no contact, no nothing; just lets cancel it... (Serious question, Oculus, why don't you put in this message why it was cancelled, since the person cancelling it knows.)

Make it stop...

Ugh, of course, I went immediate to their site and guess what:

Yep, all sold out again.. Shoot, well maybe they can undo the cancellation; and we can figure out why they would cancel a order and fix whatever mistake was made. Clicked the support link and of course it brings you to the generic support site (Serious question, Why doesn't the email link put you on the proper url?). Spend a few minutes finding the right form to fill out and send them a question asking the simple easy question of "Can you tell me why my order XXX was cancelled?"

Lets apply the thumb screws...

The automated system sent and email response and stated, it could be up to two business days; but they did respond in one! Very late the next day I get a message from CS saying thanks for contacting us... But man my heart dropped.

  1. do not create any new orders (Not than I can, its out of stock already!)
  2. WE ARE UNABLE TO RE-INSTATE IT.

At this point, I realize, I am screwed, I can't reorder even if I wanted to; and that they won't re-instate the order. They officially jumped from well this experience so far just sucks, wasting my time... to Oculus customer service/order system really sucks. WHY THE HELL DO YOU CANCEL A ORDER, IF YOU CAN'T RE-INSTATE IT? Seriously bad customer interaction at this point... If their is a order issue, and you can't re-instate it, then suspend/pause the order and deal with the issue, don't just CANCEL the order leaving the customer with NO recourse...

Electric shock therapy is best...

And to top it off; lets see why the cancelled it (this message came the next day)

So basically:

- If I'm in the military and serving anywhere outside of the United States and decide to buy a US model, I can't...
- If I'm a expat living anywhere else in the world; apparently we can't either.
- If I'm uncertain where I'm going to be in the near future (like was in college, now at home), and decide that I want to make sure all my mail is handled and sent to where I am currently, no matter when this ships and arrives... I can't...
- Worried about spouse abuse and sending all mail through a third party to eliminate the ability for them to track me via my mail. I can't....

Really, Oculus! You f**kin cancelled my order because I ordered a SINGLE device, am a known developer in your developer program for several years and wanted to ship it to a place that can re-ship it to where I'm actually located right now. Your going to cancel the order, leaving me no recourse...

Maybe Bleach will work...

Then state I can order it this way from any of your support partners, seriously? You say we can't do this; but you can get around us, this way. Here's a link to make it much simpler!

Honestly, management needs to make some heads roll, that has to be the stupidest policy I've ever heard of...

But for those who typically use a Reshipper/concierge for your mail; you need to use a friend (which I would have done had I known that up front, now it is too late!)...

NativeScript 6.3.0 Released

NativeScript 6.30 has a couple cool new things; but better yet it fixes several issues that can will affect your users if you are using 6.2.x lets look at them...

Some of the fixes include instability during android's switching of applications and resuming it. An issue with unloading views on Android. Out of memory situation on Android, and dialog fixes for iOS. In addition to several important build fixes that appear to solve a lot of build HMR related issues. Overall this release is worth upgrading to for just the bug fixes alone.

Core Modules

NativeScript is getting a new CSS parser; unfortunately it is not enabled by default in 6.3; but based on a PR should be enabled by default in 6.4. If you would like to enable this in your app to see how much faster it can parse your css; you do so by editing the packages.json file that ships with the application and adding a new key called "cssParser" and set it to "css-tree". The valid options are "rework" (current parser) and also "nativescript" which was the original css parser.

We had a couple awesome community PR's this month the first by Eduardo Speroni adds requestAnimationFrame as a supported function. And the second by Shailesh Lolam  add dialog sizing (width & height properties) to the modal dialogs on iOS.

And finally to round up our new core module features; Modal dialogs now have all the same CSS properties applied to them to allow better styling. In addition to the normal properties, a new .ns-modal class is applied.

CLI

The CLI team has fixed several outstanding bugs; including several webpack hmr issues. This also includes Node 13 and Android API 29 compatibility.

V8

I'm going to create this new v8 Section, because Android and soon iOS will both be using the same v8 engine. v8 was upgraded to v7.8 which adds:

  • Faster object destructuringconst {x, y} = object; This is now as fast as the normal ES5 const x = object.x, y = object.y;
  • Lazy source positioning; which can save 1 - 2.5% of memory; basically instead of storing all source code lines for when errors occur; it recalculates it when it needs it.
  • Faster RegEx
  • Several Wasm improvements

Android

The Android team kept busy this month;

  • Fixed some Kotlin issues
  • Android Signal 1 & 11 are now captured
  • Fixed a worker issue
  • Upgraded to V8 7.8 (See v8 section)

IOS

  • Upgraded to WebKit 13.2
  • Several metadata fixes
  • Fixed a worker issue
  • Fixed debugger not working issue
  • Fixed discardUncaughtJsExceptions issue

    A lot of changes to the new v8 version of the iOS runtime that is still in alpha testing to eventually replace the JSCore version... It appears the iOS v8 version is shaping up to be an awesome release.

Updating NativeScript

To get updated; you first need to do:
npm i -g nativescript@latest

To update a project; you need to do the following:

Latest Runtimes:
tns platform remove android && tns platform add android@latest
tns platform remove ios && tns platform add ios@latest

Latest Core modules:
npm r tns-core-modules --save
npm i tns-core-modules@latest --save

To install Webpack support:
npm i nativescript-dev-webpack@latest --save-dev

To install latest NativeScript Angular plugin
npm i nativescript-angular@latest --save
You will then need to install the actual angular bits; which as of this post v6 is currently supported.

The addition of t additional analytics/tracking to the CLI reminded me; you can disable it permanently; if you value your privacy by doing:
tns usage-reporting disable && tns error-reporting disable

ProPlugins - end of year update

We started the ProPlugins project pretty close to the launch of NS (NativeScript) 6.0. So it has only been active for about five months now. So how is it doing???

Well, first let cover the reason why we created it. This plays in strongly into how well ProPlugins is doing.

Why ProPlugins?

For most of us plugin developers who have worked in the NativeScript eco-system for a while. We all knew that NS 6.0 had a range of breaking changes; which meant it was the fifth set of breaking changes in less than 4 years for plugins. Each one of the NS major releases, had a range of breaking changes that required certain types of plugins to make fixes. Sometimes the changes were minor, other times the changes actually requires some major rewrites and/or major time debugging why something was no longer working properly. Of course the vast majority of this work was done by the original author; with very little or no help from the rest of the community. I recommend you read all three of my prior blog posts on the plugin costs and the plugin problem. And then why we believe ProPlugins is the solution. With those posts you will have a pretty good idea that the actual costs to an author, the community involvement, and how the open source seems pretty much unsustainable.

In addition to our experience, their are lots of blog posts by many other authors, on how for the most part, the majority of projects that are open source by independent developers has a serious funding and/or burnout issues. We have seen the exact same thing in the NativeScript plugin community way too many times. in fact, the other day I responded to a issue saying that I believe a specific plugin was still maintained as this author has been around for a while -- and then several people pointed me to the issue where the author has mentioned it is no longer maintained. Sadly another excellent plugin author appears to have left the community.

Community Involvement

When we FORKED all these plugins into ProPlugins, the original version was left to see how much the community would be actually willing to maintain them. My stance has been that I didn't believe the community would change any; but I have been 100% committed to allowing the community to prove me wrong and send in any PR's and I would publish the new version fairly quickly.

Sadly, my prior blogs posts on the problem, which tells the sad tale of how many PR's per plugin is received from the community before ProPlugins was created. The communities involvement still has not changed, and as such we have still only seen less than a handful of PR's for all 40 of the plugins we forked into ProPlugins. Meaning the vast majority of all these plugins probably don't work with NativeScript 6.x. This doesn't surprise me, since I had seen this lack of involvement for the last 4 years of plugin development...

The most interesting thing, is that this experiment really could have gone a couple ways. I could have been proven wrong and the community would have finally stepped up and worked on fixing all the plugins for NS 6 support. Or even the worst possible outcome, nobody could have joined, and also nobody did anything to fix any plugins. However, it seems the community has decided that joining ProPlugins as the best option to move forward. It eliminates them from having any additional time commitments, and helps us create sustainable source code.

So how has has ProPlugins done?

We grew to have 40 fully maintained plugins, which have had around 30 PR's for issues introduced in the NS 6.0 upgrade. We have done several PR's for issues people found in the last couple months to several of the plugins. We have also added several new features to multiple plugins. Finally, recently about 10 PR's for different plugins to fix the breaking change that was accidentally introduced in NS 6.2. So adding and maintenance of existing plugins seems to be off to a very successful start.

In addition, this new year we have several new plugins that we have plans to add. Even better, we have more authors lined up for joining the ProPlugins program. So by the end on 2020; we hope we will have around a hundred fully maintained top quality plugins in the program.

Despite the lack of any recent advertising and really my total lack of my focus on it for the last couple months; ProPlugins has each month done considerably better than the prior month. So our subscription revenue has been increasing faster than I had planned.

Since 80% of all revenue goes to the authors, the remainder goes to the actual expenses like paypal fees, advertising, servers, etc. We believe, the ProPlugins experiment has successfully started the process to having sustainable source code in our community, completely from the community. So a big congrats to the community for helping fund this!

We hope you all have a merry Christmas, and a happy New Year. We look forward to even more of you becoming part of the ProPlugins project and helping us fund sustainable open source for the NativeScript community.

NativeScript Offline Plugins

There are cases where you might want to package plugins with your app in your version control; like for example you are using a commercial plugin or maybe a proplugin and need to use cloud building.

The simplest setup that I have personally used is in the very root of your application.


You create a folder called plugins. Inside this folder you put any commercial and plugins you need to keep with the apps source. For example one of my projects looks like the above picture, I have 5 plugins that are actually in version control with the application. So anyone checking out the source code from git will get all these plugins with the application.

To use these plugins in your NativeScript app, in the root directory you type "tns plugin add ./plugins/nativescript-compress-0.0.1.tgz" you need to type the ENTIRE name including the extension.

How do I download them

So say I want to have the proplugins/nativescript-dialog plugin.

npm pack @proplugins/nativescript-dialog
will download the latest .tgz file into the current directory for you.

NativeScript 6.2.0 Released

NativeScript 6.20 has several fixes, and finally added the long awaited Scoped packages. UPDATE Scoped packages apparently breaks some things. See here for more info on how to deal with it.

Scoped packages; are where you can now do

const label = require("@nativescript/core/ui/label" rather than the older const label = require("tns-core-modules/ui/label");

This makes things a lot cleaner and over time more times should end up in the @nativescript namespace. Currently in the @nativescript namespace is:

  • Core Modules
  • Theme
  • Angular

Core Modules

Since they added the ns-root, ns-landscape, ns-phone, etc; in the prior version of NativeScript they have added even more css functionality in this version. ns-light and ns-dark are now added values which you can use to select specific theme color rules. They are added depending on the devices theme. Along with that change, more css optimizations, including hsla color support were added. A long awaited and very welcome fix to allow values to be reset to default when css rules are disabled was also finally done. Overall just the CSS fixes are worth the price.

Another cool change is they updated they revampled the android transition code. Should be better and more customizable. In addition Android also got ContentInset properties on the ActionBar. And iOS got selectedSegmentTintColor on the Segment bar.

Finally, the awesome community PR that was snuck into this release is Peter Staev's async read/write addition. readAsync and writeAsync allow async access to the file system.

CLI

The CLI team has fixed several outstanding bugs; things like Asset generation, several webpack issues, cocoapod fixes.

V8

I'm going to create this new v8 Section, because Android and soon iOS will both be using the same v8 engine. v8 was upgraded to v7.7 which adds:

  • Lazy feedback allocation - this reduces the memory load of the v8 engine, which is always good to have on mobile devices

Android

The Android team kept busy this month;
- They improved the error logging.
- Added Kotlin extension function support
- Added JSONObject support
- Upgraded to V8 7.7 (See v8 section)

IOS

Fixed a Mashalling issue from "unsigned char *"
Fixed losing some exceptions in TS from runtime

A lot of changes to the new v8 version of the iOS runtime that is still in alpha testing to eventually replace the JSCore version... This new runtime has pretty close to the same feature parity as the Android versoon. I'm sure the iOS team would LOVE you all to test out this runtime on your apps to verify they work properly -- you can do so by using tns platform add ios@alpha-v8 to tell it to use the v8 runtime.

Updating NativeScript

To get updated; you first need to do:
npm i -g nativescript@latest

To update a project; you need to do the following:

Latest Runtimes:
tns platform remove android && tns platform add android@latest
tns platform remove ios && tns platform add ios@latest

Latest Core modules:
npm r tns-core-modules --save
npm i tns-core-modules@latest --save

To install Webpack support:
npm i nativescript-dev-webpack@latest --save-dev

To install latest NativeScript Angular plugin
npm i nativescript-angular@latest --save
You will then need to install the actual angular bits; which as of this post v6 is currently supported.

The addition of t additional analytics/tracking to the CLI reminded me; you can disable it permanently; if you value your privacy by doing:
tns usage-reporting disable && tns error-reporting disable

NativeScript 6.10 Released

NativeScript 6.10 has several fixes, and a couple new features to make it worth your time to upgrade. 6.1 has to be one of my favorite recent releases.

Being biased here, the best fix is the PR I did; it allows the tns command line to actually be used with our awesome https://proplugins.org site. You could easily use NPM to work around the issue; but it is always better if the standard NativeScript cli tooling also works. So, I am ecstatic to see this show up in 6.1. So now completely removing my bias; the new ios wifi deployment support (which I haven't tested); is something I have really needed for a while, so awesome job team!

Core Modules

Their are a couple changes in Core modules that are worth noting. First of all; for those who have used my awesome nativescript-platform-css plugin for years; the NativeScript team finally decided I was right! 😀 They have not only stolen, er, borrowed, the idea to put device type in the class name (ns-android & ns-ios) , but they also borrowed the same idea I did in my nativescript-orientation plugin, which is put the orientation (ns-landscape & ns-portrait) into the class also. Unfortunately, I am a bit sad they still didn't have the foresight to borrow my poor-mans-media query system; it is still way better than nothing. Nor did they decide to use the device name css system, or any of the additional classes like .notch. So if you still need media query or actual device name support or anything else the platform-css; then you can continue to use the ns-platform-css plugin. And the ns-orientation plugin still offers the ability to force rotation and/or lock the rotation to a certain direction, so neither plugin will be discontinued because of the additional functionality both plugins still offer that the team didn't borrow.

In addition another community PR was accepted to add CSS calculation support! Unfortunately do to a minor oversight, it is broken in 6.10, but I would guess it should be fully fixed in 6.11.

CLI

This team has hit several home runs this release with me. In addition to getting my PR merged which solves the npm issues. They also added awesome iOS Wifi deployment support. And added iOS 13 and Xcode 11 support. Overall the CLI release looks to be a very awesome release.

Android

Android added several cool things in 6.1 also. First and foremost; Initial Kotlin compatibility has been added. This is very preliminary; so many things may not work.

Second they upgraded the the v8 Engine to 7.6 which adds the following features and enhancements

  • New much faster JSON parser
  • Promises.allsettled

In addition to the cool features added, they have also updated it to allow the latest Android tools and latest gradle. Also, they now added gradle.properties support so you can easily define properties next to your other gradle files...

IOS

Added metadata generation from inner members
Fixed issues with latest version of iOS and Xcode

Updating NativeScript

To get updated; you first need to do:
npm i -g nativescript@latest

To update a project; you need to do the following:

Latest Runtimes:
tns platform remove android && tns platform add android@latest
tns platform remove ios && tns platform add ios@latest

Latest Core modules:
npm r tns-core-modules --save
npm i tns-core-modules@latest --save

To install Webpack & HMR support:
npm i nativescript-dev-webpack@latest --save-dev
Note: you need to have nativescript-dev-webpack as a development dependency for HMR to work.  

To install latest NativeScript Angular plugin
npm i nativescript-angular@latest --save
You will then need to install the actual angular bits; which as of this post v6 is currently supported.

The addition of all the additional analytics/tracking to the CLI reminded me; you can disable it permanently; if you value your privacy by doing:
tns usage-reporting disable && tns error-reporting disable

NativeScript 5.40 Released

NativeScript 5.40 only offers a smaller number of fixes and features than usual; but is still well worth upgrading to. It will probably be the last major 5.x release. NativeScript 6.00 is on the horizon...

The most interesting update (for me) is actually the Android V8 engine has been upgraded yet again. Android engine is now on v8 v 7.4 - which offers even faster JavaScript parsing (in some cases up to 10% faster) In addition to the engine speed ups; v8 now has better memory management and much better deadcode elimination.

So just upgrading the runtimes to 5.4 should again give you a faster android app... So it is worth it just for this alone. Nothing changed on the iOS side here...

In addition the v8 v7.4 now offers support for Private class variables; an ESNext feature that is finally shipping in v8. If you are unfamiliar with this feature, this feature is needed for keeping private variables private. 😀

class CoolClass {
  iAmPublic = 1;          // .iAmPublic is public variable
  #iAmPrivate = 2;        // .#iAmPrivate is private variable

  getIAmPrivate() {
     ++this.#iAmPrivate;
  }
}

const m = new CoolClass();
console.log("I am private now equals:", m.getIAmPrivate()); // runs OK
m.#iAmPrivate = 0;  // TOTALLY FAILS!   

Unfortunately, JavaScriptCore does NOT support this feature yet and the code will fail to even parse on JSC, so don't use it in any shared code. This is an Android only feature. TypeScript will soon be adding this feature, so this should become a common way of making class fields private...

Important Depreciation Notice

In version 5.2 short imports have been depreciated; I do not know when they will no longer actually work; but basically things like require("http") are no long valid; you need to do require("tns-core-modules/http"). The primary reason for this is that webpacking requires the full path; and it has problems with short imports. Please note this now becomes more critical that you handle this; NativeScript 6.00 will be 100% webpack only; meaning that if you don't fix your code it might fail to build until you do so in NativeScript 6.

Core Modules

The core modules offers the following enhancements and fixes...

Multiple iOS components have crashing issues fixed
FormattedText crashing issue fixed

Android

Upgrade to V8 7.4.288 - which offers
- Private Class Fields
- Faster JS Parsing
- Better Dead Code Elimination
Static Binding Generator fixes and enhancements
Gradle 3.40 support.
Several memory leaks fixed
v8 Symbols exportable (for native v8 extensions)
Elevation Shadow Support

iOS

Allows compiling Swift code as part of app_resources
Minor leak fixed
Unicode crash fix
Some Metadata generation fixes

CLI

HMR is now the default app type
TNS Create Plugin fixes
Better handling of CTRL-C
CocoaPod handling improved



Updating NativeScript

To get updated; you first need to do:
npm i -g nativescript@latest

That will get you the latest version of NativeScript CLI; once you have it; do a "tns --version" and verify it prints out "5.4.x".  Then do a "tns doctor" to verify your environment is up to date and has all the newest support tools you need for a successful build.  

To update a project; you need to do the following:

Latest Runtimes:
tns platform remove android && tns platform add android@latest
tns platform remove ios && tns platform add ios@latest

Latest Core modules:
npm r tns-core-modules --save
npm i tns-core-modules@latest --save

To install Webpack & HMR support:
npm i nativescript-dev-webpack@latest --save-dev
Note: you need to have nativescript-dev-webpack as a development dependency for HMR to work.  

To install latest NativeScript Angular plugin
npm i nativescript-angular@latest --save
You will then need to install the actual angular bits; which as of this post v6 is currently supported.

The addition of all the additional analytics/tracking to the CLI reminded me; you can disable it permanently; if you value your privacy by doing:
tns usage-reporting disable && tns error-reporting disable


Known issues

NativeScript 5.1.1 Released

Even more fixes have come down the pike. Based on some of the bugs that have been squashed it appears that if you are using v5.1.0 you want to upgrade to v5.1.1 as it should make your life a little easier.

Core ModulesT

Technically they released 5.1.1 of the core modules last month; as it was a quick release that fixed several issues with 5.1.0.

v5.1.1 several android issues; and added a new ios model system, they moved context into an options hash that you now pass in its place; in addition several other parameters that used to be separate parameters are now part of the context. This cleanup allows new features to be added in the future. The old showModal function is still supported, but marked as depreciated.

5.1.2 was released with the rest of the updates this week; this version fixes the Android crash in Listview switching templates.

Android

Nothing done which needed a new Android runtime version...

iOS

Debug logs show in Chrome again

CLI

Debugging on iOS when using HMR is now fixed, many issues resolved
Many Yarn support issues fixed
Sidekick and Preview app fixes
A couple CLI crashes fixed when running/debugging.


Updating NativeScript

To get updated; you first need to do:
npm i -g nativescript@latest

That will get you the latest version of NativeScript CLI; once you have it; do a "tns --version" and verify it prints out "5.1.x".  Then do a "tns doctor" to verify your environment is up to date and has all the newest support tools you need for a successful build.  

To update a project; you need to do the following:

Latest Runtimes:
tns platform remove android && tns platform add android@latest
tns platform remove ios && tns platform add ios@latest

Latest Core modules:
npm r tns-core-modules --save
npm i tns-core-modules@latest --save

To install Webpack & HMR support:
npm i nativescript-dev-webpack@latest --save-dev
Note: you need to have nativescript-dev-webpack as a development dependency for HMR to work.  

To install latest NativeScript Angular plugin
npm i nativescript-angular@latest --save
You will then need to install the actual angular bits; which as of this post v6 is currently supported.

The addition of all the additional analytics/tracking to the CLI reminded me; you can disable it permanently; if you value your privacy by doing:
tns usage-reporting disable && tns error-reporting disable


Known issues