- From: Jake Archibald <notifications@github.com>
- Date: Thu, 07 May 2020 06:10:41 -0700
- To: w3c/ServiceWorker <ServiceWorker@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/ServiceWorker/issues/838/625245717@github.com>
> 1. service worker stays alive for 30 minutes. which means my callback gets called. Bad for privacy and battery. > 2. service worker gets killed and it boots up again by itself which executes my `setInterval` code again from scratch. But your `setInterval` code went away once the service worker was killed. ```js setInterval(() => { console.log('a'); }, 5000); setInterval(() => { console.log('b'); }, 10000); addEventListener('fetch', (event) => { setInterval(() => { console.log('c'); }, 10000); }); ``` Here are three interval callbacks. So, we spin up the service worker, which do we fire? All we have is two callbacks. The third callback hasn't even been created yet. How can that work? Also, spinning up the service worker every 30 minutes is bad for privacy and battery. > 3. maybe `push` event gets called and this is how service worker boots up again. Even in this case, booting up means running the code in the global scope. So all good. `push` requires you show a notification so the user knows you're doing stuff in the background. If you're doing this every 30 minutes, it's likely the user will block you. > So what's the risk or downside of this? i don't think there's one. Privacy and battery. https://web.dev/periodic-background-sync/ is a more controlled way of doing this. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/w3c/ServiceWorker/issues/838#issuecomment-625245717
Received on Thursday, 7 May 2020 13:10:54 UTC