Author Archives: Nathanael Anderson

Plugins.nativescript.rocks upgraded

Behind the scenes PNR (http://plugins.nativescript.rocks) has been upgraded to support several cool new features.

At this moment the largest difference is the backend data storage system has been completely changed; and now has a lot of new data available to it.    This system should allow us to do some more pretty cool things in the future...

By using this new data; I also have a bit more accurate plugin list,    In addition the new system has the ability to track both NativeScript 2.x plugins and separately 3.x.  So on the page you can now see a select list that allows you to change "All" (All plugins), "2.x" plugins that should be only 2.x compatible; and then finally only 3.x compatible.  In addition I took the time to actually drop a physical search bar in the title area; as my virtual search bar seemed to confuse a lot of people.

Play around with it, let me know if you run into any issues.

NativeScript 3.0 Released

Some of you might have seen the all New version 3.0.0 has been released today.  This is a major release.   Lots of things changed under the hood.

Some of the new features

  • Redesigned class system to increase the speed of your app.
  • Better Debugging using Chrome Developer tools
  • Lots of bugs fixed
  • New CSS features

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.0.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.0; so you will have to wait for the third party authors to get 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.0 or 2.0 plugins shortly.
  2. TypeScript incompatibilities; you should be using 2.2 or later with v3.0 of TNS

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 3.0 Sneak Peek and what it entails for Plugin developers.

For those who are not aware, v3.0 of NativeScript is the next major version that will be released.  It has been being worked on for several months now as it has parts of it have been completely rewritten to enhance speed of the framework in a number of areas.    Some parts of it have undergone radical changes in design, and as such will require changes to plugins to make them compatible.

Unfortunately these changes are a breaking change and will mess up the plugins for a while...

Some pre-release information has trickled out and as such the plugin developers needs to be made aware of these changes, so we can start getting a jump on these changes...

The biggest issue is any plugins that deals with any properties, or stylers has been completely changed.   These plugins will HAVE to be changed to support 3.0.   This means your plugin will no longer be NS <= 2.5 compatible, these are BREAKING changes.

 

Plugin Sites and the Package.json

As an aside if your plugin doesn't have any breaking changes and can continue to work fine in all versions of NS; then I am asking you to add a new flag to your package.json file to flag that this plugin is 3.0 compatible but doesn't require 3.0.

Your package JSON NativeScript section should look like this:

"nativescript": {
   "platforms": {
      "android": "2.3.0",
      "ios": "2.3.0"
    },
    "plugin": {
       "nan": "false",
       "core3": "true",
       "pan": "true",
       "wrapper": "ios",
       "category": "visual"
    }
 },

The additional "plugin" structure is being introduced  to try and capture the data that has been missing from the plugin infrastructure.  At this moment each item is totally optional.   However, this will allow the plugin sites to categories and filter the plugins based on criteria's that are important to subsets of the users using the plugin sites.  Please see: http://fluentreports.com/blog/?p=489 for more details on the new "plugin" structure proposal.

 

Back to the breaking Changes

The first resource is that some of the NativeScript team produced a video last week https://youtu.be/bwO3cYPb4zQ which will give a decent overview of the changes.

The developers working on the 3.0 project gave a run down of the changes and how they benefit us and/or what changes we need to be concerned about.

The second resource, which I find to be a bit more valuable is this document that is in the source repo.  https://github.com/nativescript/nativescript/blob/master/Modules30Changes.md

They used this document in the above video; but since they only covered an overview and this documents has all the nitty-gritty details.

For this to be a smooth transition I really strongly encourage you on the "core3" attribute be used if you are not just bumping your platforms to 3.0.0.      I will be automatically filtering out plugins that I believe are only 2.0 for 2.0 mode and 3.0 for 3.0 mode.  So  having things tagged correctly will help the end users have a much more painless transition.

 

NativeScript: Plugins - Let Fix the Data!

Some of you might not be aware but I wrote the plugins.nativescript.rocks.   I also helped write the plugins.nativescript.org site (if something doesn't work on plugins.nativescript.org; please blame my cohorts in crime, Nathan Walker and George Edwards.   I had NOTHING to do with any bugs!  😛  )

Well, with the new upcoming changes in 3.0 and some data that we have been unable to determine I have decided to request that the plugin authors add a little bit more metadata to the package.json file that comes with the plugin.

So lets look at the existing "nativescript" key.

"nativescript": {
   "platforms": {
      "android": "2.3.0",
      "ios": "2.3.0"
    }
 },

This tells nativescript which version of NativeScript runttimes are supported.   This allows the TNS command line to throw and error/warning if you are not using the proper versions.   This is useful information as this tells us what platforms are supported.   However, this fails when people (like me) write dummy wrappers to support the plugin not crashing on the other platform.     On the plugins site it will say this plugin supports both Android and iOS, but in all reality the plugin only really supports iOS, and actually doesn't really do anything on Android.    I would like to have the plugins site actually reflect this reality rather than you downloading a plugin you thing works on Android and it turns out it doesn't.

In addition since Angular was introduced to the eco-system, there are a large number of plugins that actually do NOT work with NAN (NativeScript Angular) code.   And even some that don't work with PAN (Plain Awesome NativeScript) code.  In addition in the future we might get other frameworks supported like VueJS (VAN?), etc.

So I would like to start capturing the data so that we can do these additional cool things.   And so I am proposing the following additional OPTIONAL meta data to be added.

"nativescript": {
   "platforms": {
      "android": "2.3.0",
      "ios": "2.3.0"
    },
    "plugin": {
       "nan": "false",
       "pan": "true",
       "core3": "true",
       "wrapper": "ios",
       "category": "visual"
    }
 },

nan = NativeScript ANgular will be assumed to be false, unless Angular is detected in the Keywords/name/description.
pan = Plain Awesome NativeScript Will be assumed to be true.
core3 = Supports NS Core Modules 3. Will be assumed FALSE if platforms.ios/.android < 3
Will be assumed TRUE if platforms.ios/andorid >= 3.
wrapper = Using a dummy wrapper Will default to false, use "ios" or "android" to signify platform which is using a wrapper.
category This is the category to put the plugin in.   Valid categories currently are: "Interface", "Processing", "Templates", "Developer", "Utilities"

I am up for other category suggestions.   But at this point these are the primary categories that I use on plugins.nativescript.rocks.

Please note each key is optional; however, your plugin will get extra points for having an category key.  And you will LOSE points if we detect a plugin is using a wrapper and you haven't tagged it, as this is a issue the plugin users really hate seeing faulty data about the plugins support.

I would recommend plugin authors start adding this to any releases of there plugins so that we can capture the data.  This will become critical with the 3.0 release as a large chunk of plugins are not going to be compatible between NS 2 & NS 3.

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.

 

NativeScript Android Snapshots

For those who haven't deployed any apps in v2.4 of NativeScript; one of the new features that is turned on by default is SnapShots.    Now most the time this is a AWESOME thing, however occasionally this can cause issues.   For example I have one app of mine that this crashes at startup when using SnapShots.

Now the docs do list how to disable snapshots; but it is a lot easier for me to find the notes on my own site than trying to figure out which doc has the info.

The environmental variable you need to adjust is: <strong>TNS_ANDROID_SNAPSHOT</strong>

  • 0 = Force Snapshots off always
  • 1 = Force snapshots on (including in debug mode)
  • Unset = Snapshots only in Release mode

Allowing TypeScript to understand NativeScripts ~/ home path

I know a wide number of you use TypeScript; well one of the irritations I've had with TypeScript -- I just figured out how to solve.   Finally did some research and tests to figure out how to make TypeScript support using ~/ as a normal path for building and determining editor intellisense since this is a special path in NativeScript meaning the home app path.   Using this path in a import / require statement means you can do something like this.

/app/views/login/login.ts ->

import * as animation from '~/support/animation'
and it will load in the file at   /app/support/animation

You can use relative paths, but I find absolute path's a lot easier to read and understand exactly which file is being loaded.   In addition things like my NativeScript-Updater can't use relative path's (do to some low level issues in the iOS runtimes) and determine if a file has been updated.

Ok, so the solution: open your tsconfig.json file and add the following:

"baseUrl": ".",
"paths": {
   "~/*": [
     "./*"
   ]
  }

To the "compilerOptions" key in the json file.

Amazon Tablets - Jailbreaking / Rooting

Amazon sales some decent little tablets called the Amazon Fire 7", add one of there decent kids cases and the tablet is great for letting the kids use for a ereader, comics, games, notes, Zork, and many other tasks that a normal Android compatible touch screen devices can do. All for the grand total of $50 for the android device, and $20 for the case.   So around $70 you have unit that is perfect for kids.

Now with this unit there is a couple of small gotcha; by default it comes with a silly advertising screen saver and it is tied completely to the Amazon eco-system.   For those who aren't interested in Advertising there is two options; one you can pay Amazon $15 to eliminate the advertising, or you can remove it yourself.   Now many of you know me; So I'm sure you can guess which way I did it. 🙂

The second issue is that it only has a 3 month warranty; they DO sell a "kids" version for $99 that comes with the case, removal of the ads and a two year warranty.   So the cost difference between the two is negligible if you want a two year warranty, this is your better bet and you don't have to do anything to eliminate the ads as it comes already without ads.

This device is not a bad little tablet; and my kids fight sometimes over who gets which one of the them that we have.


Now on to why most of you are probably viewing this blog post; I prefer to have full control over any device that enters my house.   So guess what my choice was.  Yep, I eliminated the ads and "root"ed the device.   If that sounds scary; it really isn't.   You just do a couple steps; install some software and boom your done and have a fully open Android tablet.  Please note this can void your warranty and you have a chance you can mess up your device.   No warranty is provided and I don't provide free tech support.  😉 Please note this only works on Amazon Kindle fire 5.3.1 and lower, if you are running 5.3.2; you need to downgrade to 5.3.1 before doing this. There are videos to help you do this.

Please note; by doing this you might eliminate the ability for Amazon's Alexa, freeplace, prime videos, kindle free books from working.   I do have a prime account; but I don't have anything on Amazon I want the kids to have "easy" access too; so I honestly haven't tried any of the prime services on my fire's.   I'm pretty sure the Kindle e-reader app continues to work fine; but no guarantees.    I don't believe my fire's are babysitters, so no video access is given to them.  If they want to be entertained they can read a book.  😉

First things first; you need the tools.  You need to download the link on here:

http://rootjunkysdl.com/files/?dir=Amazon%20Fire%205th%20gen/SuperTool

The file is currently called AmazonFire5thGenSuperTool.zip and it is around 152MB's

After you download it and extract it to a folder; you need to install the ADB drivers; the best tutorial I've seen if you like video's is the author of this tool; "Root Junky" video tutorials which you can watch on http://www.rootjunky.com/amazon-fire-5th-gen-supertool/

If you prefer text and pictures http://www.makeuseof.com/tag/install-google-play-remove-lockscreen-ads-amazon-fire-tablet-without-root/

Now I'm not going to repeat those tutorials; The things I did to make everything work was option 1. ADB Driver Install, then 2. Install Google Play and remove ads from Lock Screen, then 7. Root your Amazon Fire fifth gen, and finally 8. Replace Amazon Fire Launcher with Nova Laucher.
1. ADB Driver Install -- This is required so that the software on your computer can talk to the Amazon Fire, so this has to be done FIRST, and must be working, for everything else to work.  This can be tricky depending on the OS; if you are using Windows 8 or 10; you have to disable driver signing; which you can see how to do in the Text and pictures link.

2. Install Google Play / Remove ads -- well I don't like ads, and I want Google play to be able to install other things, that I mention below.

7. Root your amazon fire; this is if you want to be able to control things; I happen to like putting a firewall on my devices.  This allows me to block all applications from connecting to the internet and dialing home and/or pulling down ads inside of them.    This is not needed; but I personally prefer it.  The firewall I use is called "AFWall+" and can be got for free on the Google Play store. (But you must be rooted to use it).   There are a couple other tools I use on my devices that require root; but I'm a developer so they probably won't interest you.  😉

8. Replace the Amazon Fire launcher with Nova Launcher.  Nova Launcher is a pretty good default launcher; if you like the Amazon launcher; then no need to do this.  But I don't and I find it very limiting and it is very much tied to the Amazon eco-system.  So I install Nova Launcher; then I installed another app called "Kids Place" this allows you to setup a simple to use Launcher for the kids; where I can pick the apps they can run, when they are allowed to be ran and other "kid" friendly items. This "Kids" place runs in its own sandbox and limits the kids to pretty much only the apps you allow it. It has some "holes" that my crafty kids have discovered, but the holes are pretty minor and don't cause any real issues since the firewall blocks access from any app that I've decided doesn't need internet access.

I tend to disable the internet on the tablet, pre-install a ton of books, apps, comics and other items. I have also purchased a License for Moon Reader (My favorite e-reader app), and Aldiko Premium. And so I install these along with FBReader on all my Fire's so that the kids can choose which e-reader they like.  In addition I typically install a couple learning games (for the non-readers), drawing, and even a comic book reader; as everyone loves comics.

If you want to allow your kids access to the internet from the device; I would install the Brave browser as it has built in ability to eliminate ads and tracking which is what you want for your kids. The other thing you might consider is changing the DNS to use a family/kid friendly provider. You can do it on the device; or if you have a smart router; you can tell your router to server a kid friendly dns to a specific device. OpenDNS & Norton both provide free kid friendly dns servers.

None of this is totally bulletproof and you still have to be a parent; but it does make my life a lot easier and I have no concerns about any of the kids taking any of the fires in their rooms and using them.

 

MySQL SSL required connection Ubuntu solutions

I went to implement MySQL replication for a client this evening and ran into some interesting issues that I haven't ran into before. Guess it has been a while since I had to set it up from a client.   So this post is for notes for me or someone else who might need to do this in the future. The normal installation replication installation works great but if you are going to enable ssl connections this is where the things can get a bit more complex.

The first thing to find out is if you have your SSL setup correct, try doing:
And verify the SSL is enabled and build in, in my case everything looked good:

mysql> SHOW VARIABLES LIKE '%ssl%';

have_openssl  = YES
have_ssl      = YES
ssl_ca        = /etc/mysql/certs/ca-cert.pem
ssl_capath    =
ssl_cert      = /etc/mysql/certs/server-cert.pem
ssl_cipher    =
ssl_crl       =
ssl_crlpath   =
ssl_key       = /etc/mysql/certs/server-key.pem\";

This looks correct, so the next thing to figure out is where the error log file is located;
mysql> SHOW VARIABLES LIKE '%error_log%';

log_error     =  ./mysql-bin.err
or something like
log_error     = /var/log/mysql/error.log

Now that you know where the error log is at you can see why it is failing.

In my case the error was this:

2016-12-06 23:21:33 32695 [Warning] Failed to setup SSL
2016-12-06 23:21:33 32695 [Warning] SSL error: SSL_CTX_set_default_verify_paths failed

I love that it is a "Warning".   It is totally broken, but we will list it as a Warning...

Well, this can be caused by several things:

  1. No permissions to the files in the folder, use chmod/chown to give perms.
  2. SELinux blocking it, disable selinux or grant permissions via SELinux
  3. AppArmor blocking it.  (this was my case)

Edit the /etc/apparmor.d/usr.sbin.mysqld file.

You'll see something like this in the file:

/etc/mysql/*.pem r,
/etc/mysql/conf.d/ r,
/etc/mysql/conf.d/* r,
/etc/mysql/*.cnf r,
---> /etc/mysql/certs/*.pem r,  <---
/usr/lib/mysql/plugin/ r,

Add the ---> line <---, make sure it matches your path to where you are storing the certs.  Then restart mysql. After restarting the server, I then got this error: SSL error: Unable to get private key from '/etc/mysql/certs/server-key.pem' 2016-12-06 23:53:32 21728 [Warning] Failed to setup SSL 2016-12-06 23:53:32 21728 [Warning] SSL error: Unable to get private key Ok, this one threw me for a while.  The files are fully readable by MySQL.  The issue ends up being incompatibilities between SSL libraries in use.  OpenSSL 1.0x vs yaSSL The key file will start like this:
-----BEGIN PRIVATE KEY-----
If you used OpenSSL to generate the keys;  OpenSSL creates keys in PKCS#8 with a SHA256 digest.  Of course yaSSL which is (normally) used by MySQL doesn't support either, and want PKCS#1.  So despite having the files fully readable, MySQL is telling you it can't figure out how to "get the private key" out of the file.  Once you know the issue, it has a simple solution:
openssl rsa -in server-key.pem -out server-key.pem
when you are done with this command the beginning of the file should look like this:
-----BEGIN RSA PRIVATE KEY-----
Again, the internal format is different, so don't try and just change the text and insert the "RSA" into it -- it will look like it works until something try's to connect using SSL. Once you have this done, restart mysql again and you should be good to go.