Jump to content

Search the Community

Showing results for tags 'serviceworker'.



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 1 result

  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)
×