Tag Archives: NativeScript

NativeScript Plugins: A Deep Dive - With the Three Stooges

And the second talk I was in at the NativeScript 2017 DevDays, us now up.  My cohorts in crime; and my awesome nStudio team mates; Nathan Walker and Brad Martin is now up.   Audio is a little low; but you can hear everything.

Unfortunately, the majority of my information was chopped since we ran out of time.  This was planned for and sorta expected as we weren't sure exactly how much of the info we would get to present in the time we had.   So almost all my content is totally self described in the slide deck.   😉

One word about the interactive slide deck, some of the slides have a "Down".  We groups the different subjects into their own like mini-slide decks.  So you can go "Down" to see everything about that specific sub-topic.

You can view the slide deck on our nStudio website.  http://nStudio.io/talks/pluginsdeepdive it has a lot more information that we were able to present.

 

 

 

NativeScript: Performance from the Trenches

Well my video for Performance from the Trenches, was released today!   This is the talk I gave at the NativeScript Developer Days 2017.

 

There is a lot of good useful information in this Talk, so enjoy.

Slide Deck: Performance

NativeScript App: https://github.com/NathanaelA/PerformanceFromTheTrenches

V8-Natives Repo: https://github.com/NathanaelA/v8-natives

 

 

 

NativeScript and Console logging on iOS (including XCode 9)

Been a while since I posted; and most this info was going to be presented at the NativeScript Developer days speech that we ran out of time in our cool session.     So I'm going to present it here, because I think this will help a lot of people.

First of all, NativeScript has an issue (at least on my machine) where the logging is incomplete and missing important things, like crash reports (and now on XCode 9, non-existent).

Well, when I ran into the two first issues using XCode 8.2 & 8.3.   I figured out a work around, because I hate my tools not working.    🙂

There is a really awesome set of utilities called libimobiledevice this set of utilities lets you do all sorts of things with a real iphone when it is connected to your computer including reading the logs.

 

Real Devices (any version of iOS)

So I typically do idevicesyslog | grep CONSOLE and it will then show me all my logs for the device and it basically fixes any issues other than some exception reporting.   Most the time my app doesn't crash so that command above I use probably 99% of the time.    However in the cases I need to see the NativeScript actual crash logs.   I use the above command and it will spit out the PID of your app next to the CONSOLE word.  I then cancel it, and do a idevicesyslog | grep <PIDID> and this gives me the full log including anything the NativeScript runtimes print.

Please note this only works for real devices.

Simulators (iOS 10 and before)

UPDATE for iOS 11 simulators, please see below!

Now for simulators; the process is very similar.

You run xcrun simctl list | grep Booted and it will give you a line like this:
iPhone X (4701B6F6-0EE4-423F-B5E2-DE1B5A8C32AC) (Booted)

Do you see that big old long uuid; you need that.

tail -f ~/Library/Logs/CoreSimulator/4701B6F6-0EE4-423F-B5E2-DE1B5A8C32AC/system.log | grep CONSOLE

This allows you to grep the log from that specific simulator.   Again, using the grep CONSOLE filter you can limit it to any console logs.   And you can also use grep <PIDID> to filter it to any application if you need the filtered down to, if you are needing the specific NativeScript application level logging or crash reports too.

 

Simulators (iOS 11)

iOS 11, changed the logging for the Simulator drastically.  Technically iOS 10 changes the NSLog drastically, but 11 enforced some new rules.   So iOS 11 broke the NativeScript internal logging; but it broke the cool tail trick above.    Everything now is now running through the new os_log facility.  The easiest way to get logging from your simulator is this single line:

log stream --level debug --predicate 'senderImagePath contains "NativeScript"'
--style syslog

Please note this is case sensitive, if you don't case the senderImagePath and NativeScript you won't have your filtered logging (or any logging at all if you type it wrong).   This part of it filters it down to just any NativeScript logging from all emulators running.

I created a simple bash script called /usr/bin/local/tnslog and dropped the above line it in and then chmod +x /usr/local/bin/tnslog 'd it.  So I can easily just start tns, and then open another terminal tab; and type tnslog and have all my logging again.

 

