Author Archives: Nathanael Anderson

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.1.0 Released

For those who upgraded to 5.0.0 last month, it was a bit of a rough ride.  A lot of cool features but a lot of weird corner case broken items.  Fortunately since that point, they have released a several 5.0.x point releases which fixed several of the larger flaws.  5.1.0 actually fixes several of the non-critical smaller flaws and adds some cool new features...   So if you were waiting to jump on the 5.x bandwagon, this should be the stable release you are waiting for!

The quick list of some of the new features in 5.1

Core Modules

Enable modal dialog chaining in IOS - this allows you to have another dialog follow the first; anyone who has tried this in the past; know this was always a pain on iOS.

isScrollEnabled - This allows you to disable scrolling in the scrollbar component.

androidSwipeEnabled - Allows you to disable swiping in the Android tabview control.

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

Android

Android AAB (Android App Bundle); support added!

New package.json flag;  suppressCallJSMethodExceptions: true/false - enables suppression of the boolean errors when calling a native function.  This could happen and crash the app.  Now you can suppress them.  (see http://fluentreports.com/blog/?p=581 for more information) 

Java 8 Static method support on interfaces; allows NativeScript to call these Static functions.

extends should now work against standard javascript classes (i.e. non native Android classes); so that you can now do class MyVue extends Vue {}; class blahComp extends MyView {}; and it will work properly.

iOS

CStrings are a bit more resilient when passing to a function that wants them as a pointer to read and possibly write.

Updated JavaScript engine to JSC 12.0

CLI

Several bugs when using hmr are fixed.

Yarn Support

Adding lots more Analytics/Tracking (Don't forget to disable this for your privacy: tns usage-reporting disable && tns error-reporting disable)


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

The "tns preview" Feature

The all new "tns preview" feature in NativeScript 5.0 is very useful for testing small local projects and/or for new developers who want to try out NativeScript without installing all the build tools.    

However, the preview app has some limitations, some of them can be worked around.   The first is that you must have working internet as the link between the CLI to the preview app on the device is via cloud servers.   Your app is transmitted via the internet to your device; and the device creates another channel that is transmitted back to the CLI the console so you can see any errors that occurred. 

If your company has an issue with your app source code being transmitted out to the cloud; then make sure you don't use this feature. 

The second limitation is that only the plugins that come with the preview app can currently be used.   These are the only compiled plugins you can use:

Now, this is a decent list; but we currently have over 800 plugins available to NativeScript.    A number of these additional plugins can be used in the preview app.    There is two ways to work around the built in limitations of the Preview app.  However, only if the plugin is 100% pure javascript source (*).    If the plugin has no compiled code; then you can work around it easily by doing the following:

  1. npm i --save-dev nativescript-dev-webpack
  2. tns plugin add <plugin_name>
  3. tns preview --bundle

By using the --bundle command, it will use webpack to webpack your source code and then those 100% pure JS plugins will be transmitted to the app in one of the two bundles.  

The second way (if you don't want to use webpack, or webpack is breaking something) is to basically install the plugins into a different folder that will be synced via the preview function.

  1. Change to your "app/" directory (main directory that contains the app.js/app.ts file)
  2. npm i <plugin_name> --save
  3. In your source code do 'var X = require("~/node_modules/plugin_name");'     (or you can use the import statement, you still have to use "~/node_modules/" to allow the javascript engine to be able to figure out where the plugin actually resides, since it isn't in the normal location.

Again this technique will ONLY allow any 100% JavaScript plugins(*) to be used in NativeScript, anything that has a cocoapod, gradle, or jar/aar file won't work.    Everything inside the "app" directory is synced to the device, so these 100% JavaScript plugins will also be synced and then be usable.

(*) - It is possible that a 100% JS plugin won't work on Android.  Any plugins that actually requires the SBG (Static Binding Generator) to generate compiled Java code from the JS code can't work; as the Preview app has no ability to use any additional compiled code.

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

NativeScript 4.2 Released

The new version of NativeScript just dropped today!   As usual the update is worth getting for several features that are shipping in it.

Major Features

  • LiveSync now uses Sockets on Android
  • iOS and Android now support the `discardUncaughtJsExceptions` flags.
  • Simpler Templates (less NPM dependencies)
  • Android now support HTTP Gzip'd packets
  • Debugging Webpacked apps

Minor Features and/ Bug Fixes

  • Android v8 engine upgraded to 6.7.288
  • Android app no longer crashes when closing debugger.
  • Multiple CLI building issues resolved, including LiveSync on modern Android; Gradle issues with Google plugings.
  • Android P support
  • iOS XCode 10 support
  • Several LiveSync fixes
  • Lots of build issues fixed

Known new Issues

  • None so far

NativeScript application wide runtime settings (updated 5.1)

NativeScript SwitchOn thing most people are probably not aware of is that the Android runtimes has a large number of knobs and switches to customize certain behavior of the engine.   I will try and list out all the current switches and knobs that you can use.   iOS now has one switch.

First of all the settings go into the /app/package.json   If you open up the default package json you probably will see:

{
   "android": {
      "v8Flags": "--expose_gc"
   },
   "main": "app.js",
   "name": "tns-template-hello-world",
   "version": "4.1.0"
}

That "android" key is where everything goes for Android specific settings.   The default setting that comes in the files is "v8Flags": "--expose_gc" this one is rather critical in that this enabled the runtime to call gc from JavaScript.   Now, there is quite a few v8Flags you can use; most the time they aren't needed but if you need to tune the v8 engine; you can add more flags into this string.  I even list a few in this post.   Let me warn you again; DO NOT remove the "--expose_gc".   You will cause your app to crash when something attempts to call the GC from code.

Ok, so the complete list of settings you can change in the Android section:

Setting Default Min Version Description
gcThrottleTime 0 3.x Allows you to throttle how frequently JS GC triggers native GC
See: Memory Management
memoryCheckInterval 0 3.x How frequently to check memory usage
See: Memory Management
freeMemoryRatio 0.0 3.x Ration of memory before a GC is ran (works with memoryCheckInterval)
See: Memory Management
markingMode full 3.x Switches which type of GC engine to use.  "none" will enable a different engine which doesn't do marking.  Typically faster for Angular apps
handleTimeZoneChanges false 4.1 True will enable the ability for a time zone change in the settings to effect the NS app.
maxLogcatObjectSize 1024 4.0 How many lines of text a console output will log.
forceLog false 4.0 True will enable logging in release mode
suppressCallJSMethodException false 5.1 True will suppress the boolean type conversion error from null that could randomly occur and crash the application.
codeCache false 2.x True - Enables code caching in the v8 engine.
v8Flags --expose_gc 1.x Tunes the v8 engine
heapSnapshotBlob "" 2.x (Believe to be unused now)
heapSnapshotScript "" 2.x (Believe to be unused now)
snapshot.blob "" 2.x (Believe to be unused now)
profilerOutputDirKey "" 2.x (Believe to be unused now)
profiling "" 2.x (Believe to be unused now)

IOS Level Flags:  (None Currently)

Top Level Global Flags:

Setting Default Min Version Description
discardUncaughtJsExceptions false 4.2 True - will disable crashing on JS errors, will log any issues to console.

Recommended changes:
discardUncaughtJsExceptions: "true" - This will keep the app from crashing on certain types of errors; this should be enabled for release mode! Some developers might find it more productive to have this enabled while coding to eliminate application crashes. Please note you MUST pay attention to the console if you enable this during development; because most JS errors that would crash out; will now be just logged to the console.

suppressCallJSMethodExceptions: "true" - This will keep the app from crashing on the boolean conversion issue that can occasionally occur.  This is not to say the app might have some other issue later; but this will eliminate a stupid (imho) crash reason.

markingMode: "none" - This will enable the experimental GC engine, this will help incredibly with Angular based apps. Please note it "might" cause more crashing errors if a plugin forgot to hold a reference to something it needed later. However with the above discardUncaughtJsExceptions enabled; those errors won't crash the app.

Late Breaking news; in 4.2 they actually moved "discardUncaughtJsExceptions" to the top level of the package; the reason why is because shortly after they added the support to Android; the support was added to iOS.  So now this flag controls both iOS and Android, so it no longer belongs just in the "android" block.

So in your package json would look like this if you used my recommended settings:

{
   "android": {
      "v8Flags": "--expose_gc",
      "markingMode": "none",<br />      "suppressCallKSMethodExceptions": "true"
   },
   "discardUncaughtJsExceptions": "true", 
   "main": "app.js",
   "name": "tns-template-hello-world",
   "version": "5.1.0"
}

NativeScript 4.1.0 Released

I took a bit of a break from reporting on NativeScript things; but guess what, I'm BACK!!!

Well, looks like I was on the ball again this time.   😉    4.1.0 has been released to NPM, and it is HOT!

Version 4.0 was a great release and all; had a lot of cool changes.   But 4.1 is an awesome release building upon that great release and if you haven't upgrade to the NativeScript 4 yet; this is what you have been waiting for!   Thank you Progress.

First of all the item that we have been all waiting for if you do any Android development; they have updated the Android V8 engine to pretty much the latest stable released version.  So we jumped from v8 v5.5 to v6.6.   Now that might not seem like a large change but the number of changes in the v8 engine from v5 to v6 are incredibly large.   We now have the brand new JavaScript optimizing engine (Turbo Fan); the new optimized Garbage Collection engine, pretty much full ES6 support ; and so many other countless optimized features -- I could dedicate a post to all the cool things we now have access to in Android.   In a nutshell this v8 is now considerably faster.  In fact one of the tweets you might have seen is how much faster this version even starts the application.     Always awesome for our customers to have the app startup now almost twice as fast.   For all you iOS fans; v4.0.0 of NativeScript upgraded the JavaScript core to pretty close to the latest, so now both sides are running the state of the art JavaScript engines..

In addition to that awesome change that is totally worth the upgrade by itself - we can now use Angular 6 and Webpack 4!   I'm sure many of you will be very happy to see these.

Now that I'm done drooling over all this new found speed and these two other awesome feature updates; lets run down some of the other new features and fixes that you get for free when you upgrade:

  • Android: "in" names space is now fixed.  Prefix it with a $ so that it is $in.rest.of.namespace.
  • Android: Java ByteArray to ArrayBuffer support was improved to support more types of ByteArray's.
  • Android: Latest Gradle now used (and a bug fixed against it).
  • Android: Several Console fixes; including release mode no longer logs.
  • Android: Fixed JNI crash
  • Android: Debug tools are and LiveSync fixes.
  • Android: Android P fixes!
  • Android: ReturnKey no longer fires twice
  • Android: Transition no longer crashes
  • iOS: Console fixes
  • iOS: Inspector port no longer times out quickly
  • iOS: Flexbox fixes
  • iOS: getImageAsync() added
  • iOS: searchbar and listview sizing fixes
  • All: Modal dialog fixes
  • All: Navigation fix
  • All: LayoutChanged event added
  • All: css; linear-gradient support
  • All: File System; get file size
  • All: TabView font size
  • All: Read XML from Bundles
  • Angular: Angular 6 Support!
  • Angular: router state should no longer crash the app in an invalid state
  • Webpack: Webpack 4 Support!
  • Webpack: XML Loading support
  • Webpack: Android Compression
  • CLI: Supports driving more than one iOS simulator
  • CLI: Support Java 10
  • CLI: Full application templates (Beta)
  • CLI: Allow native Objective C source as part of plugins.
  • CLI: iOS wifi driving should work again.

What do you think; I think this is a Rock'n awesome release, thank you to the different development teams (and community members) who contributed to this release!

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

Common Issues:

  1. None so far.  🙂

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 iOS Delegates and easy access to modifications.

UPDATE: After a lot of direct testing; this technique does NOT work for fixing and/or updating iOS delegates.   NativeScript does NOT follow the JavaScript specs in this area.  (in other words NativeScript is broken/buggy here, but I do not expect to see a fix for it.)  So even though the JS engine updates the code properly and the delegate object on the JS side of the bridge looks like it is updated.  The original delegate that was first created is cached and used from that point forward.   This technique is valid for any other normal JavaScript stuff; but does not work for the iOS NativeScript delegates as I had expected it to.   Sorry for the bad information, everything would/should have worked if NativeScript didn't introduce bugs into the JS engine in this area on iOS.

---

Over a year ago, I had a long discussion with the NativeScript team about opening the delegates to allow the developers to easily access and change them before they are created.   Unfortunately a couple people on the NativeScript team disagreed with me and my reasoning and rejected my pull request that would have allowed easily extending the delegates before they are created.    They unfortunately thought it was "unsafe", and that was that, the delegate doors were shut.

So then for any projects I needed to extend a delegate I pretty much had to use a custom version of the NativeScript Core Modules for my clients. This has bit me a couple times; when I upgraded as then my changes were wiped out.  (Tip: Always list any of these type changes in your project readme, with code!)

Also, I never had the time to finish my planned work around "TNS-Core-Patcher"; which would have allowed plugins to have patch files to patch the NativeScript core modules during the prepare phase and include any code like delegate changes.     The TCP project is only partially done, so this post isn't about that cool project, that still might see the light of day when I have that mythical spare time.

But instead it is about a post about a issue that Gheric posted to the ios-runtime repo yesterday.   I originally responded and said my usual spiel about about how it only works if you can get access to the delegates prototype chain and that the NS team had dismissed allowing it on this issue.    He responded back and said he didn't see anything in my examples that couldn't be done using his proposed feature.

At first I was thinking, he had no idea what he was talking about.   But I am so happily wrong!    The current version of NativeScript uses this._delegate assignment inside the class for almost every single instantiated delegate that I can see.  I just quickly searched through the code and as far as I can tell; I can get access to every single created delegate.  This is what I believe Gheric was pointing out that the underlying instantiated delegate is accessible.  If he wasn't pointing to it; then because of his persistence; he made me go look at it again and then I discovered it.  But either way; it was because of Gheric's post that I understood the ramifications of having access to the instantiated delegates.

So lets add to to that, NativeScript's current engines now support a large chunk of ES6, not full ES6, but a large enough chunk where what I need exists now.

So what does that give me?   Well, it just gave me the entire ios delegate world!!!   Delegates are no longer locked behind an artificial barrier, and I can change them however and whenever I want!!!  Can you tell I'm excited?    I just got a second Christmas!

I now have a technique that totally eliminates the stupid door the team closed. So instead of letting me have a easy door to make my changes; I have found a awesome open window to allow me to make the exact same changes.

(c) 2013,Angelo DeSantis - https://www.flickr.com/photos/angeloangelo/8607844680/

Ok, so lets get to the nuts and bolts of how to do this.  The key is the ES6 Object.getPrototypeOf()function.  This allows us to get the prototype of an already instantiated object.   So it is almost as good as my original pull request.  In my original pull request I would be able to

let x = require('someComponent');
x.exportedDelegate.prototype.addFunction = function() {
/* Do whatever iOS expects this delegate function to do */
}

Very simple, and allowed me access to all sorts of things iOS expects you to be able to do when you want certain customizations.   Doing it off the prototype chain of the exported delegate is the easiest and BEST place to do it.   It doesn't matter if the delegate is instantiated or not.

Now the WORKING technique is:

let originalPrototype = Object.getPrototypeOf(someClass._delegate);
originalPrototype.addFunction = function() {
/* do whatever iOS expects this function to do */
}

Not that much harder, and the end result is identical.   However there is one potential gotcha with this new technique; if the delegate has not been instantiated yet -- you obviously can't get access to its prototype chain.  Depending on which delegate you need to modify you might have to wrap the code in a looping setTimeout() until the delegate is instantiated.

function fixPrototype(classObject, delegateName, delegateFunctionName, delegateFunction) {
if (!classObject[delegateName]) {
setTimeout(() => { fixPrototype(classObject, delegateName, delegateFunctionName, delegateFunction, 100);
return;
}
let prototypeOf = Object.getPrototypeOf(classObject[delegateName]);
protoypeOf[delegateFunctionName] = delegateFunction;
}

/* Call it */
fixPrototype(someClass, "_delegate", "addFunction", () => { /* do whatever ios expect */ });

 

This simple function, will allow you to pass in the object class, then the delegate name (most the time "_delegate" and then the function name you want to add, and then the function itself.   It takes care of the rest.

Remember, once you have patched a delegate prototype; ALL delegates using that prototype (including any of them created in the future) will get your changes.  That is why it is so important to patch the delegate prototype, you only need to do it once and it works everywhere.