Discussion:
Expected ratio of ServiceWorker instances to Geolocation Updates
(too old to reply)
Richard Maher
2017-07-20 10:25:22 UTC
Permalink
For some time I've been arguing with W3C/IETF (and anyone else who'd
engage) that ServiceWorkers are the ideal platform to host the
Background Geolocation functionality that Ultimate Web Apps need in
order to compete on a level playing field with Native Apps. The sticking
point is usually the fleeting nature of a ServiceWorkers' lifespan. I
have always argued that it would be madness to kill them immediately and
most implementations seem to agree. (Firefox being the most aggressive
at 30secs see Bug at
https://bugzilla.mozilla.org/show_bug.cgi?id=1378587 this behaviour
prevails even with heaps of CPU/Memory)

Anyway, in order to prove that I am right, and the likes of Jake
Archibald are very much mistaken, I wrote a little Web App, Source code
can be found here:
https://drive.google.com/open?id=0B7Rmd3Rn8_hDNW1zSWRoXzBTclU (There is
a aaa_readme.txt)

Now it still needs a bit of work to provide a trip summary page and map
the trip on Google maps but I think you'll get the idea and most
importantly see the real world, actual, demonstrable relationship
between Service Worker Instances and Geolocation updates? (I wanted to
get it out before the Europeans disappeared for August

So have I done something stupid here? Am I imagining that I only get a
new Service worker instance when I'm stuck at the lights for an extended
period on the way home and position updates are nowhere to be seen? Are
my coding skills lamentable and testing skills non-existent?

If not, then I have no idea why Web Apps are not allowed to satisfy
these legitimate and very desirable user requirements. Sure, we'll get
user-empowerment, permissions, and discovery right but let's get on with
it? The TravelManagerPolyfill.js file is nearly all UA developers have
to do!

Q: Have I understood the ServiceWorker architecture correctly and
implemented a valid heuristic interrogation of ServiceWorker
instantiation over time?
Richard Maher
2017-07-21 23:56:53 UTC
Permalink
Post by Richard Maher
For some time I've been arguing with W3C/IETF (and anyone else who'd
engage) that ServiceWorkers are the ideal platform to host the
Background Geolocation functionality that Ultimate Web Apps need in
order to compete on a level playing field with Native Apps. The sticking
point is usually the fleeting nature of a ServiceWorkers' lifespan. I
have always argued that it would be madness to kill them immediately and
most implementations seem to agree. (Firefox being the most aggressive
at 30secs see Bug at
https://bugzilla.mozilla.org/show_bug.cgi?id=1378587 this behaviour
prevails even with heaps of CPU/Memory)
Anyway, in order to prove that I am right, and the likes of Jake
Archibald are very much mistaken, I wrote a little Web App, Source code
https://drive.google.com/open?id=0B7Rmd3Rn8_hDNW1zSWRoXzBTclU (There is
a aaa_readme.txt)
Now it still needs a bit of work to provide a trip summary page and map
the trip on Google maps but I think you'll get the idea and most
importantly see the real world, actual, demonstrable relationship
between Service Worker Instances and Geolocation updates? (I wanted to
get it out before the Europeans disappeared for August
So have I done something stupid here? Am I imagining that I only get a
new Service worker instance when I'm stuck at the lights for an extended
period on the way home and position updates are nowhere to be seen? Are
my coding skills lamentable and testing skills non-existent?
If not, then I have no idea why Web Apps are not allowed to satisfy
these legitimate and very desirable user requirements. Sure, we'll get
user-empowerment, permissions, and discovery right but let's get on with
it? The TravelManagerPolyfill.js file is nearly all UA developers have
to do!
Q: Have I understood the ServiceWorker architecture correctly and
implemented a valid heuristic interrogation of ServiceWorker
instantiation over time?
For those wanting to know where the Java, VMS, and C# relevance is, you
need to look at the Service Worker code echo.js, in particular: -

/*
* Even if there are no active client windows we still let Starship
* Control know where we are so thay can let us know (notify us) of a
* GeoFence we've just traversed of a bargain to be had at that pub over
* there.
*/
function tellFleetManager(payLoad)
{
return new Promise((resolve, reject) =>
{
fetch(FLEET_MANAGER, {
method: "POST",
credentials: 'same-origin',
headers: {
'Content-Type': 'application/json'
},
body: payLoad
}).then(response =>
{
if (response.ok) {
resolve(response.json())
} else {
var error = new Error(response.statusText)
error.response = response
throw error;
}
}).catch(function(error) {
console.log('Fleet request failed', error)
reject(error);
});
})
}

This code allows the fleet management C#/Java server to track all
trucks, pizzas, ski-buddies and plot them as a whole.

Loading...