Installation

The simulator you need no extra tools.   For real devices you need the libimobiledevice toolset, which you can easily install via brew with the following two commands:

brew install --HEAD usbmuxd

and

brew install --HEAD libimobiledevice

It is really important that you install from head, the changes in Xcode 9 and iOS 11 have made a couple changes to both those libraries require some updates and the normal brew packages are out of date and doesn't have it.  So you need the latest and greatest.

 

Final Thoughts

I have been lazy, and just documented the steps.   If someone has some spare time and wants to create a quick bash script to automate the grabbing of the simulator id, and starting the older logging; against that simulator that would be cool to add to our tools.  But since I'm using primarily iOS 11 emulators now; my tnslog script handles all logging until the NativeScript team can fix their tool's issues.

 

NativeScript 3.2.0 Released

Well, looks like I was on the ball this time; I actually beat Progress to the punch.   😉    3.2.0 has been released to NPM.

  • Blur and Focus events added
  • Android keeps nativeView when navigating forward to eliminate the tear down and re-build when navigating back.
  • Nasty memory leaks in iOS fixed; this one is worth the upgrade alone!
  • Some XCode 8.3 and 9 fixes
  • iOS LiveSync fixes
  • Some Webpack and Signing issues fixed
  • Android metadata generator fixes

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

Common Issues:

  1. Plugins fails; this is a known issue do to the complete revamp of the lower levels of the core modules design.  Some plugins need a lot of changes to work in 3.x; so you will have to wait for the third party authors to get caught up (Even I'm not caught up).    My plugins site  http://plugins.nativescript.rocks should be listing both version v2 & v3 plugins separately so that you can easily find 3.x or 2.x plugins.

NativeScript: 3.1.x released

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

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

Upgrading (Core):

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

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

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

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

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

Common Issues:

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

NativeScript: @Next- should I use it?

Short version: Nope...   😉

Long Version:

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

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

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

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

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

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

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

 

NativeScript: Android application upgrade issues

Updated Information: A RELATED ISSUE CAN also effect ALL normal android applications that are just a simple upgrade in that your newly upgraded app WON'T be upgraded properly on the device.  The client running your app, will revert to the prior version and/or prior data.

This doesn't normally crash the app, like the original issue (discussed below)-- but your client will be wondering why your upgrade didn't change anything...   So my recommendation is to apply the application backup disabling fix listed below so you don't run into either of these issues.

This new issue effects:

  1. Android 6 and up devices.
  2. Any application upgrade/update.
  3. Does not affect a brand new installs on a device that has never had your application. Will affect devices that deletes your app and later re-installs.  So this is doesn't affect a new customer, but will effect any exist customers.

The issue described below has been patched in v3.01 of the Android Runtimes, technically it should be fixed.  However as I suspected and we have confirmed recently; the root issue actually can cause other related issues, and it is unpatched and with no eta for its solution, hence this updated blog post with a work around...


For those who don't want to read the hows; the information you need is:

  1. This is an Android only issue; iOS doesn't have this issues.
  2. This is an Android 6.0 and higher issue.
  3. Fresh new installs will not have this issue, only devices that have had a old version on it.
  4. The main issue only occurs when you are upgrading from 2.x to 3.0 application.  (See update info above, related issue is different)    So new apps that started as 3.0 won't have this issue; and apps that stay 2.x won't have issues.  Only apps upgrading from 2.x to 3.x will have this issue on clients that are upgrading.
  5. This is a conflict between a file (in 2.5) that was changed into a folder (in 3.0).
  6. This is in the cases I've seen are caused by Google Auto-Backup auto restoring files/settings on the application installation.

If your app is a upgrade from 2.x to 3.x and you are wanting to release it to the Amazon or Google play store; don't do it -- for you and your customers sanity.  The app will crash on startup and you will be left scratching your head as to why it works (new customers) sometimes and why it doesn't (existing customers).

Progress is aware of the issue and how critical it is; so I would guess we should see a patch shortly (released in 3.01 ), however if you are under the gun and must release today; I have a fix that should also work, see end of blog post.   😉


The longer story; Brad Martin pinged me late last week because he ran into this issue.   He is one of the awesome members of the nStudio team, along with myself and Nathan Walker.  So I stopped what I was doing and began to help him out.    By the time we finished a couple hours of debugging (it was LATE Friday night) we had determined a number of things, but not the underlying issue.

We figured out that on what appeared to be a fully clean device it would still crash.

What we knew

  1. It didn't matter if it was Android @ release  or Android @ next runtimes.  (Wasn't runtime dependent.  Included cleaning this multiple times)
  2. We knew his tns-core-modules was 100% correct and it wasn't related to 3.00 or 3.01
  3. We knew his his tns-core-modules & widgets matched 100% a clean version on another machine (no npm corruption)
  4. We knew the .APK generated worked on all the emulators fine.
  5. We were pretty sure LiveSync couldn't be causing the problem (we nuked it several times and installed via a couple different methods)
  6. The platforms / src did NOT have that file in it, so no way the built APK could even get it.

