Welcome to OStack Knowledge Sharing Community for programmer and developer-Open, Learning and Share
Welcome To Ask or Share your Answers For Others

Categories

0 votes
589 views
in Technique[技术] by (71.8m points)

javascript - Expected ratio of ServiceWorker instances to Geolocation Updates

EDIT: There is a new version of my Brotkrumen Web App in the same location.

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!

Original Question:

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 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. (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?

See Question&Answers more detail:os

与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…
Welcome To Ask or Share your Answers For Others

1 Answer

0 votes
by (71.8m points)
Waitting for answers

与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…
Welcome to OStack Knowledge Sharing Community for programmer and developer-Open, Learning and Share
Click Here to Ask a Question

...