Scenario:
Follow up of
So, let’s generalize this to use cases and not talk about how it would be done. Basically, a web app wants to be notified when it enters or leaves a geofence, right?
Yes, and also when the position changes like Geolocation.watchPosition
Ok, so, just noting that we’ve attempted to have discussion around this a few times and they’ve been sadly derailed (we’ve banned the individual who keeps poisoning it).
Nonetheless, browser makers haven’t been very enthusiastic about exposing this functionality to date. However, listing use cases and apps that would benefit from this would be great (or even discussing native apps that are successfully making use of this functionality), for when browser folks eventually get around to prioritizing this.
You can find some use cases here.
Some successful apps that could leverage this feature: Uber, Runtastic, smart home apps, everything for vehicle telematics industry.
Just to highlight and remind again what @jakearchibald wrote:
“To clarify, I’m referring [in saying service workers would not be well suited] to the kind of geo tracking that an exercise tracker would need. Geofencing is a different thing, and does kinda fit with service worker’s model.”
So summarizing, where Service Workers could work:
Geotracking, e.g., track a run and see an accurate GPS trace.
Geofencing, e.g., remind me to buy some milk when I pass by the supermarket.
The big use cases in my mind, would be fleet tracking, apps like fitness tracking, and even geo-caching. Those would be present day use cases. You could even include (these are from another users post on github) safety bulletin broadcasts. I think that we have the basics of what is needed from the GeoLocation API, we can get single points, or we can get a continuous stream of points. I think (Sorry this is getting more towards implementation than I wanted) we really just need a better way of consuming that data. Im not sure that ServiceWorker is the place to have it. Mostly because ServiceWorker will already handle the network side of things if we need to send data back to the server. What we need is something that will proces the data stream into more relevant events. I think the major problem to solve is the hurdle that is the word “Tracking”, and the perceived privacy implications.
ServiceWorker is an abstraction between the network and your app, it is not a catch all for processing background data. It has to be periodic event driven, and network related. Unfortunately GPS data is effectively NOT periodic. Its continuous. Now if there was a companion processor that broke down the stream into usable relevant events that ServiceWorker would then react to to say, cache a log, then I would agree. On the surface Ill agree that ServiceWorker is the closest to what we need for a background processor, but if we mangle it to fit this use case we will open a pandoras box that will end up with serviceworkers getting locked down by users and we are back to using appcache. You don’t want that do you?
@Richard_Maher To directly respond to your link and why tha’ts not fact, its because the link you presented, is to source developed by you to prove a point. It does not consider any alternatives other than what you have deemed as a best course of action. That’s like writing a paper and citing yourself as a reference. "You should believe me, because I believe me!" Hence me re framing it as opinion. Still valid, and worthy of consideration. But as opinion it invites discussion. As fact it ends discussion.
I would love to see the ability to define a resolution (distance delta and/or time delta) and have an event fire when those conditions are met. Its not a constant stream of position data, but a periodic stream, with predictable intervals (I want to know if the position changes by 5 meters or what position there is after 10 seconds) So we can track movement (Like fleet management), We know where the fleet was, how long it stopped and loitered, and what route it used to get from a to b.
@Richard_Maher I won’t brand you for quoting colloquialisms, I like to think I am more understanding than that, however I would prefer you chose one that had a parallel.
Ill look deeper when I get home from work, however, even in your code it references a mythical beast; “This module simulates the work that needs to be done by the UA or SW daemon in order to facilitate background geolocation on the web.”
It is precisely the SW Daemon that I would like to focus on. Since we have to define that, then we might as well do it right and not have preconceptions. I wouldn’t rule out that ServiceWorker might be a great place for part of it, but definitely not all of it, and I’m just not convinced that any of it fits. Despite the title of the proposal, I think there is a far more elegant solution yet to be found.
@Richard_Maher So I need to admit a confusion. Based on all my reading and conversations with others, I came to believe that serviceworker was not a good fit for geolocation… then based on your suggestion of reading the extensibility section, I decided to re-read the entirety of the spec, and I find this:
Service workers are generic, event-driven, time-limited script contexts that run at an origin. These properties make them natural endpoints for a range of runtime services that may outlive the context of a particular document, e.g. handling push notifications, background data synchronization, responding to resource requests from other origins, or receiving centralized updates to expensive-to-calculate data (e.g., geolocation or gyroscope).
Now I’m at a loss, if I am reading that paragraph correctly, it is explicitly noting geolocation as a service that serviceworkers are a natural endpoint. So at some point the spec writers believed that it was not only possible, but it would be a good fit. Im wondering what made them change their minds. @marcosc can you provide some insight? It would be helpful for shaping the continuing conversation?
You are correct, geolocation is out of scope for the generic sensor api. as it is a specialized sensor. Also I dont think that geolocation should be in the wake lock api. wake lock is something that a a geolocation process would use to maintain wake or cpu activity. I continue to look deeper, peeling off the the layers of the onion.
Collecting a number of use cases from (anonymized but real) partners:
Real Estate: Notifying you of nearby neighborhoods you’re passing that might fit your search criteria.
Retail: You have to be in a certain geofence to be eligible for various sales. Localized coupons. Connect the in-store experience. Let you know something you’ve looked at before is actually available for pick up nearby.
Travel: Automatic delivery of check-in experience once you’re in boundaries of hotel/airport. Last mile confirmation of location/check-in. Show venue specific data like WiFi passwords etc. only within geofence boundaries.
Ticketing: Notification with ticket QR/bar code once you’re in boundaries of event location.
Car Rental: Notification when you land at airport or approach rental facility with car pickup details.
Ride Share: Notification when your driver approaches the pick-up point.
(tried to delete :))
@Richard_Maher Good luck storming the castle!
I would suggest you look at the Geolocation Sensor API working group.
not the Generic Sensor API, the Specific Geolocation Sensor API. That would be the place to get a connection with serviceworker. They cant claim geolocation doesnt belong in a Geolocation Sensor API.
Slow and steady, @Richard_Maher. @tomayac list of use cases is a great start. Expanding on how those are currently solved in native apps would be really helpful.
I actually took time to read every single word in this thread. And it strikes me how complicated thing it appears to be, when it’s so easy in reality. Let me point out a few things guys:
Can’t we just make the spec for this and see it easily implemented in browsers (UA guys will more or less forward the events from the location managers and we’re good).