Tag Archives: WebWorkers

NativeScript-SQLite Multi-Threading!

The first release of NativeScript-SQLite was April 19th, 2015 on GitHub, and April 26th to NPM. I am happy to say this plugin is now almost 4 years old, and it was one of the first plugins available to NativeScript. I believe there was two or three others released before, like NativeScript-Flashlight. By June of 2015 we had a grand total of 18 (eighteen) plugins in the NativeScript eco-system, where today we are at almost 1,000 plugins.

NativeScript-Sqlite has had a lot of upgrades like encryption, prepared queries, and several bug fixes over the last 4 years. But the newest feature; I'm probably the most proud of. Without your app changing a thing (besides setting a simple option flag); NativeScript-Sqlite can now be fully multithreaded. What do I mean by that? In a nutshell all SQLite calls can now happen in a background thread. This means that if you are inserting or reading 20 records the UI won't freeze.

A couple years ago I did a session on Performance and NativeScript; my sample app showed how doing several different things could freeze the UI easily; and the best way to deal with this was to move as much of your work to background threads.

Now if you watch this image; every time I hit the SQLite button, the "n" freezes for a few seconds. This is because the work loading and processing the records is all done on the main thread which is the UI thread, causing the Animation to stop and/or stutter.

Since NativeScript-Sqlite has always been Promise (and/or Callback) based ASYNC code; it ended up that I could preserve the entire API as is; when allowing you to use multithreading. You just need to set a flag when opening up the connection and it will become multithreaded.

And this is what it looks like when sqlite is doing everything in a background thread. Notice how smooth it is. This is because the main thread is just waiting for the acknowledgement back that everything has been loaded.

If you check out the demo app; the code change is just this:

[[code]]czoxMDk6XCJuZXcgc3FsaXRlKGRibmFtZSwge2tleTogXFxcJ3Rlc3RpbmdcXFwnLCBtdWx0aXRocmVhZGluZzogISFzcWxpdGUuSEFTX0NPe1smKiZdfU1NRVJDSUFMfSwgZnVuY3Rpb24oZXJyLCBkYkNvbm5lY3Rpb24pIHtcIjt7WyYqJl19[[/code]]

Basically if the commercial plugin has been loaded; we flip on the multithreading flag. Otherwise we leave it off. (This way the app can test, Encryption, Multithreading, Commercial features, and no extra features all in the same codebase.)

The open source version of the plugin can be easily installed by typing tns plugin install nativescript-sqlite@latest, the open source repo can be seen at https://github.com/NathanaelA/nativescript-sqlite.

The commercial version which includes Encryption, transactions, prepared queries, and now multithreading can be purchased from my site at nativescript.tools.

NativeScript - Workers

ns-workersOne of the best new features in the brand new 2.4.0 release of NativeScript is WebWorkers.    For those who have seen me around in the community; you will probably all know how long I have been harassing the NativeScript Core Teams to get this done (Since Aug of 2015).  I even went so far as to create a plugin (NativeScript-WebWorkers) that allowed you to spin up more JS threads but with the major limitation that they didn't have access to the native OS side of things, they were only pure JS.    So getting real 100% NativeScript webworkers this release means I am a VERY happy camper!

The feature is fully cross platform (i.e. works on iOS and Android) and allows you to spin up additional JavaScript engines to do all your heavy lifting needs in the background.    Now obviously, the more you spin up the more memory and cpu you will use; so you want to treat them as a precious resource and only spin up those you need.   Let me re-iterate; use these for only heavy duty processes; each worker is another FULL JS engine, which takes a chunk of memory and cpu to just start and maintain.

They still have full access to the iOS and/or Android runtime just like normal.   The only difference between them and the main thread is that you do not have any valid access to the GUI or GUI elements.   You can attempt to modify the GUI, but you will crash your app as you are not allowed in even in a native app to modify the GUI outside the main thread.  Same rules apply to a NativeScript app.

The NativeScript Core Teams modeled the background threads after the web workers model.  They are created, developed and destroyed the same way as a browser web worker would be.   So lets dig in.

Everything is passed via messages between the workers and the main thread; so lets look at a sample demo:

main file

"use strict";
exports.onNavigatingTo = function(args) {
   let myWorker = new Worker('./myWorker.js');
   myWorker.onmessage = function(msg) {
     console.log("Hi I'm a message from the worker: ", msg.data);
     myWorker.terminate();  // We no longer need the worker around, so kill it.
   };
   myWorker.onerror = function(err); {
      console.log("Opps, something went wrong in the worker", err.message);
   };
   setTimeout(function() { worker.postMessage("a Cool Message"); }, 500);
}

myWorker.js
"use strict";
require("globals");
global.onmessage = function(msg) {
  console.log("Got a message form the main thread!", msg.data);
  postMessage("Worker's cool Message");
  // global.close();  // If ran, this would close the worker from inside.
};

global.onerror = function(err) {
  console.log("We can handle our own errors too", err.message);
};

Now as you can see we have two files; the first file is from the main thread it starts the new worker by doing let myWorker = new Worker([path to worker script]); this is how you start a brand new worker.   The new worker will load that JavaScript file and start it up.  Now there are some gotcha's we are going to cover on the worker side that you will want to know about.

  1. You want to require('globals'); as your first or second line.    If you do NOT require the global module, you will not have access to console, setTimeout , setInterval, and any other function you are used to using globally.   So requiring this function is pretty important for most workers.
  2. When you assign .onmessage (or .onerror if you are using it) you must assign them to the global variable.  The new version of the Android engine is enforces "use strict"; properly and having implied "this" variables is NOT allowed.  So as a habit when assigning something to the global scope; implicitly use global.
  3. All messages have a .data parameter that contains the data you sent from the other side.  When you do a postMessage({cool: "wow", I: "am"}); this will be in msg.data.cool and msg.data.I in the onmessage message.  This might catch you, but is easily fixed.  Please make sure that any objects you send across to the other side is fully serializable (i.e. no recursion, no native gui elements) ; if not it will fail unless you use some third party lib to serialize the recursive structure.
  4. Terminate() or Close() the webworker if you are no longer going to use it.  If you are planning on continuing to use it; then leave it running it is cheaper to leave it running (& not doing anything) than to terminate and restart.
  5. If you get an error message like this: Worker Error: Uncaught TypeError: Cannot read property 'prototype' of undefined this can mean it can't find the worker file that you wanted to load.  Using the tilde to say main app folder '~/path/to/worker' is the easiest way to fix it.  OR it can mean that the file that is required is doing something that is causing the worker to crash.
  6. If you see the error: Uncaught TypeError: global.moduleMerge is not a function The solution is to do a require('globals'); at the top of your worker file.

Once you understand these items, you are ready to rock and create cool background threads to do all your busy work so that your main thread never freezes again...