Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #37416 > unrolled thread

Expected ratio of ServiceWorker instances to Geolocation Updates

Back to article view | Back to comp.lang.java.programmer

Contents

  Expected ratio of ServiceWorker instances to Geolocation Updates Richard Maher <maher_rjSPAMLESS@hotmail.com> - 2017-09-14 13:15 +0800

#37416 — Expected ratio of ServiceWorker instances to Geolocation Updates

Please be advised that, as promised/threatened, I have added the Trip 
Summary page and you can now map and replay your trip on Google Maps.

The new version of the code is at the same link 
https://drive.google.com/open?id=0B7Rmd3Rn8_hDNW1zSWRoXzBTclU

Most important design/proposed-specification change is that 
TravelManager subscription should now be Client specific. The 
TravelEvent must contain the intended Client.id (TravelEvent.source.id). 
This means that the UA must monitor and filter GeoLocation updates per 
client. I have also added new demo functionality such as a Trip Summary 
that is displayed when you press the "Arrive" button. The trip can also 
be replayed onto Google Maps by pressing "Map Trip" or "Replay". If the 
last and next geolocation updates for the trip are both visible in the 
Map window then smooth Marker movement is achieved via CSS transitions.

*PLEASE* help Background GeoLocation get up and help Web Apps compete 
with Native Apps!

If there is something wrong with my TravelManager solution design then 
let me know. Tear holes in it!

Cheers Richard


On 20-Jul-17 6:21 PM, Richard Maher wrote:
 > 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?


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.

[toc] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web