Open RichardMaher opened 5 years ago
@anssiko Please flesh out the "minimum" in your MVP.
Given the current Geolocation now has big deprecation warnings on it can you please explain what additional functionality you plan to deliver with the sensor API V1.0? A rough guestimate of ETA of the spec (if not implementations) would also be useful.
Most importantly, can you please reference the decision to re-implement Geolocation as a generic sensor? W3C? IETF? Chrome? Edge? FireFox?
@anssiko
Note: Only the foreground operations were possible with [GEOLOCATION-API], the background operations are completely novel.
Yes, but everything novel appears to have been deferred to the too hard basket for V2.0. The architectural and functional design of the novel background ability will necesitate a foreground API re-visit if the ramifications are not placed front and center now.
The decision to adopt the Geolocation Sensor spec was made by the W3C Advisory Committee when it approved (Member-only link) the current charter on 29 Jun 2018.
Can you provide a brief redacted summary of the justification for this being handed to the generic sensors group? Was it a matter of financing and governance and reestablishing the Geolocation group?
What I'm really asking, did any copy the few files here and run the proof-of-concept? What alternatives to the Background Geolocation API surfacing as a sensor were considered?
@anssiko @romulocintra
For background geofencing we do not have any polyfill (since that'd be impossible).
Far from being impossible it is very doable. If you look at the TravelManager Polyfil it uses simple Service Worker Message events to simulate GPS readings. Very effective.
NB: A fundemental bed-rock design of the TravelManager is that the UA (or other lightweight" daemon) will do the GPS reading and filtering on behalf of all Background GPS clients. Do you plan the same or does your design have the client sensoring themselves?
Most importantly, which of the currently shipping sensors continue to function in the background?
It also couldn't hurt to see what Web Apps have to compete with: - competition
@RichardMaher First of all, Thank you for this prototype :) I've tried your code on chrome v79.0.3945.79 (Android) and it didn't work on background, only when the tab was focused. Did you test it lately?
It doesn't work in the background. It proves to browser vendors aht needs to be done to achieve this.
At present everyone needs to use Cordova/Phonegap for background geolocation and it's a bloody shame :-(
Cheers
On Thu, Dec 12, 2019 at 11:51 PM Yuval notifications@github.com wrote:
@RichardMaher https://github.com/RichardMaher First of all, Thank you for this prototype :) I've tried your code on chrome v79.0.3945.79 (Android) and it didn't work on background, only when the tab was focused. Did you test it lately?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/RichardMaher/Brotkrumen/issues/1?email_source=notifications&email_token=AB7BYAX5ADTCWSCUEVJIUI3QYJMXHA5CNFSM4GGE77T2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGXDJ6Y#issuecomment-565064955, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB7BYAXY73CQEEUS4FCJJODQYJMXHANCNFSM4GGE77TQ .
@RichardMaher I'm going to convert my PWA to TWA app.
@rajasimon
I wonder if that is enough to allow geolcation in the background to work. Would be great if it is.
Can you update this thread about the results after the conversion to TWA?
@rajasimon How did it work? Did you manage to get background location using TWA?
This is much needed. It's a shame Google and Apple lobbyists won't allow it so they can collect money thru their app stores.
@tomayac @jakearchibald you mean like what was described here a year and a half ago?