Jump to content

Search the Community

Showing results for tags 'worker'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Categories

There are no results to display.

Forums

  • Welcome to Smart Mobile Studio
    • News and Information
    • Pre-Sales Questions
    • Smart In the Media
    • Smart Contests
    • Meta
  • Smart Mobile Studio Discussion
    • General
    • IDE
    • RTL
    • Code
    • Client Server
    • Platform
    • Graphics
    • Deployment
    • Suggestion box
  • Smart Mobile Studio support
    • Support
    • Bug report
  • General Discussion
    • Pascal
    • Delphi
    • Javascript
    • HTML/HTML5
    • CSS
  • Resources
    • Website
    • Download Smart Mobile Studio

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Website URL


Location


Interests


Company name


Position

Found 3 results

  1. lynkfs

    serviceWorkers (fetch)

    WebWorkers are a way of off-loading tasks from the main browser into a separate thread. ServiceWorkers sit between the browser and the network and extend these capabilities by a couple of powerful features : offline detection and interception possibilities of network requests (fetch api) resource caching under program control (new cacheStorage api) background syncing saving browser apps as icons on the homescreen serving push notifications ServiceWorkers are integral to Progressive Web Apps Architecturally a serviceWorker is just a separate js file, which means that 2 Smart projects are needed (one for the main program, one for the serviceWorker). For normal webWorkers there is a workaround in that it is possible to generate an in-memory js-file using the blob: protocol (see forum post here), so the webWorker can be generated from the main program. For serviceWorkers this approach should work as well, however all modern browsers have closed this avenue (see here, here and here). Not sure if this is temporary or permanent. ServiceWorkers are created in the main program, a bit differently then normal. No 'new' object constructor but instead a call to a registration function, returning a promise. var navigator external 'navigator': variant; if navigator.serviceWorker then begin navigator.serviceWorker.register('sw-v1.js') .then(procedure(registration:variant) begin console.log('Service Worker registered with scope: ', registration.scope); end) .catch(procedure(err:variant) begin console.log('Service worker registration failed: ', err); end) end; (Adding the link to the external navigator object in the first line means no asm blocks are required. The above could be wrapped up in a TServiceWorker object). 1) network request interceptions (fetch) For the serviceworker : start a new project and delete all pre-generated forms and units. Set output to js file (linker) and unclick 'use main body' in code generation. Replace contents of root-unit with var sw : variant; asm @sw = self; end; sw.addEventListener("fetch", procedure(event:variant) begin if (event.request.url.includes("res/app.css")) then begin event.respondWith( fetch("res/appmodified.css"); ) ); end end); Soon as the request to load the standard Smart resource-file 'res/app.css' is detected, it is intercepted and replaced with another resourcefile. Usually communication between worker and main is done through messaging. There is however a short-cut where the worker can modify the calling main page directly : add a Response object to the event.responseWith method with appropriate headers asm event.respondWith( new Response( "body {background: green !important;}", {headers: {"Content-Type": "text/css" }} ) ); end; this will change the backgroundcolor of the form to green. Change the Content-Type to "text/html" and the preceding string to valid html and the form will be replaced with the rendered html content. demo (click button and do refresh) and projects (main and worker)
  2. lynkfs

    webworker demos fail

    The webworker demos (featured demos) seem to fail ? @jarto
  3. lynkfs

    Multi threading

    Multi-threading The below approach works. My question though is, is there a simpler solution to the story-line below or is this it ? Computationally intensive tasks can be processed separately from the single thread main js-loop using webworkers. In this case I want to separate an existing processor-intensive procedure (TForm1.TrainNetwork) into its own thread. postMessage is the mechanism which can cross process-space divides and is how the main program and webworkers communicate. This is somewhat different from the CustomEvent mechanism described by Jon in this article. I found out that postMessage by the way works equally well in the same browser-tab, without using webworkers at all. To illustrate : the following statement TrainNetwork(<parameter>); could be replaced by posting a message and adding a listener : window.postMessage(['TrainNetwork','<parameter>'],'*'); window.addEventListener('message',procedure(evt:variant) begin case evt.data[0] of 'TrainNetwork': begin TrainNetwork(evt.data[1]); end; end; end, false); which works, but doesn't make much sense of course. It replaces a simple function call with sending a message, listening to it and then making the function call after all. However this is the pattern used with webworkers. For using webworkers, replace 'window' with 'worker' in the code above (and forget about the second '*' parameter in the postMessage call). There is a demo in the Featured Demos section on how to initialise and use webworkers. Which shorthands to var worker : variant := new JObject; asm @worker = new Worker('worker.js'); end; where 'worker.js' contains the logic of the worker. The simplest of workers just echoes incoming requests : onmessage = function(e) { console.log('Message received from main script'); console.log('Posting message back to main script'); postMessage(e.data); } although the following addListener construct, which produces the same results, is perceived to be better : self.addEventListener('message', function(e) { self.postMessage(e.data); }, false); Next step is to actually let the worker execute the TrainNetwork procedure. Since worker.js is javascript, it needs javascript. What worked for me is to use the command line compiler to compile TrainNetwork into TrainNetwork.js and include this file in the worker : self.addEventListener('message', function(e) { importScripts('TrainNetwork.js'); console.log('TrainNetwork executed'); self.postMessage(e.data); }, false); The limit to this approach is that workers cannot access the Dom at all, which means that TrainNetwork cannot have any visual contents. If for instance the results of the TrainNetwork procedure need to be displayed, then the solution will be to either - leave that to the main program - let the worker construct a set of visual objects with no reference to the dom, serialise them and insert them in the main program - let the worker construct a compound html string and insert this into the innerHtml property of some element in main
×