Fetch user location as background process

[marcveens]

Figure out if it's possible to fetch the user's location as a background process.

Goal: We would like to send a user messages based on their location and time.

[marcveens]

Seems that it's not possible to fetch location using a service worker, see w3c/ServiceWorker#745.

There is a specs draft by W3C, but it's written in 2016 and no longer maintained: https://w3c.github.io/geofencing-api/.

There is a still active proposal for Geofencing in a PWA, but still no outcome: https://discourse.wicg.io/t/proposal-expose-geolocation-to-service-workers/2588/30.

There are a few alternatives:

• Jake Archibald (one of the designers of the ServiceWorker) suggests to look at https://w3c.github.io/wake-lock/. This should keep the page alive, not by using a ServiceWorker. Support seems to be poor. Needs more research
• Keep track of user location and time on the website everytime they open it. For example: User opens website at 8:00 at location A and opens it again at 12:00 at location B. We already know the time in between the 2 actions, for distance we have two options:
  • Calculate the approximate distance as the crow flies (hemelsbreed) (Not very accurate)
  • Calculate a more precise distance using a geoservice (by Google Maps API or another service) (Accurate, slower to fetch, might have to be paid for)
    Based on this data we know how long someone has been on the road.
• Create a hybrid web app in order to use Geofencing, which is supported natively: (https://ionicframework.com/docs/native/geofence/) (This is probably the worst solution of all, since we want a PWA)

[marcveens]

I've done some research on getting the distance between 2 geolocations:

• Google Maps offers a Distance Matrix API (https://developers.google.com/maps/documentation/distance-matrix/intro). Unfortunately it's a pricey service, 5 dollars per 1000 requests. Since it's Google the service would probably be very accurate.
• An open source alternative is OSRM (http://project-osrm.org/). It can be used as host-your-own service (it's C++ though) or as a hosted service. The hosted variant seems to work allright but is fairly unstable, see http://router.project-osrm.org/route/v1/driving/13.388860,52.517037;13.397634,52.529407. Once in a few requests you get the "Too many requests" error.
• Haversine is a mathematic formula which can calculate the distance between 2 geolocations. It doesn't require an API request but it's a little less accurate. There is an NPM package available: https://www.npmjs.com/package/haversine. Online calculations can be done here.

I've compared the Haversine accuracy with the OSRM service:

• Short distance (from Macaw (52.2909792,4.7004547) to Schiphol (52.311872, 4.760534))
  • Google Maps: +/- 7000m
  • OSRM: 7538m
  • Haversine: 7073m
• Long distance (from Macaw (52.2909792,4.7004547) to the Eiffel Tower (48.8583736,2.2922926))
  • Google Maps: +/- 506km
  • OSRM 506km
  • Haversine: 465km

[marcveens]

I now have 4 fetch options:

enum LocationSource {
    PREDEFINED = 'predefined',
    MANUAL = 'manual',
    VISIBILITY_CHANGE = 'visibility_change',
    PAGE_LOAD = 'page_load',
}

• Predefined: This is set from code. Actually only for test purposes
• Manual: When a user clicks the "Fetch my location" button
• Visibility_change: Triggers automatically when a tab is active again after being inactive. This also triggers when a PWA is opened again after a "soft-close"
• Page_load: Quite obviously after a page load. Is also triggered when a PWA opens again after a "hard-close"

[marcveens]

LocalStorage limitations
Since we're storing all of the location history records in LocalStorage we have to take into account that LocalStorage has a size limit. This article at Sitepoint tells us that the least maximal size is 2MB at Android Browsers.

• Currently I have 5 items in my localStorage. Size: 1.83 KB. For easy calculations, we make it 2KB.
• This means that we can have 5x500x2 = +/- 5000 items before we have to delete old records.
• Of course this is based on the current model we're saving. Every extra property costs more disk space.

Do we actually need (and are we allowed) save an entire history of locations of a user? Perhaps 50 records is more than enough?

[RichardMaher]

Just curious if my proposed solution here is exactly what you're looking for? If not, why not?

Your visibility_change and Page_load options miss huge tracts of the journey leaving the resulting distance calculation unreliable (Circles, back-tracking, diversions, stopped etc)

See this for more.

Cheers Richard

[marcveens]

Thanks for your interest :)

I'm trying to understand your solution but I'm not quite getting it yet. As I understand right now the only way you fetch the location is by client JS just like we do, right? What is your SW doing in order to fetch the location?

Unfortunately I'm not able to add your page as a PWA since the SW doesn't seem to register..

[RichardMaher]

Yes Marc that is the current restriction. What my Polyfill proves is that IF the Browser Vendors OR W3C/IETF implemented the proposed solution, what wouldn't it solve? Why are you not asking W3C/IETF to formalize the TravelManager specification???

Just "Add to homescreen" to register Brotkrumen. Once again Google Lighthouse and the inner sanctum have chosen to dictate rediculous barriers to becoming an official PWA :-(