This Feature Request is to gauge WebKit's interest in implementing the ServiceWorkerRegistration's TravelManager interface (https://github.com/RichardMaher/Brotkrumen), aka. "Background Geolocation". The demand for such a feature is self-evident with Web DEVs in areas such as https://github.com/w3c/ServiceWorker/issues/745 The business/user requirements are well known and have given rise and popularity to plugins such as Phonegap Ionic. We *need* thyis functionality in Native PWAs!
Looks like the standard request had been rejected and now it's being tracked as a part of https://github.com/w3c/geolocation-sensor/
(In reply to Ryosuke Niwa from comment #1) > Looks like the standard request had been rejected and now it's being tracked > as a part of https://github.com/w3c/geolocation-sensor/ Where did you hear/see that the TravelManager had been rejected? What *is* happening is that @w3c refuses to debate a demonstrably fit-for-purpose solution and instead intends to merely duplicate current watch/get location functionality in the form of a "sensor" for reasons only know to themselves. Whatsmore they acknowledge that the current GeoLocation API will not be deprecated and will continue to be supported and there is no benefit to be obtained to switching to the new API until a mythical version 2 when presumably someone will begin to ponder how to implement a battery friendly solution that I will take great pleasure in pointing out the faults in just like I did the abandoned geofence implementation in Chrome. But we don't have *another* 3 years to waste on this so please Ryosuke let me ask you what is wrong with the proposed TravelManager solution? What use case(s) does it not support? I beg you to then tell me why a workable, battery friendly, solution based on proven ServiceWorker extensibility has been ignored for 2 years. Go ahead, ask them what the alternative is!
(In reply to Richard Maher from comment #2) > > But we don't have *another* 3 years to waste on this so please Ryosuke let > me ask you what is wrong with the proposed TravelManager solution? What use > case(s) does it not support? To me, the biggest question isn't so much whether this doesn't support some use case but rather exposing background geolocation to a website is ever acceptable in terms of privacy at all. Ordinary users don't really understand the implication of allowing websites to get geolocation information in foreground, let alone in background. Furthermore, keep running websites in background while the screen is turned off is not something WebKit supports on iOS so there is also a practicality issue. I'm going to start a discussion internally at Apple.
> To me, the biggest question isn't so much whether this doesn't support > some use case but rather exposing background geolocation to a website > is ever acceptable in terms of privacy at all. I agree %110! Lots of work to do here but some ideas already suggested: - https://github.com/w3c/ServiceWorker/issues/745#issuecomment-183159534 Sadly that thread is over 3 years old and parts outdated but it contains everything you want to know about Geolocation demand, W3C recalcitrance, and why Google Geofencing died. (And you have an hour of your life you never want to get back :-) > Ordinary users don't really understand the implication of allowing > websites to get geolocation information in foreground, let alone in > background. Again I agree, but these are Manifest driven. installable [P]WAs. > Furthermore, keep running websites in background while the screen is > turned off is not something WebKit supports on iOS so there is also > a practicality issue. One advantage of the TravelManager design is *nothing* except the UA has to be running in the background until an "interesting" GPS reading is detected! Safari would listen/filter GPS readings and, when necessary, see if it needs to start a ServiceWorker or deliver a TravelEvent to an existing ServiceWorker. The ServiceWorker can then decide to foregrouound the APP (and/or pop up toast about background tracking) or, Far more likely, just send an travel update to the server who in turn can decide if a PushMessage is required. Anyway thank you for engaging. Please feel free to mail me direct on maherrj@hotmail.com. I'm just worried about being blocked. Again :-(
Sorry that should've been maherrj@gmail.com Also happy to email my mobile# if it helps. Please also acknowledge that the Background Geolocation conundrum is not unique to Web Apps. I assume quasi web Cordova/PhoneGap/Ionic solutions as well as native background tracking Apps appear in the iStore. NB. Another bonus of the TravelManager solution (at least on Android) is that the UA process(es) is able to defeat (too strong a word) mitigate the impact of the GPS throttling at the OS level when Apps are backgrounded. The Min-Interval, Min-Distance etc configuration can be restricted to the Web-App but received at full-throttle by the UA.
Just looked up your page https://rniwa.com/about/ and appeal to your love of "empirical evidence". The Brotkrumen Web App is not based on any cult of personality such as Jake Archibald's pronouncement that "Pretty confident the service worker isn't the place for doing this." or "They're designed to wake up for an event, briefly handle it, then go away.". It is also not based on Alex Russel's dictate that "Not an issue appropriate for this [Service-Worker] repo. Closing.". What Brotkrumen *proves* with empirical evidence is that the Service Worker paradigm is the natural fit for background geolocation by reporting the very favourable ratio of Service Worker instances to geolocation readings over typical journeys be they car, bike, walk! What has the opposition, narcissistic, star chamber been able to show you to back up their claims??? "WE OUGHT NEVER TO ALLOW OURSELVES TO BE PERSUADED OF THE TRUTH OF ANYTHING UNLESS ON THE EVIDENCE OF OUR OWN REASON" Could not agree more! But that's not how W3C works :-(
Just read an update on iOS 13 and it seems Apple has already sorted most of the permissions issues! Hope they get standardized. 1) A new feature that lets you give an app permission to track your location just once, rather than saying it can track you in the background forever. 2) New notifications and icons also let you know when apps are monitoring your microphone, or want to use Bluetooth to connect to other devices. To me, at least, it looks like Apple has already done the heavy lifting on when/how to obtain permissions and also permission-status visibility. Do you agree @Ryosuke?
+1