Alexander Vakrilov (from the NS team) noticed the call stack was pointing to the old 2.5 style.js file.    I knew the 2.5 style.js file couldn't be coming from the freshly built apk and it wasn't in the LiveSync folder; so I actually thought that maybe there must be two different ways this error could appear, one of them would be someone upgrading and having the extra style.js in the node_modules/tns-core-modules, the other would be what Brad was running into.

Then Brad confirmed today that the style.js file was present in his stack trace.   That actually confused me quite a bit, because with the data we had above, that didn't make any real sense.  We had a fully clean APK without that file in it.  How was the device getting it?     We had manually deleted the livesync folder and even verified it was empty before we ran the app.    But the app would still crash with that call stack.    Color me confused...

So I took some time to scan the NativeScript android runtime source code for its livesync stuff.  I had seen the code before, but I wanted to make sure nothing major changed in 3.0.    I couldn't find anything other than what I expected to see.  No "other" LiveSync folders, so I was still confused...

So how is the device getting this file on it???

So I thought for a few minutes; in my best Sherlock Holmes voice; "When you have eliminated all which is impossible, then whatever remains, however improbable, must be the truth"

  1. Appears to be primarily happening on Real Android devices.
  2. Clear Data, works if done after the install.
  3. Doesn't matter how the app is installed.
  4. LiveSync doesn't appear to be responsible
  5. The generated APK is 100% correct.

