Category Archives: Uncategorized

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

NativeScript: 2.5 and 3.0 upgrade learning moments

Well, my son has been learning Web and NativeScript for a while and was continuing to work on NativeScript project today (Lots of cool things like GridLayouts, ListViews, Sliders).

So he finally got to see first hand the wonderful world of fun that the new NativeScript 3.0 upgrade has caused.

One of his requirements for his application was ability to include a picture with each data item.  So he used my http://nativescript.rocks site to find the plugins and then did a simple tns plugin add nativescript-imagepicker -- then a tns run android and got the error cannot require the nativescript-imagepicker file in the Android crash dialog.   So I had him do a full rebuild, then as it still doesn't work (and of course he is telling me the plugin shows in the node_modules folder on his local machine).   So, next I have him open his packages.json file.   Its not present.... Hmm, so I ask him try to do a tns plugin add nativescript-imagepicker again.  This time he saw the error about the current project does not supported 3.00 runtimes.

I'm like welcome to the wonderful world of 3.0 incompatibilities, high five time!    You have reached the pinnacle of achievement; welcome to my world!   😉

So then I explained why he was now seeing this issue; and that 3.0 is not compatible with 2.5 in several ways and all the ins and outs of why and then I said you have two choices...

  1. Upgrade to 3.0, and upgrade your plugins to 3.0 -- No guarantee all of them are 3.0 compatible, so he would need to look into that.  Even some of my plugins I haven't had time to test on 3.0 and some aren't 3.0 compatible yet.     This is something that should have been handled better by Progress, do to the number of breaking changes and sometimes missing documentation.   But as the community has time, and large number of the issues are fixed by Progess; 3.x will eventually turn into a good solid release, and this will all be a bad memory...
  2. Stay with 2.5 and grab a older version of the plugin.

He decided to go the safer and easier route so I showed him how to use the npm info naitvescript-imagepicker command to find the older version of the plugin.  In most cases the last version before 3.0 is the version you want...   In this case 2.5.2 was the last version before 3.0.

npm r nativescript-imagepicker to make sure to delete the 3.0 version that is in his node-modules folder.  Then we used tns plugin add nativescript-imagepicker@2.5.2 and we do a tns platform remove then tns platform <strong>a</strong>dd again to make sure nothing was left over from the prior failed attempts.

Of course, it wasn't as simple as that -- the developers of the imagepicker plugin has a really stupid issue that were causing building issues that I had to fix for him.  But that is a story for another day...  😉

But none the less it turned into a great teaching moment to improve his skill set on both CLI, NPM and NativeScript...  And so off he goes...  So proud, of this guy...  Can't wait to show off some of his stuff...

 

NativeScript: Android & Crashing issues

This is more of an informational post; there are a couple issues that I am aware of that will kill your application deader than a door nail.    As a community service I want to inform you on how to deal with them.

The first issue is fairly simple to duplicate; open your app in Android 7, and then open it in split screen mode.  At this moment there is a issue in the android runtimes that causes your app to crash and burn.   Assuming you do not want to see  your customers complain about application crashes, Nick came up with a good workaround until they can fix the issue.

To fix the issue you need to open your /app/App_Resources/Android/AndroidManifest.xml file and navigate to following key to the Activity section of the file.     It should look like this:

You want to add android:resizableActivity="false" to the Activity section as shown in this image.

This will disable the ability for the application to be resized; which will eliminate the crash.   The NativeScript team is investigating how to fix it; so eventually you won't need to do this; but in the meantime, I would recommend you add this to all your apps to eliminate at least one place your app can easily crash on Android 7.

 

The second issue is one that I have been dealing with for month; my remote error logging shows this log frequently:

Error (native) com.tns.NativeScriptException: No weak reference found. Attempt to use cleared object reference id=-xxxxxx

This of course crashes the application.    Well Peter (on the NativeScript Android team) has managed to duplicate and fix at least one of the ways this can occur.    So, we will be seeing this fix in the the new 3.0.0 runtimes.   WooHoo, less customer crashing is AWSOME news...

Now I know what a lot of you are thinking, I've got a NativeScript 2.5 application; I don't want to upgrade to 3.0 yet; it will break all my plugins...  Guess what this intrepid developer has tried and confirms works properly.   You can run the 2.5 TNS core modules and the 2.5 widgets with the Android 3.0.0 android runtimes.    This is not going to be guaranteed to work for any future releases past 3.0,  but for the first couple versions, you should be very safe running the Android 3.0 runtimes with 2.5 NS Core Modules and 2.5 NS Core Widgets.    One word of warning you MUST use 2.5 core-modules with the 2.5 widgets; DO NOT try to mix these up these versions.

Now 3.0 is not yet out of RC status; so I wouldn't deploy this right this minute.  But once 3.0 is out; I plan on updating my apps to use the 3.0 engine to eliminate this nasty issue that randomly crashes my applications...

To update you just do:

tns platform remove android
and then
tns platform add android@3.0.0

Please note; you will also want to disable the snapshot feature.  It is tied to the core modules and runtime engine.  At this moment there is no version of the snapshot for v2.5 core on a 3.0 android engine.   To disable the snapshot ability; the easiest way is to do:

npm remove --save-dev nativescript-dev-android-snapshot

This will remove all the snapshot code from your project so it won't run and mess anything up...

 

 

 

NativeScript 2.5.0 - Released

Some of you might have seen the all New version 2.5.0 has been released today.  For the first time that I can recall; Telerik has actually beat me to the release news.   You can read the official blog post here.

Some of the new features

  • Better Debugging using Chrome Developer tools
  • Working Webpack 2.0
  • Flexbox layout fixes
  • Updated Android Runtime Engine (even more ES6 support)
  • More css support for ActionBar
  • Lots of bug fixes

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
> tns update

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

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

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

Some Changes

  1. tns run does not work the same way anymore; it is now equal to tns livesync --watch
  2. To actually "rebuild" the app; use tns run android --clean

Common Issues:

  1. In some cases when doing a tns platfrom add android, the package.json file gets a entry in the dependencies section for "tns-android": "^2.5.0" which will cause any following builds to fail with the error code: the plugin tns-android is already installed.   Fix: Delete it out the package.json.
  2. ActionBar items -- backgroundColor do not use color names; only use Hex values.  Using color names can cause the app to crash.
  3. Android --release apps and error about can't find package "nativescript-snapshot@x.y.z" or "nativescript-angular-snapshot@x.y.z" in the registry.     A couple things can be causing this; first make sure you have updated everything.   Second, occasionally the hooks folder gets out of sync, you might have to delete your hooks & node_modules folder and do a npm i to reinstall everything.