locked
Where to declare web worker?

    Question

  • Where abouts in my default.js should I be declaring a new instance of a web worker?

    The quickstart guide says a good place to register events is after the "args.setPromise(WinJS.UI.processAll());" but if I create the web worker object there then it is out of scope for my functions I have created further down the page.

    Is it best to create it outside of the app.onactivated function or should I be using some sort "return" syntax to make it available outside of the scope of the function?

    Sorry for the noob question, I am still learning and just practicing various different things to learn them properly.

    Friday, January 25, 2013 11:47 PM

Answers

  • Your variable myWork is the worker and is in scope for this entire module. If you expect messages to come back from that worker relatively soon, you can consider adding the listener for "message" at that same time. But if it's only going to process stuff in response to the messages you post to it, then the structure you have here is just fine.

    Simply said, whatever JS you point the worker to when you create it will go ahead and execute on another thread. If it does a postMessage somewhere in that process, without waiting for you to do anything else, then you want to add your message listener right away.

    The worker is really independent of whatever else is going on in the app, e.g. page loading, UI processing, etc., so you can really do what's right for the worker's design and how it intends to communicate with the app.

    Kraig

    Author, Programming Windows 8 Apps with HTML, CSS, and JavaScript, a free ebook from Microsoft Press


    • Marked as answer by Song Tian Thursday, January 31, 2013 12:50 PM
    Saturday, January 26, 2013 2:31 AM

All replies

  • May be easier if I show you what I mean.  I wrote this up quick (didnt test it so my have typos).  Is this the right way to go about it declaring the web worker at the top?

    (function () {
        "use strict";
    
        WinJS.Binding.optimizeBindingReferences = true;
    
        var app = WinJS.Application;
        var activation = Windows.ApplicationModel.Activation;
        var myWork = new Worker("worker.js");
    
        app.onactivated = function (args) {
            if (args.detail.kind === activation.ActivationKind.launch) {
                if (args.detail.previousExecutionState !== activation.ApplicationExecutionState.terminated) {
                    // TODO: This application has been newly launched. Initialize
                    // your application here.
                } else {
                    // TODO: This application has been reactivated from suspension.
                    // Restore application state here.
                }
                args.setPromise(WinJS.UI.processAll());
    
                // add events
    
                $("#submit").click(this, submit_Click);
                myWork.addEventListener("message", worker_Message, false);
            }
        };
    
    
        app.oncheckpoint = function (args) {
            // TODO: This application is about to be suspended. Save any state
            // that needs to persist across suspensions here. You might use the
            // WinJS.Application.sessionState object, which is automatically
            // saved and restored across suspension. If you need to complete an
            // asynchronous operation before your application is suspended, call
            // args.setPromise().
        };
    
    
        function submit_Click(e) {
    
            var myMessage = $("#theMessage").val();
            myWork.postMessage({ message: myMessage });
        }
    
        function worker_Message(e) {
            $("#result").html(e);
        }
        
        app.start();
    })();
    

    Friday, January 25, 2013 11:53 PM
  • Your variable myWork is the worker and is in scope for this entire module. If you expect messages to come back from that worker relatively soon, you can consider adding the listener for "message" at that same time. But if it's only going to process stuff in response to the messages you post to it, then the structure you have here is just fine.

    Simply said, whatever JS you point the worker to when you create it will go ahead and execute on another thread. If it does a postMessage somewhere in that process, without waiting for you to do anything else, then you want to add your message listener right away.

    The worker is really independent of whatever else is going on in the app, e.g. page loading, UI processing, etc., so you can really do what's right for the worker's design and how it intends to communicate with the app.

    Kraig

    Author, Programming Windows 8 Apps with HTML, CSS, and JavaScript, a free ebook from Microsoft Press


    • Marked as answer by Song Tian Thursday, January 31, 2013 12:50 PM
    Saturday, January 26, 2013 2:31 AM
  • Ok cool. I thought I better check as often there are memory implications in things or recommended patterns I don't know about.
    Ps. I really liked your book. It was very easy to read and helped me tremendously. I'm going to re-read it soon so it all sticks.
    Saturday, January 26, 2013 4:46 PM