Re: Geofencing API - next steps?

Yet another background GeoLocation Use Case example that the spec continues
to completely ignore: -


On Wed, May 25, 2016 at 10:29 AM, Ruben B <> wrote:

> Hi,
>
> Sorry for my english but i'm french. I'm founder of a meal delivery
> startup.
>
> I recently read yours messages on Github about geolocation web worker
> issue So first congratulation for your fight in discuss, i loved yours
> posts.
>
> I have exactly the same problem. I developed a web app for my delivery
> cyclists, this app permiss to manager orders and geolocate bikers to send
> position to a tracking web page for customers.
> The app works so great, I' m really proud of me because i'm not a real
> developper but a coding passionate and exactly like you i'm very
> disappointed by fact of locking phone or just switching tab or minimizing
> browser will stop execution script and geolocation update obviously.
>
> I saw in yours messages that firefox allow watchPosition() in background,
> but after research i saw that's only on firefox OS. So i don't know what i
> can do, i love use web app for many reasons, and i don't want create a
> native app only for that.
>
> The only solution i found for moment it's to use noSleep.js,
> https://github.com/richtr/NoSleep.js , a kind of polyfill of firefoxOS
> function wakeLock();
> But obviously this solution sucks because smarphone will be on untill all
> time of delivery and battery will be terribly decrease.
>
> Did you find another solution ?
>
> Thanks in advance and if you want exchange about dev or business, i would
> be really happy.  :)
> --
> Ruben
> Founder
> eatforlife.fr
>
>
I pointed out to Ruben that FireFox is currently the only browser that
continues to track location in the background and he seemed happy.

The sheer irony of Mozilla staff prohibiting here what FireFox exploits out
there appears lost on most. Absolutely *no* background-tracking permission
required and absolutely *no* visual, audible, or tactile cues that the user
continually is being tracked even when FF has been backgrounded. Disbelief!
(Google recently changed Chrome to prohibit just such unauthorized
behaviour. But then their motto is "Don't be evil")

Try it yourself: -

<!DOCTYPE html>
<html>
<body>

<p>Wait 5 secs.</p><br />

<p id="out"></p>


<script>

     function success(position){

var x = document.getElementById("out");
x.innerHTML += position.timestamp+" GPS "+Date() + "<br />";
 }

     function failure(error){
var x = document.getElementById("out");
x.innerHTML += error+" Error "+Date() + "<br />";
 }

document.getElementById("out").innerHTML = "Start "+Date()+"<br />";
if (document.addEventListener){
document.addEventListener("visibilitychange", function() {
var x = document.getElementById("out");
x.innerHTML +=  document.visibilityState +Date() + "<br />";
})
} else {
document.attachEvent("onvisibilitychange", function() {
var x = document.getElementById("out");
x.innerHTML +=  document.visibilityState +Date() + "<br />";
})
}

    setTimeout(function(){
var x = document.getElementById("out");
x.innerHTML += "Timeout "+Date() + "<br />";
}, 5000);
trackerId = navigator.geolocation.watchPosition(success, failure, {
enableHighAccuracy: true
});

</script>

</body>
</html>

On Fri, May 20, 2016 at 8:42 AM, Richard Maher <maherrj@googlemail.com>
wrote:

> or . . .
>
> c) Continue to work withe the ServiceWorkers Working Group
> https://github.com/slightlyoff/ServiceWorker/issues/898 on a standard for
> implementing
> navigator.serviceWorker.registration.travelManager.subscribe(options) so
> that GeoLocation can continue to be tracked while the WebApp is in the
> background in an efficient and battery-friendly way. A TravelEvent will be
> delivered from the User Agent (or optimized to a more lightweight ambient
> OS specific daemon such as Google Play) once an interesting location change
> has taken place. This TravelEvent suffices to instantiate a ServiceWorker
> that in turn could spin up a browser and/or tab. "Geofencing" is simply 20
> lines of Javascript on top or, far more importantly, something that can be
> delegated to the Application Server and subsequently PUSHed to interested
> parties.
>
> The case for GeoLocation being just another Generic Sensor has yet to be
> made let alone proven. I personally can see the argument but then why have
> a PushManager when a "MessageMailbox" could be just another sensor? Why
> have DateTime, Interval, and Timeout when you have a Clock sensor?
>
> Why make everything look like a nail 'cos all you want to use is a hammer?
>
> Cheers Richard Maher
>
> On Thu, May 19, 2016 at 10:31 PM, Mandyam, Giridhar <
> mandyam@qti.qualcomm.com> wrote:
>
>> As per the announcement below, I am not aware of any pending
>> implementations of this API.  Given the need for interoperable
>> implementations in order to progress a specification along the W3C
>> standardization track, it does not seem to be possible to move forward with
>> this specification as is.
>>
>>
>>
>> I am sending this message as an open call to the group to see if there is
>> any interest in continuing to work on the specification as it currently
>> stands.  Particularly for browser vendors, if there is expressed interest
>> in continuing the work please also state implementation plans.
>>
>>
>>
>> If there is no expressed interest, then the following steps are possible:
>>
>>
>>
>> a)      Transition the existing API to a W3C Note.  This is essentially
>> a parking space for a standard that did not achieve completion but could be
>> picked up again in the future if there is interest and need.
>>
>> b)      Start working with the Devices and Sensors Working Group on
>> supporting Geofencing use cases as part of their Generic Sensor work.  Note
>> that Marijn has raised this issue already
>> https://github.com/w3c/sensors/issues/73.
>>
>>
>>
>> I thank Marijn for his efforts on the specification.
>>
>>
>>
>> If there are no responses to the mailing list by May 27, 2016, 11:59 PM
>> US Pacific time, then I will assume that there is group consensus for the
>> next steps as proposed.
>>
>>
>>
>> -Giri Mandyam, Geolocation Working Group Chair
>>
>>
>>
>> *From:* mek@google.com [mailto:mek@google.com] *On Behalf Of *Marijn
>> Kruisselbrink
>> *Sent:* Wednesday, May 11, 2016 11:40 AM
>> *To:* public-geolocation@w3.org
>> *Subject:* No longer working on Geofencing API
>>
>>
>>
>> For quite a while now the geofencing API hasn't been much of a priority
>> for us. Now in addition to that we're no longer convinced the geofencing
>> API in its current shape is the best way to address the use cases we're
>> interested in addressing. So with that in mind we've decided to stop work
>> on the geofencing API in its current form.
>>
>>
>>
>> Marijn
>>
>
>

Received on Thursday, 26 May 2016 00:33:18 UTC