Category Archives: Uncategorized

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

Australian AABill

If you look at my blog; I do believe this is the first article I've ever written about something political.  I tend to be anti-political because I feel like it just divides us and tends to be just complaining with no one actually doing anything meaningful about it.

However two days ago I noticed in the news that the AABill was about to be passed.  I had read about it before, but since I'm not Australian (and I don't work in Australia) it really doesn't affect me "personally" right this minute.   However, the reality hit me later, that it does affect my friends; and it has a very high chance of affecting all of us in the future.  What the Australian government gets away with now; the rest of the "civilized" countries will also attempt to implement someday.    

Our own (USA) FBI has been hankering for this power for years; and so far they have been thwarted; the Canadians have thwarted similar issues in their country.   Europe; has caved to a lot.   So much of what Australia did; they took from Europe.  They just went a lot farther.  The more nations that cave; the easier it is for the other nations to do the same thing and go farther.   

This bill is BAD!    So bad, if it was meat it would have to be launched into the sun to actually eliminate the deadly bacteria.   If it was a meteor we would all be wiped out instantly.   

In a nutshell the bill gives the Australian government the right to require people and/or companies to implement back doors into any systems (web, phones, your apps, banks, encryption, etc).   

  • No real¬† over sight¬† ¬†"Trust us; we won't abuse it..."¬† ¬†(I bet they¬† have a bridge to sell us too.)
  • Massive mandatory punishments for speaking about the request; to anybody -- even if it is to defend your reputation or job when the back door is found..
  • Severe Anti-whistle-blower rules to eliminate anyone attempting to do the right thing, when the government is doing the wrong thing.¬† ¬†Trust us we won't abuse it...
  • The improbability that the person served with the "backdoor" order can actually bypass the security of any company that is multinational is... well, rather ludicrous.¬† More than like instead it will cause their own termination and potential black balling of the poor developer in the industry since he can't defend himself nor mention why he tried to subvert the software.
  • Trying to backdoor anything, is a criminal paradise.¬† ¬† We all know that no bad guys ever fine issues in any thing, never happens...
  • Backdoored encryption, what a joke.¬† ¬†
  • What Australian developer (or company) can I now trust with my code, data or hosting?
  • Beware of that bridge for sale...

I can go on an on about the terrible things in this bill...   Suffice to say; this is a very bad bill and that it has world wide implications.

I posted on twitter that I thought that maybe the internet community should route all the Australian government IP's to a banned page saying that until the bill is repealed they are being segregated to limit any more damage they can generate.

Several people posted they thought that was a good idea.   And it dawned on me, all I was doing was still just complaining and offering ideas that nobody would probably do.   In all reality I wasn't really doing anything at all.

So I got off my butt; and actually did something.   I purchased the domain name internetprotests.com; I then proceeded to setup a simple site.  Figured out several blocks of Australian government IP's to be routed to the banned page.    Figured out how to make the routing work in both Apache 2.4 and Nginx, and published the site.

I have attempted to start something here; and I cannot do it alone.   

If you are a internet provider or you have control over a website.  I urge you to check out the internetprotests.com site and become involved.  The more sites that blackhole all the Australian Government IP's; the more likely they will be forced to actually repeal the law if they want to be able participate on the internet.   

 If you don't own any websites; please pass this blog and/or the site around.  If you do copy editing, graphics works or technical work; the site is open source and could use more work prettying it up and making it more appealing to the masses and the press.   It was built quickly to try and spread the word because the tech world is starting to understand just how bad this law is.

If we can get the law repealed in Australia; then that will make all the other nations have second thoughts about trying it in their nation.   Maybe we the people of the internet can actually get our government to listen to us and follow our lead...

Security with Apps on iOS and Android.

Recently a person on twitter asked about a statement that Max made in a blog article which he did on the official ionic blog.  For those who know me; I actually am pretty heavily into security; and I happen to have used many mobile technologies  Cordova/Phonegap/ionic, Flutter, Titanium, React Native, Java, NativeScript, ObjC, Swift, etc -- so this article is right up my alley.   So lets start with the quote that started the tweet...

Some toolkits, like NativeScript, take the approach of exposing every Native SDK API to JavaScript. We think the security implications of that are undesirable, and it doesn’t remove your need to learn platform-specific APIs. We don’t think you should have to learn those APIs if you don’t want to, and we don’t think you should expose all Native APIs to JavaScript for security reasons.

