Discussion:
[whatwg] Background Geolocation for Progressive Web-Apps
Richard Maher
2016-12-01 23:53:22 UTC
Permalink
Cor, steady on Hixie, it wasn’t me yelling that “WHATWG is broken”. All I’m
trying to do is get someone (not me) to start development on a solution for
background geolocation in HTML5 Web Apps. Sorry if my post was in/pas
apropos.
all that matters is the quality of arguments and data presented
Excellent news! Here I go: -



Secure, user-sanctioned geolocation collection is currently unavailable for

HTML5 Web-Apps when they are not running or in the foreground. This leaves

the browser hosted applications incapable of competing with Native Apps on

an even playing field.



The main goal of background geolocation reporting is to allow all web-apps, but

in particular, Gaming, Social-Network, and Fleet-Management Apps, to

continue to function even if the device has gone to sleep or another App is

in the foreground.



Additional goals are:



- Power-Saving. By using the existing ServiceWorker paradigm and flexible

throttle/filter on which geolocation movements are "interesting".

- Single-process (Google Play etc) to monitor all geolocation reports for

all Apps before deciding if ServiceWorker(s) need to be instantiated.

- Unlike Mozilla's current implementation, stalkers, estranged spouses,

and marketeers will no longer be allowed to track users covertly.



My suggested solution: -



serviceWorkerRegistration.travelManager.subscribe({options. . .})



The "options" contain "filter" that can specify such things as minimum
distance traveled, minimum reporting interval, accuracy, maximum loiter
interval and so on. Once an "interesting" geolocation position change has
been obtained a ServiceWorker can be instantiated to process the event in
the same way that Push Notifications are handled today.


This is where it plugs-in: -

https://w3c.github.io/ServiceWorker/#extensibility



The following diagram that illustrates how shimlessly typical user
movements map to the ServiceWorker paradigm: -





Elapsed Time: tttttttttttttttttttttttttttttttttttt



User Travelling: P----P----P Stopped P-----P----P



Service Worker 1: --------------



Service Worker 2: ================



Now I find that argument compelling! How about you?



Cheers Richard
Karl Dubost
2016-12-02 01:41:06 UTC
Permalink
Post by Richard Maher
The main goal of background geolocation reporting
Previous related threads:
https://groups.google.com/forum/#!topic/mozilla.dev.geolocation/D5UXf-N3JfU
https://lists.w3.org/Archives/Public/public-geolocation/2016Feb/0016.html
https://lists.w3.org/Archives/Public/public-geolocation/2016Feb/0017.html
https://lists.w3.org/Archives/Public/public-geolocation/2016Feb/0010.html
https://groups.google.com/forum/#!topic/mozilla.dev.geolocation/UXkd3Tz1GPc
--
Karl Dubost 🐄
http://www.la-grange.net/karl/
Richard Maher
2016-12-02 01:57:11 UTC
Permalink
Post by Karl Dubost
Post by Richard Maher
The main goal of background geolocation reporting
https://groups.google.com/forum/#!topic/mozilla.dev.
geolocation/D5UXf-N3JfU
Chalk and Chees. But I do want wakelock functionality as well.
Post by Karl Dubost
https://lists.w3.org/Archives/Public/public-geolocation/2016Feb/0016.html
Since then the Geofencing API has died
Post by Karl Dubost
https://lists.w3.org/Archives/Public/public-geolocation/2016Feb/0017.html
Well worth reading
Post by Karl Dubost
https://lists.w3.org/Archives/Public/public-geolocation/2016Feb/0010.html
Yep
Post by Karl Dubost
https://groups.google.com/forum/#!topic/mozilla.dev.
geolocation/UXkd3Tz1GPc
Unrelated. I managed to get Chrome's implementation of the GeoFence API
canned and a wakeLock is not battery friendly and not secure except for
constantly foreground APPs such as navigation.

Loading...