Monthly Archives: June 2017

NativeScript: 3.1.x released

Looks like I was asleep at the wheel; according to NPM 3.1 was released late last week; and I totally missed it.   However, I am more on the ball today and saw that 3.1.1 was released today to fix some of the issues with 3.1.    So lets cover the changes in both 3.1 & 3.11

  • Android Chrome development tools now supports the Elements tab; this allows you to see what css is assigned to elements in the UI DOM.  Very nice feature!
  • Android snapshots can be generated on Linux and Mac.  This allows you to make a custom snapshot; snapshots will improve startup time; but they do have the downside of increasing the size of the APK a lot.
  • Android now support ABI splits on first build.
  • Profiling on Android, you can now enable a profiling to see what is taking time in your application.  The feature is also available in @next on iOS.
  • CLI has been improved to fix a lot of issues, including Node 8 / npm 5 support.
  • Several fixes for the SearchBar, and TextFields now have a maxLength property!

Upgrading (Core):

First of all to upgrade is done is a couple steps:
> npm install -g nativescript@latest
> npm install tns-core-modules@latest --save

Next try the new update command or you can manually run the commands below
> tns update

For Android:
> tns platform remove android
> tns platform add android@latest

For iOS
> tns platform remove ios
> tns platform add ios@latest

Then you can type tns info and verify that everything says 3.1.x

Common Issues:

  1. Plugins fails; this is a known issue do to the complete revamp of the lower levels of the core modules design.  Some plugins need a lot of changes to work in 3.x; so you will have to wait for the third party authors to get caught up (Even I'm not caught up).    My plugins site  http://plugins.nativescript.rocks should be listing both version v2 & v3 plugins separately so that you can easily find 3.x or 2.x plugins.
  2. TypeScript incompatibilities; you should be using 2.2 or later with v3.x of TNS
  3. A new  3.1 CSS issue with Background Color
  4. Android runtime can still crash randomly with No weak reference found. long standing unfixed bug...  Disabling screen transitions, seems to help resolve the issue.
  5. Webpack might have random issues in Android builds, you might need to to a tns platform clean android to fix occasionally
  6. Issue with upgrading applications on Android 6 & 7 see blog post on fix.

NativeScript: @Next- should I use it?

Short version: Nope...   😉

Long Version:

I see this pop up frequently in the bug tracker and slack where someone is complaining about a issue; then we all find out it is a issue in the @next version.    Unfortunately Telerik really did everyone a huge disservice when they named it @next.

This is not actually the next version of that specific repo/codebase.     What, you say???  But it is named next.   Yes, I'm sorry to say it is totally a mis-named tag.   None of the repos have an actualNEXT branch.

The @next tag is actually tied to the MASTER branch.    And Master is not a RELEASE branch in NativeScript.    Master is used for testing, and validating things.  Once they have been validated and the feature(s), or fixes approved;  then that single item will be tracked and eventually moved into the Release branch before the real next upgrade release.

In the meantime if you decide to try @next, you will have many features/bugs that are still in testing or transition that might not even be 100% complete or working properly.     Now the Telerik devs have been trying really hard to keep the Master branch in a usable state (Kudos for the guys putting "DO NOT MERGE" on really major pull requests that are still being developed).   But even with them being careful; Master is still a DEVELOPMENT branch, so just like my own DEVELOPMENT branches, thing will slip through.   Or a design change will occur; where we decide to refactor something and then the current "master" is broken in some weird way that we didn't anticipate.   In addition there will be many features/bugs that are present on Master that will never be in Release in that form.    So, @next != release or really even release quality.

Please if you don't need to upgrade to @next; don't do it.  Not only will you stay saner; you won't be wasting peoples time with issues that are frequently meaningless.   @Next is really so that you can test if a bug is fixed; but be very leary of using it for ANY other reason, the rest of the non-release changes in @next will probably bite you...

However I would ask that if a bug you reported is fixed on @next; please upgrade temporarily to verify the bug is fixed, and report back to the team.   This is helpful for them to know they squashed your bug as you see it.   But once you are done,testing; I would highly recommend you go back to the @latest tag.   😉

To upgrade you do npm i tns-core-modules@next  (Example sake; we are assuming it is the core you are upgrading, but all the repos have a @next).   Then a tns platform clean android or ios.  Then re-build and run the app.    When you are done testing, change the @next to @latest, and you will get the latest RELEASE version available for that repo.