Category Archives: JavaScript

NativeScript/JavaScript Tip: Debugging

Once thing I was made aware of today was that not everyone knows the magic "debugger;" command.   I suppose this makes sense; I rarely see it mentioned, but it is a very useful debugging command in the JavaScript world.

The "debugger;" command is used to cause the application to stop and enter the debugger at that point.   This works in Node.js, the browsers, and even in NativeScript!    In a browser the developer tools must be open; if your debugger tools are closed; it will ignore it.     In node, a debugger must already be attached or it will also ignore it.

In NativeScript it will actually halt the program and WAIT until a debugger is attached!   So don't release your code

So pretend my code in main-page.js is

function pageLoaded(args) {
var page = args.object;
debugger;
// do something with the page object.
}

You can then start the application on the device; and it will automatically stop right at that debugger; statement.   Then at the command line type: tns run android --start and you will be in the debugger right at that line.

NativeScript: Keeping your AndroidManifest.xml easily editable and under version control.

So here I was again minding my own business on the forums again, and Ben posted he had been attempting to use this new feature of v1.5.x of NativeScript and it was failing.  I responded it didn't work like that.   Thankfully he was persistent and ignored my wrong response, and linked to the github issue a second time where they discuss the new feature.   Him, being persistent despite me telling him it doesn't work that way; is why we now have a way to make it work!   So thank you Ben!

So I went and looked at the new feature and found that by default it doesn't work as a normal person would expect.    It does exactly what I expected and why I said it doesn't work.    However, I decided to see if I could make it work the way any sane person would want it to and guess what, I have a method to make this work perfectly.

To make this work properly;  you need NativeScript v1.5.1 or later; so type tns --version and make sure you are running v1.5.1 and later, if not upgrade.

WARNING: changing things in your platforms folder can completely break your build; and if you totally break your build you can do a tns platform remove android and then a tns platform add android to reset it.

First, you will need to navigate to your /platforms/android/src/main and copy the AndroidManifest.xml file to your /app/App_Resources/Android/ folder.   This is going to be your primary manifest and the one you will edit to your hearts desire.  Make sure you COPY just your app manifest.

Next you will need to edit the /platforms/android/src/main/AndroidManifest.xml and basically deleted everything in it.   This file should end up looking like this:

<?xml version="1.0" encoding="utf-8"?>
<manifest  xmlns:android="http://schemas.android.com/apk/res/android"
package="YOUR_APP_PACKAGE" >
</manifest>

Do not copy the above as is; you need to make sure the "package" property contains your app package name, which is why I recommend you edit the one in their as it already has your app package in it.  If you copy the example above, it has YOUR_APP_PACKAGE which is an invalid package name.

Because the manifests are merged; and since the package name doesn't change the merging system is able to merge everything in your brand new App_Resources/Android/AndroidManifest.xml into the original AndroidManifest.xml file without any conflicts!

 

 

Getting Started with NativeScript - On Sale Now!

Getting Started with NativeScript

Getting Started with NativeScript

