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.
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:
- PWAs are meant to compete with native apps (not only on mobile devices!), so they should and will provide more and more access to the native APIs. Geolocation is one of them.
- Users already use apps which track geolocation in the background, they want to use them, they’re happy with them. We ask for permission, they grant it or not, they have a little icon in the status bar. Everyone happy.
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).
FYI, I’ve banned @Richard_Maher from our discourse for repeated code of conduct violations.
If he returns under a different alias (which he tends to do), please let me know.
Please refrain from engaging with him on Discourse or standards discussions.
I’ve also deleted @Richard_Maher posts, as they are just noise.
Apologies to participants in this thread for not taking action sooner. This individual has been trolling our community for a long time, and, despite numerous pledges from him to behave - or claims that he will go away, he keeps coming back.
I’m not sure if i should add this here or in a new post, but i also feel the need to use some of the functionality requested here, in particular the access to the geofencing api. The main goal is to use the device location services in a practical and battery-efficient way.
Here are some scenarios that i can think of:
an airline app can define a geofence around an airport when a flight reservation is near boarding time. When the device crosses the geofence, the app can send a notification that takes users to an activity that allows them to get their boarding pass. (taken from google geofencing api)
Travel guide assistance - Could define multiple interesting areas around a city, accordingly to the user interests, and warn users when they are entering or leaving that area of interest.
The other use case can be in sport area. Like paragliding where the participants should be tracked and scored. The location should be tracked every 3 second and send to the server when network is available and it is better to be send LIFO (last in first out) so the server knows the last location as soon as possible to show it to the spectators on the web site. Also the server must care about, the rules (where to go and where not to go), the safety (where was the pilot lately if she/he is missing) and at the end of competition to collect them from about 60 km wide playing field with designated vehicles, the server must track the vehicles as well. One more thing, the altitude is also important, not only lat/long.
The spec might be like to register to get the location every 3 seconds / every 10 meter, and the user get a permission box to allow or not. And the service worker get a location changed event every 3 seconds / every 10 meter.
Two use cases that are perhaps a little left of field but I think are important.
Museum content based on geofences that represent different exhibitions. Research in the area of museums and other cultural orgs has shown that their apps tend to go un-used whilst their websites are visited regularly. As the web is challenged by native apps there is an opportunity in the cultural space to maintain dominance. In cultural spaces you tend to react to where the user is or what they are seeing to cue different experiences and content. Being able to access GeoLocation via SW would give developers in this space one less reason to have to build a native app.
Festival content based on geofences that represent different festival stages/performances areas. Useful via SW because you could send notifications as people pass locations - especially useful for events that span entire cities.
Art installations/web art. As the world of digital art continues to explore having more APIs available to web artists and creative coders will unlock artworks that cannot be created by other means. Artworks need to capture an audience quickly and instantly - asking a user to download an app before viewing an artwork doesn’t lead to much usage for the same reasons museums have issues (see link above).
It is anecdotal, but all 3 of the above instances have lead me (or the companies I’ve worked for) to have to pursue native apps just for geofencing capabilities (even though for many other reasons a PWA would have been better).
I was under the impression that SW could use geolocation?
OTOH, these use cases are great reasons that browsers should be not only aware of the device location but also the location of other geographic features, so that it can do reasonable things, possibly including geofencing.
This is one of the things we’re trying to accomplish with Map Markup Language. https://discourse.wicg.io/t/map-markup-language/1267/4
There is some stuff that could have been editied out because it is inappropriate noise, but as far as possible it is helpful to have the other stuff available.
This space has very low tolerance to abusive behaviour, as we believe that inclusivity towards abusers results in excluding others. It is not the chairs’ role to edit out the poison while trying the guess whatever substantial contribution was intertwined in it. If someone has something valuable to say, they can say it without demeaning others.
First off, I just wanted to say thank you for the patience of those who not only read the associated material relating to the topic but also keeping a professional and open mind through the associated noise. I’ve been aware of the general problem for over a year now. Knowing our own customer requirements and potential future features which surround this topic. Generally I was hoping that some solution would have been proposed by now however this has not been the case.
With this in mind I would like to state what I believe to be the general high-level use-cases and the constraints of the problem:
- A wishes to inform B of an event within a given geo-spatial area
- A wishes to know that B is within a given geo-spatial area
- A wishes to know where B is
The primary constraint of the above is that A would be (or proxied by) a server and that the requirements apply when the user does not have the application in the foreground. The secondary constraint is that the above be also applicable if the application was installed and neither in the foreground or background.
Examples of specific user stories have been given however as demonstrated in the Wake Lock API proposal (http://w3c-webmob.github.io/wake-lock-use-cases/) there is a lack of direct references of Applications. Personally I do find it a little frustrating that to have an idea considered, you must demonstrate it being done somewhere else - however I’ve worked with customers where we must do exactly that so it shouldn’t be too unexpected.
With note to the Wake Lock API proposal - some use cases would be covered by that proposal however the conditions of such API listed below would not make the API suitable for others from a user experience perspective:
- The application would have to be initially loaded to the Foreground before being applicable.
- The application would still run the full UA application and accompanying resources (when using System lock).
The key I believe that distinguishes this proposal is that activity occurs in the background instead of within the primary UA loaded application. As such the considerations I think apply to moving the proposal forward are; performance, activity, security and simplicity.
- Performance relates to the consumption of resources - this is the primary reason I don’t believe Wake Lock API is appropriate for this use case. The consumption of minimal resources as possible and the acceptance of system throttling.
- Activity relates to use of frequency of processing and the use of network resources. Network requests consumes user bandwidth (costing user money) and a bad example of usage would be continuously sending position updates to the server.
- Security relates to user awareness of the activity, integrity of the source of the activity (the application), and control of such activity.
- Simplicity relates not only to implementation but usage by developers.
What I believe this proposal shouldn’t be is:
- A general background process service (ie. More Service Worker rather than Worker that runs in background)
- An extension of the standard application logic (the UA application is not running)
With the above, I believe the scope of the proposal should be something more like:
- This only applies to PWA Installed applications (requiring applications to satisfy the requirements of such installation and the use of Service Workers). Standard GeoLocation API is available to foreground applications and standard web clients shouldn’t behave differently to the standard browser experience - it must require active user installation to be available.
- A dedicated permission to have access to geo-location data within the background. This permission must then be requested when the user installs the application (or after update for applications already installed). Apple already have this kind of permission (https://support.apple.com/en-gb/HT203033) and the application should assume Denied until explicitly given. The user Must be able to Deny/Approve the permission on the application after the initial request.
- There needs to be a distinction between passive usage and tracking, and that the user can understand and approve/deny such usage. The above permission allows the application to monitor the users position - I believe the user should have a separate permission for forwarding that position back to the server.
This indicates the following elements for a possible concept design:
- The concept of a Service Worker could be reused for the location processor - GeoLocation Service Worker. It operates as a background service and mirrors the same conditions of use/activity as the existing Service Worker - only handling Position Update events from the native location services.
- The GeoLocation Service Worker can be referenced from the Service Worker.
- Push Notifications extended to provide a Geo-Spatial area (simplest being a radius based area) and provide the ability to only continue processing the notification if the user is within the geo-spatial area (without telling the service worker user code the position directly). This covers the 1) high level use case of “A wishes to inform B of an event within a given geo-spatial area” using Push Notifications.
- API extension to the Service Worker to allow subscription to events from the GeoLocation Service Worker providing Position Updates. The subscription should be heavily throttled but could support bulk values (ie. current position + position track since last update). This covers 2) and 3) of the high level use cases as the application code can send network requests to the server with the position data.
I deliberately ignored the permissions gates in the above concept as that would have to be carefully considered in a proper design, alongside what should be done in scenarios where the location is denied or unavailable. This was just provided as thoughts to contribute to the discussion.
From a personal perspective - considering existing implementations, I would like there to be consideration about offering the ability for the user define periods of usage. This is more along the how mail applications sync and do-not-disturb features can be scheduled on Android. From a business employee application perspective the user would be expected to allow the service as required by their Standard Operating Procedures. However for standard consumers this could give a nice level of control to allow when the application can track you. Speaking from personal experience, I was frustrated (and quickly uninstalled after) a fitness tracking application that continuously tracked my location all the time - there was no limitation to when I was actually doing my cycling, it was all the time. Providing this personal control would be a nice addition.
Thank you for reading and I hope this has contributed to the discussion. Below I’ve added some examples of existing applications I’m aware of that have some of the use cases described.
- Moves (owned by Facebook prior to shutting it down) - Fitness Tracker
- Use case 3)
- Why: It tracked users to monitor fitness activities (walking/cycling etc.)
- Benefit: User had collated data on distances and estimated calories burned. This was meant to provide feedback on there fitness activity and provide motivational support.
- Negative: User couldn’t control when the application was tracking and subsequently affected battery performance
- Dark Sky - https://darksky.net
- Use case 1)
- Why: It tracks users location to inform them of appropriate weather warnings via push notifications
- Benefit: User receives notifications of relevant weather updates for their current location without continuously monitoring an active application.
@JaiOwl, thanks for your input. This topic has graduated from incubation and the work is now underway in the Devices and Sensors Working Group. You can help by reviewing the Geolocation Sensor use cases that consider both foreground and background operations enumerated at https://w3c.github.io/geolocation-sensor/#use-cases and submit feedback via https://github.com/w3c/geolocation-sensor/issues