W3C home > Mailing lists > Public > public-geolocation@w3.org > September 2014

Re: Geofencing alternative proposal

From: Martin Thomson <martin.thomson@gmail.com>
Date: Fri, 19 Sep 2014 08:31:07 -0700
Message-ID: <CABkgnnU4NE2PB1iHArZTw7dJOEVQO5Rn2OO6C1tabpdSsh-KOA@mail.gmail.com>
To: Marijn Kruisselbrink <mek@google.com>
Cc: public-geolocation@w3.org
On 18 September 2014 10:27, Marijn Kruisselbrink <mek@google.com> wrote:
> Can you give some sample code how this would look like with your API? I'm
> not quite following how it could. So the browser would "wake up"
> (essentially load from scratch) a service worker, and would then have to
> somehow wait for the service worker code to install event handlers on the
> right geofences? But to get to a GeolocationFence object it would need to do
> possibly asynchronous API calls, so it's not clear to me how this waiting
> could work.

A service worker runs the code in the "install" event when it is
awoken, during which time you would have to register handlers for
global events.  The only difference with having specific registrations
is that you would have to force the install event to wait for the
promise:

this.addEventListener("install", e => {
  e.waitUntil(
    this.geolocation.geofence.getRegistrations().then(fences => {
      fences.forEach(fence => { fence.onenter = handleEnter; });
    })
  );
});

This (e.waitUntil) is a standard feature of service workers.
https://slightlyoff.github.io/ServiceWorker/spec/service_worker/index.html#wait-until-method
Received on Friday, 19 September 2014 15:31:39 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:51:09 UTC