WooHoo!   It has been such a long road to get this book published.   I wrote a bit about it here.  It is finally  officially available on the Packt site for sale today!   It should be available on the Amazon store by Monday the 1st of February.  I will have a list of additional sites and urls later this week.  If you want the best book on NativeScript (I know I'm so funny!  I get to claim it because its the only book on NativeScript!) then it is now available!

The available sites are as follows:

 

 

 

Upgrading to NativeScript v1.5

I figured I would add a post for this; since I've done one on most the other version. v1.4 & v1.5 are the most seamless upgrades so far. Kudos to the Telerik teams involved in this. You can now upgrade in like four simple steps.

1. npm install -g nativescript
Ouch, that hurt, that was so dang difficult. Oh, wait no that must have been my last dentist visit. That was pretty darn seamless; and look if you now look at your nativescript --version you should have a nice v1.5.0 show up.

2. npm install tns-core-modules@latest --save
What, that is it to install all the new core modules; holy smokes Batman, it can't be that easy!

3. tns platform remove android AND/OR tns platform remove ios
Please note before you run the above commands if you have made ANY changes to the xcode project or the Android manifest; you might want to back them up first, or you will have to manually make those changes again.

4. tns platform add android AND/OR tns platform add ios
do a type package.json or cat package.json and you should see everything say "1.5.0"

Again a big Kudos for the teams involved in making the updated from v1.3 onward so seamless; if you look at my prior upgrade posts you can see how much EASIER it is to upgrade now.

If you want to run from masters, by them simplifying this process the process to install the masters from http://nativescript.rocks is also just as simple.

Upgrading to NativeScript v1.3 from earlier versions.

To update you need to upgrade a couple items, recommended that you do it in order.   Also, a word of caution once you upgrade your NativeScript CLI, you need to upgrade your platform and common modules for any of your other projects.   It is supposed to be backwards compatible; but I was not successful in getting the new version of TNS CLI to compile an older project properly.  Rather than spend any amount of time trying to get it to work, it was simpler just to upgrade the platform and common core modules...

Make sure you are NOT running Node v4.00; The current v4.00 version of Node does NOT work.   If you need to downgrade node, I recommend you grab the latest version of Node v0.12.x from https://nodejs.org/download/release/latest-v0.12.x/.   If you are already running node and it is working for you; you don't need to upgrade it.  This note is just to make sure you DON'T upgrade node to v4.00.

Next thing if you are doing anything with Android; you want to do is type "gradle --version" and see if it runs.  If it doesn't run from the command line you need to either install gradle or set your path to use it.   If you have Android Studio installed; gradle is including with Android Studio, so you don't have to install it again.  For example on my Windows machine; my gradle is located at: C:\Program Files (x86)\Android\android-studio\gradle\gradle-2.4\bin.   So I added that to my path, so now gradle can run from anywhere.  If you are using Ubuntu, the version included is really old and you will need to install a ppa from: https://launchpad.net/~cwchien/+archive/ubuntu/gradle Then you will be able to do a sudo apt-get update && sudo apt-get install gradle and get a much more recent version.   On a Macintosh, it is recommended you install brew, and then do a brew install gradle.   You can alternatively download and install it directly from https://gradle.org/.   You must be running at least v2.3 of Gradle.

Edit 2015/09/17: The new version of the build system uses gradle and the gradle configuration file REQURIES that you are running v22.0.1 of the Android Build tools. In the grunt based build system you could use v21 or v23.0.1. Since this has caught a few people; you will want to open up the Android SDK installer, and make sure to install Build Tools v22.0.1

The next thing you need to make sure is that you have your ANDROID_HOME and JAVA_HOME environmental variables set.   If you don't have them set you will get error messages about these needing to be set.  On Windows you can do echo %ANDROID_HOME%  %JAVA_HOME% to see if they are set.  On Macintosh and Linux you can do echo $ANDROID_HOME $JAVA_HOME to see them.

So, now that you have your environment all setup; we need to upgrade the NativeScript Command Line utility, first.  This is very important, before you even attempt to upgrade the platform modules you MUST be running the new version of the NativeScript CLI.

The easiest way is to do a: npm remove nativescript -g   Yes, we want to de-install the current version; trust me it is easier this way.  You can do a in-place update; but the times I tried it it threw errors; and I had to do it a couple times to get it installed.   So, it is much easier just to de-install it. Then you just type:  npm install nativescript  -g to re-install it.

If everything worked fine; you should be able to do: tns --version and you will see v1.3.0

The next piece you need to do is upgrade your platform.  Before you upgrade; you will want to make sure you backup any changes you made in the platform folder as both methods can overwrite the project files.  You can do it one of two ways; my way or the simpler way.   Telerik recommends the simpler way; you do a tns platform update android or tns platform update ios.    In most cases this works great.   However, in some of the past updates it has left you with a broken platform and then you still had to do it my way to fix it.    So rather than have the chance that you will get a broken platform, I of course will recommend my way.

My way is the nuclear option!  tns platform remove android and then tns platform add android.   I remove and then re-add back the platform.   Now, this will totally DELETE your platform/android or platform/ios folders.  So if you made any customization to your project files; I'm going to re-stress this -- you will want to back them up first.

The final piece is updating the common core tns-core-modules; in past versions of nativescript this was a bit of a pain to upgrade.  No more, it is now very simple!   The first thing you can do is just totally delete your app/tns_modules folder.  It is not used any more, totally ignored and now a waste of disk space.   Then you just type npm install tns-core-modules --save from inside your root project folder.    This will install the core modules in the node_modules folder like any other nativescript plugin.  So now in the future you can do a simple npm update tns-core-modules and have the latest version.

And finally after everything is all done; you can do a:
tns prepare android
and/or
tns prepare ios

And you should see it confirm everything is good to go...   Happy hacking on your NativeScript application.

Adding External Resource Security

lock-143616_1280In a lot of larger web sites it is pretty common that you use several third party resources like JavaScript.   However, this is a potential malicious door into your customers computer via your website.   What happens if the third party resource is changed by someone who does not have your best interests at heart.  Your page will still happily load the malware right onto your customers browsers.    So what can you do about this?

Well I'm glad you asked.   In the just released Chrome 45 (and soon in an upcoming Firefox release), they have added a awesome new feature to protect your customers (and your reputation).   When you link to any resources in your web page; you can now use the integrity attribute to tell the browser that this file must match this hash to load and use this file.

So <script ... integrity="sha256-some_sha256_hash"> or <link... integrity="sha384-some_sha384_hash">

The browser integrity attribute must support the sha 256, 384 and 512 hashes according to the w3 spec. For browsers that don't support this yet; then this won't do anything and the resources will load fine just like normal.  But in browsers that do support this; when the browser downloads the resource it will hash it and verify the hash matches before allowing it to be used.

On Linux you can generate the hash by doing:
cat the_file_resource | openssl dgst -sha256 -binary | openssl enc -base64 -A

On Windows if you have openssl installed you can do:
type the_file_resource | openssl dgst -sha256 -binary | openssl enc -base64 -A

Or if you don't have openssl installed; you can also easily cheat by using Chrome.   Just add the integrity with a bogus value; then reload the page.   Chrome in the developer log will show you the computed hash for the file when it blocks it.

For the full W3 Spec: https://w3c.github.io/webappsec/specs/subresourceintegrity/

fluentReports gets an actual web site.

Hey,  I finally got a few spare minutes and spent those few minutes building a quick and simple web site for fluentReports.   However, I couldn't just do something totally "static" -- I had to do at least one page that was awesome.

The fluentReports web site now has a fully working demo page (with 3 of the sample reports pre-programmed in) that runs fully in your browser.    You can make any changes you want in the editor and it will attempt to run your changes and generate a new report if possible.

I had suspected the fluentReports would run fine in a browser; but I can now totally confirm that it is possible, with no modifications needed.   You just need to use browserify,

Check out the main site and let me know what you think...  http://fluentReports.com

Announcing NativeScript-WebSockets!

WooHoo, I have finally released it; http://github.com/NathanaelA/NativeScript-Websockets. I only have been discussing it for almost a month.   I had it working on Android almost a month ago; and then on iOS shortly afterwords.    However, doing documentation; making a easy to use consistent interface, building install routines.   And then fixing BUGS.  Ouch, tracing bugs in NativeScript, iOS and Android and in the two third party libraries I used, was not exactly fun.    But I am very happy with the state of the library now.  The library not only support Text messages; but fully supports binary messages also!

You should be able to do a tns plugin add nativescript-websockets to install it on both iOS and Android.   iOS as usual has a few items you have to do afterwords to the xcode project.  And hopefully by the time you read this post; Telerik will have released v1.2.2 of the iOS runtimes.  They have already tagged the v1.2.2 a couple days ago; so I assume they are running tests.   But until you have the v1.2.2 iOS runtimes you will need to use the workaround I put in as the first issue on the nativescript-websockets repo.

The NativeScript-WebSockets supports TWO interfaces; I'm particularly proud of this feature -- you can do var ws = new WebSocket(url, protocol); just like you would do on a browser and all the functions and events are present so this as far as I can tell fully emulates the web socket on your browser.     The second interface is much more advanced and allows re-connecting on a dead socket and timeout support.    See the documentation for more details on both interfaces.

I would like to thank Nathan Rajlich for his Java_WebSocket library which is what I used as the base of the Android version: https://github.com/TooTallNate/Java-WebSocket

And thank Robert Payne (of Zwopple) for his PocketSocket library which is what I used as the base on the iOS version: https://github.com/zwopple/PocketSocket

 

NativeScript v1.2.0 Built in LiveSync vs the NativeScript-LiveSync Plugin

Pros of Telerik's LiveSync:

  • Works from the NativeScript Command Line
  • No extra code added to your application!
  • Possibly works on Real IOS Devices (Untested on real device, but does not currently appear to work on a IOS Simulator)

Cons of Telerik's LiveSync:

  • Not really Live. It syncs the files; but then has to restart the application from scratch, no matter what file is changed.
  • Delays while it detects any changes and then deploys the changes.
  • Delays while it is re-launching Application.
  • Loss of all application state since it reloads the app on every change.
  • If you navigated three screens deep, and make a CSS file change; you will need to re-navigate to that screen again to see it.
  • Incredibly slow LiveSync startup time. (What in the world is it doing for about a minute?)
  • Can crash the LiveSync watcher code easily (don't change any files in the tns_modules!).
  • Does not apparently detect any new files...
  • Reset of the Application even if you change a file that isn't even being used.
  • Easy to crash your application as the JavaScript and XML are not checked before being sent to the application.

Con's of Master Technology's LiveSync:

  • Until Telerik accepts the patch; you have to use the included patched runtime. (Please vote up the issue!)
  • Added coded to your project.
  • Only works on the Android platform, no IOS support.

Pro's of Master Technology's LiveSync:

  • Live, You see the app change almost exactly when your editor saves the files.
  • New files are detected and synced instantly.
  • Application state is almost always fully maintained.
  • The screen you are working on only reloads ONLY if it is the code you just changed.
  • Built in ability to detect errors in XML and JS before pushing to device to eliminate crashing the app on the device.
  • Ability to only reload application on files that are singletons or other files that you would rather have the app reloaded for.
  • Ability to restart application by touching or creating a "restart.livesync" file.

 

The new LiveSync code has been updated to be a seemless installation on your Box.    It now includes the modified runtimes for v1.20 of the Android runtimes.     All you have to do to install it is: tns plugin add nativescript-livesync

 

 

NativeScript v1.20 Released

We all need to start upgrading,  Telerik has released v1.2.0 -- this is a important upgrade as it fixes several nasty bugs on IOS & Android!    It also adds a lot of cool new features.

1. To upgrade the command line: npm install nativescript -g

(On a mac or linux you might need a "sudo" in front)

2. To Upgrade the platforms: tns platform upgrade ios  or tns platform upgrade android

3. To upgrade the common modules; well that is still a pain.  I would advice you to follow the same instructions I had you follow in the v1.0.0 to v1.1.0 upgrade, however if you have manually added anything to your "tns_modules" (which I would not recommend you do, you will want to copy or re-install it in your new tns_modules)

cd ..
tns create testupgrade
rd /S /Q <strong>YOURAPP</strong>\app\tns_modules
move testupgrade\app\tns_modules <strong>yourapp</strong>\app
rd /S /Q testupgrade

 

First things first, NativeScript command line plugin code works a lot better.    You can now do:

tns plugin add android <somepluginname> and it works!

For those interested; my LiveSync plugin has already been updated for v1.2 with a slew of new features and a very simple install using the new tns plugin add android nativescript-livesync command.

Lots of new Features and here are some of the changes:

New Features

 

Fixed