{"id":416,"date":"2016-11-08T11:42:49","date_gmt":"2016-11-08T11:42:49","guid":{"rendered":"http:\/\/fluentreports.com\/blog\/?p=416"},"modified":"2016-11-16T16:35:59","modified_gmt":"2016-11-16T16:35:59","slug":"nativescript-workers","status":"publish","type":"post","link":"http:\/\/fluentreports.com\/blog\/?p=416","title":{"rendered":"NativeScript - Workers"},"content":{"rendered":"

\"ns-workers\"<\/a>One of the best new features in the brand new 2.4.0 release of NativeScript is WebWorkers.\u00a0\u00a0\u00a0 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).\u00a0 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. \u00a0\u00a0 So getting real 100% NativeScript webworkers this release means I am a VERY happy camper!<\/p>\n

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. \u00a0\u00a0 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.\u00a0\u00a0 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.<\/p>\n

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

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

Everything is passed via messages between the workers and the main thread; so lets look at a sample demo:<\/p>\n

main file<\/code>
\n

"use strict";\nexports.onNavigatingTo = function(args) {\n\u00a0\u00a0 let myWorker = new Worker('.\/myWorker.js');\n\u00a0  myWorker.onmessage = function(msg) {\n\u00a0\u00a0\u00a0\u00a0 console.log("Hi I'm a message from the worker: ", msg.data);\n     myWorker.terminate();  \/\/ We no longer need the worker around, so kill it.\n   };\n   myWorker.onerror = function(err); {\n      console.log("Opps, something went wrong in the worker", err.message);\n   };\n   setTimeout(function() { worker.postMessage("a Cool Message"); }, 500);\n}<\/pre>
\nmyWorker.js<\/code>
\n
"use strict";\nrequire("globals");\nglobal.onmessage = function(msg) {\n  console.log("Got a message form the main thread!", msg.data);\n  postMessage("Worker's cool Message");\n  \/\/ global.close();  \/\/ If ran, this would close the worker from inside.\n};\n\nglobal.onerror = function(err) {\n  console.log("We can handle our own errors too", err.message);\n};\n<\/pre>
\nNow 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]);<\/code> this is how you start a brand new worker.\u00a0\u00a0 The new worker will load that JavaScript file and start it up.\u00a0 Now there are some gotcha's we are going to cover on the worker side that you will want to know about.<\/p>\n
    \n
  1. You want to require('globals');<\/code> as your first or second line. \u00a0\u00a0 If you do NOT require the global module, you will not have access to console<\/code>, setTimeout<\/code> , setInterval<\/code>, and any other function you are used to using globally.\u00a0\u00a0 So requiring this function is pretty important for most workers.<\/li>\n
  2. When you assign .onmessage<\/code> (or .onerror<\/code> if you are using it) you must assign them to the global variable.\u00a0 The new version of the Android engine is enforces "use strict";<\/code> properly and having implied \"this\" variables is NOT allowed.\u00a0 So as a habit when assigning something to the global scope; implicitly use global.<\/code><\/li>\n
  3. All messages have a .data parameter that contains the data you sent from the other side.\u00a0 When you do a postMessage({cool: "wow", I: "am"});<\/code> this will be in msg.data.cool<\/code> and msg.data.I<\/code> in the onmessage message.\u00a0 This might catch you, but is easily fixed.\u00a0 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.<\/li>\n
  4. Terminate()<\/code> or\u00a0Close()<\/code> the webworker if you are no longer going to use it.\u00a0 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.<\/li>\n
  5. If you get an error message like this: Worker Error: Uncaught TypeError: Cannot read property 'prototype' of undefined<\/em><\/strong> this can mean it can't find the worker file that you wanted to load.\u00a0 Using the tilde to say main app folder '~\/path\/to\/worker' is the easiest way to fix it.\u00a0 OR<\/strong> it can mean that the file that is required is doing something that is causing the worker to crash.<\/li>\n
  6. If you see the error: Uncaught TypeError: global.moduleMerge is not a function <\/code><\/strong>The solution is to do a require('globals'); <\/strong>at the top of your worker file.<\/li>\n<\/ol>\n
    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...<\/p>\n","protected":false},"excerpt":{"rendered":"
    One of the best new features in the brand new 2.4.0 release of NativeScript is WebWorkers.\u00a0\u00a0\u00a0 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).\u00a0 I even went so far as… Continue reading NativeScript - Workers<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[15,7],"tags":[16,86,85,84],"class_list":["post-416","post","type-post","status-publish","format-standard","hentry","category-nativescript","category-performance","tag-nativescript","tag-threads","tag-web-workers","tag-webworkers","entry"],"_links":{"self":[{"href":"http:\/\/fluentreports.com\/blog\/index.php?rest_route=\/wp\/v2\/posts\/416","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/fluentreports.com\/blog\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/fluentreports.com\/blog\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/fluentreports.com\/blog\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/fluentreports.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=416"}],"version-history":[{"count":6,"href":"http:\/\/fluentreports.com\/blog\/index.php?rest_route=\/wp\/v2\/posts\/416\/revisions"}],"predecessor-version":[{"id":436,"href":"http:\/\/fluentreports.com\/blog\/index.php?rest_route=\/wp\/v2\/posts\/416\/revisions\/436"}],"wp:attachment":[{"href":"http:\/\/fluentreports.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=416"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/fluentreports.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=416"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/fluentreports.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=416"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}