If finally hit me; some sort of external force is causing the issue.   I was so focused on NativeScript; I didn't think about the other items on a REAL DEVICE.  It hit me like a 2x4... What is one thing that Real devices typically have over emulators???    A Google account is normally setup and syncing...    So I told Brad...

  1. De-install app (again)
  2. Nuke the LiveSync Folder (just to make sure)
  3. Turn on Airplane Mode (What a trouper he is, didn't even ask me why!)
  4. do a TNS run

App worked!    I'm like AWESOME, Brad is like WTF!     I don't blame him, I didn't tell him what the test was for, and so he had no idea what I was testing for.  And the poor guy has been not only doing my tests, but he had also put in a lot of time himself testing things...   He just had the surprising fact that it actually worked on his phone when in Airplane mode.    Me, I'm like I know what it is...

Android 6.0 Introduced a cool features called Auto-Backup; this nice feature backs up your data and files from your app.   Well unfortunately for us NativeScript users; NativeScript stores its .JS files in the /files/app folder.   Guess what one of the folders that is AUTO BACKED UP?   /files folder...

What is happening is there is a cool setting with your device, that will Automatically restore application settings when you re-install a application.

When you install app; it detects the name is the same, it restores the /files/ folder (adding any MISSING files) which then puts the old 2.5 styles.js file into the folder.    And then NativeScript attempts to load this file, and crashes...


My fix:

  1. Open your app/App_Resources/Android/AndroidManifest.xml file change or set/add the key allowBackup in your <Application> tag to "false" and the tools:replace.  So it should look like:

&lt;application
   android:name="com.tns.NativeScriptApplication"
   android:icon="@drawable/icon"
   android:label="@string/app_name"
   android:theme="@style/AppTheme"

   android:allowBackup="false"
   tools:replace="android:allowBackup"
&gt;

Then in the Manifest section you need to add the xmlns:tools namespace entry:
&lt;manifest xmlns:android="http://schemas.android.com/apk/res/android"
 xmlns:tools="http://schemas.android.com/tools"
 package="__PACKAGE__"
 android:versionCode="1"
 android:versionName="1.0"&gt;

By disabled the backup; you also disable the auto-restore of just this app's setting and files...  (Thanks Brad for confirming this works!)

 

NativeScript: 3.0.1 Released

Normally I don't do a post about a simple point release; however if you are one of the many who upgraded to 3.00; you will really want to grab 3.0.1.

There are lots of issues resolved from the major update 3.0.0; some of them include:

  • Several crashing bugs on Android
  • Image issues
  • Action bar issues on iOS
  • Layout issues on iOS
  • bindingContext issues
  • TextField issues
  • Fixing --debug-brk on Android

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 iOS

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

For Android

> tns platform remove android
> tns platform add android@latest

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

NativeScript: Downgrading to 2.5

If you are needing to use a plugin that hasn't been upgraded to support 3.0 you basically have three choices, and guess what I can help with each of them...

  1. Wait for it to be updated; you can check my site http://plugins.nativescript.rocks; then select the "3.0" plugins list, now you can easily see when a plugin has 3.0 compatibility.
  2. Update it your self; or since I'm a contractor; you pay me; I will upgrade the plugin for you.
  3. Downgrade to NativeScript 2.5; I suspect most of you are the most interested in this since you are here...

The good news is that several of the 3.0 parts are backwards compatible.  You can be running the 3.0 NativeScript command line and build 2.5 apps.  You can also be using the 3.0 release runtimes with the core 2.5. modules.  So here is the way to downgrade a 3.0 app into a 2.5 app.

 

To downgrade PAN (Plain Awesome NativeScript) apps:

npm install tns-core-modules@2.5.2 --save
npm remove nativescript-dev-android-snapshot --save-dev
tns platform clean ios
tns platform clean android

If you are using TypeScript in your apps you need to do:

npm install typescript@2.1.6 --save-dev
npm install nativescript-dev-typescript@0.3.7 --save-dev

To Downgrade NAN (NativeScript ANgular) apps:

npm install --save @angular/animations@~4.0.0
npm install --save @angular/common@~4.0.0
npm install --save @angular/compiler@~4.0.0
npm install --save @angular/core@~4.0.0
npm install --save @angular/forms@~4.0.0
npm install --save @angular/http@~4.0.0
npm install --save @angular/platform-browser@~4.0.0
npm install --save @angular/platform-browser-dynamic@~4.0.0
npm install --save @angular/router@~4.0.0
npm install --save nativescript-angular@~1.5.0
npm install --save reflect-metadata@^0.1.8
npm install --save rxjs@~5.2.0
npm install --save zone.js@~0.8.4
npm install --save tns-core-modules@2.5.2

npm install --save-dev @angular/compiler-cli@~4.0.0
npm install --save-dev babel-traverse@6.15.0
npm install --save-dev babel-types@6.15.0
npm install --save-dev babylon@6.11.2
npm install --save-dev htmlparser2@^3.9.2
npm install --save-dev Lazy@1.0.11
npm install --save-dev typescript@2.1.6
npm install --save-dev nativescript-dev-typescript@0.3.7
npm remove --save-dev nativescript-dev-android-snapshot

tns platform clean ios
tns platform clean android


One note that seems to confuse some people; you can continue to use the NativeScript 3.0 CLI with NativeScript 2.5 applications.  You can also use the 3.0 Runtimes (highly recommended actually) with your 2.5 Core modules applications.

Any of my 2.5 applications are now (This setup is fully 2.5 plugin compatible):
- 3.0 CLI
- 3.0 Runtimes
- 2.5 TNS Core Modules (if NAN, then you need the old Angular stuff as listed above)

And my 3.0 applications are (This is the standard 3.0 setup)
- 3.0 CLI
- 3.0 Runtimes
- 3.0 TNS Core Modules  (if NAN, then you need the new 3.0 compatible Angular Stuff)

 

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.