(Quoted from Max's blog post linked above)

Initially I saw this tweet and was well saddened that Max feels he had to bad mouth his competitors to make his product potentially look good.   Unfortunately the statement Max made is 100% pure marketing FUD (Fear, Uncertainty, & Doubt).  He is just try and make a competing framework look bad with the hot button topic called security.    All it does in my opinion is make him, and his product look bad, and it is on the official ionic blog.   Compete on what you do great; not on trying to make the competition look bad (especially with FUD).

The real truth of this matter is that no matter the framework the same security surface exists.  Unfortunately for Max, this includes ionic!

So lets say I'm a evil person and I want to take over the world with my evil ionic app.   What do I do?

[I]...wrap a Native SDK and expose it as a reusable component that can be easily consumed in JavaScript ... Native Views provide a structure for wrapping and consuming a Native SDK so that it can be easily and safely exposed to JS...

(Quoted: from the same blog post linked above)

Oops; I guess I safely exposed some very bad methods  and succeeded in doing the exact same thing in ionic.  The only thing is I had to add the exact same code in a different place and expose it so it is easily consumed  using my exposed call "doBadThing()" in the JavaScript side of ionic when I need it to do my evil bidding.      Does that mean ionic shouldn't be trusted since I can easily and safely do very bad things in ionic?   See the problem, for me to do GOOD things in ionic; that gives me the same power to do BAD things in it.  

The reality is this means that just like I can do bad things in 100%  pure Java app, Kotlin, C/C++, NativeScript, React Native, ObjC, and Swift (name the framework); I can do it just as easily in Ionic.  None of them are immune!     This doesn't mean any specific platform is worse or better; they all have the ability in one way or another to access the exact same api's which can be used for evil purposes.   The bad code in all of them is literally the same; just the location in the app calling it is different.   

Now not to get into a more technical discussing; there are some areas where the frameworks do have some differences that may allow certain things to be easier to miss.  For example; using proguard can hide method calls in native Java code.  However overall this does not change the relative security of each of the frameworks.   You name the framework; and I know a way to make it hard for you to detect my evil code..   They all have pretty close to the same level of security surface.  

Now that I've explained the FUD and debunked Max's unfortunate dig at his competitor; I would like to explain where I see the real security issues with Android and iOS.

The real security vulnerabilities is our trust model.   We are now seeing it play out more and more where a developer creates a decent app.  It gets a decent reputation and then it gets sold to another developer.   The "other" developer is sadly not your friend.  Unfortunately; they add "bad" code; upload it as a minor fix to the app; and bam your Android or iPhone now is doing stuff you would rather it not be.   This has happened on ALL platforms, ALL types of code bases and so far none are immune.   Eventually they are caught (at least we hope) and the app is removed from the stores and you see a article about how 20 apps by XYZ dev had malicious code in them...

But the root problem is trust was built; and then outside of our control and knowledge; the app transferred to a different vendor who hasn't proved himself.  This is a hard issue to solve.     Do we say when you sell your app; it no longer can be auto-updated and has to be manually updated the next time so a notice will appear?    Or can we make the stores possibly notify us on the next upgrade with a re-install dialog announcing that the app has changed hands?    What has the best chance to be detected by the community and looked into?

I think that either of those ideas would be a good first step; but it won't solve this issue.  Bad actor then waits several months and then posts his "bad" changes.   Likely hood of being caught went drastically down, as we all get busy and our trust level goes up...  But at least the community is aware of the change of ownership and so some of them might still be diligent...

My next suggestion, is something unfortunately neither Google nor Apple will ever implement because our personal information is their bread and butter...   

I believe the real solution is that our devices should have two additional features: 
1. Built in firewall added to the OS.  The firewall is allowed to block all traffic for a specific application.   Easily enabled and disabled per application.   
2. Lying Data Module - This is a little harder to explain and a bit more advanced but basically you can tell the OS to lie to the app.  The app asks for your location and you have pre-configured the OS to always say you are at the north pole.   The app asks for the temperature; and again you pre-configured the OS that the temperature is 200 degrees.   It asks for your phone number and it returns 555-555-1212.   For the apps that need the real data (like maps, needs your location) you tell OS to tells the truth about GPS location.  But otherwise the same dummy data is passed by DEFAULT to every app.   If your map app asks about your phone number, it gets the same 555-555-1212.   This eliminates the app (& companies) from actually gathering any valuable data, and effectively the database will be poisoned making it virtually worthless to the company trying to collect the data.

With those two items; you could take control of your digital lives on your android or ios devices.  Yes, it requires more setup as when an app starts you have to tell it what you want to allow it to have access to data wise.  (or maybe when it requests something).

If anyone has an idea how to actually get Google or Apple to implement this in their Operating systems; I would love to hear feedback as I feel this could drastically improve our digital lives.    (and yes I know if you have a rooted android phone -- both are available to use right now.)     

Disclaimer: I have written books, blog posts, and plugins for NativeScript; so I currently do have a preference towards NativeScript.  However, anyone in the community that knows me; knows I'm the first person to call a spade a spade and argue about how this feature is horrible in NativeScript and awesome it is in framework X.  I can tell you several things I think that NativeScript is doing wrong or poorly.  (Just look on github)    I have written apps and/or thoroughly investigated the security and software stacks of each of the frameworks I've mentioned in this article.    I am not employed by Progress, nor is this blog sponsored by them -- all posts are strictly my own opinions.     

NativeScript 5.0 Released

It has been a long road getting to this point; but I'm happy to see that the NativeScript team released The final piece of the 5.0.  The CLI tool which was the final piece was finally released on Nov 2nd; the rest of the pieces have been released for a couple days.

5.0 adds a whole lot of new awesome features; however since several pieces have changed; I would highly recommend before uploading a 5.0 app to the app stores you do another full test of your application; testing everything as several low level framework items changed for both iOS and Android.

The quick list of some of the new features in 5.0

CLI Prompts

The cli now will prompt you for input; so when you type "tns create ProjectName" you will see something like this:

You can use the arrow keys to select an option, in this screen shot; the "Plain JavaScript" is chosen and so it is highlighted.

HMR - Hot Module Replacement

This is the feature most NativeScript developers have been waiting for; this is awesome.  You know the silly change a file app restarts; change another file app restarts livesync?    Now you can do this:  tns run --hmr

HMR, allows the page and JavaScript code to be updated dynamically (no more full app restarts) ; if you change a class the class may have to be re-instantiated (like in this example), but if you change other things, like functions, the state is preserved and the new function will be what is called the next time that function is needed.   All in all, this is very HOT!   (You do need to have the nativescript-dev-webpack as a developer dependency of your project for HMR support)

NativeScript Preview

QR Code

Preview allows you to preview the application without having xcode or android tools installed and building it.  It uses the already built playground preview application to preview the app so that you can see the app on your mobile phone.   It has the same limitations as the playground site; but for most developers getting started it is a quick and easy way to start playing around with programming application.    When you type:
tns preview

you will then see the qr code in your console.  Point the playground app's qr scanner at it and then your app will start running on your phone.   Please note the entire application is uploaded to the cloud; which then your phone links to.  So if this is an issue with your company  don't use this feature.

Internal Changes

Android Core modules is now descended from the Google Support libraries; this opens up many more visual plugins and makes the app a lot more modern and compatible.   One word of caution this did require them to do a bit of reworking of several parts of the base code for android.  Their is the likely potential for new bugs to appears in areas that were bug free before.  So heavily test your app before releasing it to the stores.

iOS Core modules now have a new way to do the safe areas; this also has required a lot of reworking and so the same warning applies.  Test your app thoroughly to make sure that something in this area won't cause you any issues.  

Other android specific changes:

  • now using the v8 engine, v6.9.427.23.
  • before-plugins.gradle support
  • SBG will fail if their is a JSParser issue
  • JSParser fix for Decorators
  • Runtime issue fix with support > 26 on devices < 23.
  • Gradle is now using 3.2
  • Building is even faster now

Other iOS specific changes:

  • Typing generation improvements
  • Webkit is now using 11.4
  • Several marshalling to native from JS issues fixed.

Other specific changes:

  • Many bugs fixed
  • Webpack Vue  bundling support
  • Angular memory leak fixed
  • Styling changes to support dynamic theming
  • tslib helpers now global
  • appSettings now supports allKeys method
  • Touch event pass through now supported


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.x.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.


Known issues

Tech support & Open Source bug fixes

I get more than one message a week requesting help with one of my many open source plugins or projects.   I would really love to help you; but this is not something that is sustainable and completely unfair to my family.

Not only did you get the plugin and/or project for free; you already have the source code, documentation, and probably even a full demo that shows most -- if not all the functionality of the project.   You should have everything you need to find the answer to the question yourself.

Pretty much all my income generated is currently from my doing contract development or consulting related work.   So any "free" support work that interrupts paid work; really is a bad thing for my family.   If you are being paid to build your app; than you can see how this  even more of an issue.

If you really you think you found a bug; then by all means report it to the proper repo (https://github.com/NathanaelA) and the support will be appropriately dolled out.¬†¬† I do take bugs seriously; but again open source plugins are never as high of a priority as paid work.¬†¬†¬† The bugs will eventually get fixed; but it might take several weeks to find the time to work on it.¬†¬† In the meantime I do accept pull requests.¬† I am also much more likely to accept your PR fairly quickly and fix anything that I find broken in it; than reject it.¬† ūüėÄ

Finally, I am not opposed to supporting you; so If you really want my support; I do offer paid support https://nativescript.tools/product/11

Now back to the regularly scheduled technical blog posts.¬† ūüėČ