Re: Progress on Push API

Jonas wrote:
> One thing that I think would help the API would be to unify the
> "initial registration" flow and the "you need to reregister since the
> push server has lost track of your registration" flow. I.e. having a
> single API which lets the page check "do I need to register now".

Actually, the isRegistered method that Eduardo mentioned was intended to
behave this way, i.e. you would do:

// page onload handler
navigator.push.isRegistered().then(registered => {
    if (!registered)
        navigator.push.register().then(endpoint =>
sendToAppServer(endpoint));
});

Though I agree that registrationRequired would neatly save a little
boilerplate by removing the if(!registered) check*.

The PushError event meanwhile was intended to be delivered only to the
Service Worker not to web pages, and when the reason code indicates a fatal
error at the server requiring re-registration, it would give your webapp a
chance to re-register in the background (from the Service Worker) without
having to wait until the user next launches your webapp (or course it would
also work if your web page is still open).

In order for this to be possible, navigator.push.register (and friends)
needs to be exposed to Service Workers, but when used in the background it
would typically always reject unless hasPermission() == "granted" (since
UAs can typically only show permissions UI in the foreground).

Cheers,
John

*: (FWIW, isRegistered() in theory had a tri-state return value, where if
the promise got rejected instead of returning true/false it would have
meant that the UA doesn't know, perhaps because it can only check whilst
online or something - but in practice I suspect most UAs will cache
registrations locally, so perhaps we can just drop that state).


On 2 May 2014 06:18, Martin Thomson <martin.thomson@gmail.com> wrote:

> On 1 May 2014 17:31, Jonas Sicking <jonas@sicking.cc> wrote:
> >> If it's going to happen over and over, why not an event?
> >>
> >> function register() {
> >>   navigator.push.register().then(endpoint => sendToAppServer(endpoint));
> >> }
> >> navigator.push.onderegister = e => register;
> >
> > For two reasons:
> >
> > * If the page does some initialization asynchronously then it might
> > miss that the "deregister" event fires. I.e. it is very easy to
> > accidentally register the onderegister event handler "too late".
> > * It would require that we for each page that the user visits check if
> > that page has a registration, and if that registration has been lost
> > by the server. We only want to do this on pages that care about push
> > registration and is actually going to make a registration if needed.
> > Not for every page the user visits.
>
> Fair points, but with a an event coupled to a state (attribute boolean
> registered), this can be avoided.  I guess that the point of your
> second proposal at least is that it sort of rolls all that into the
> one package.
>
> I think that I prefer the "registration needed callback" approach,
> even though it seems to be a little surprising in the sense that it
> shares many characteristics with events.  Maybe a onregistrationneeded
> event would be a closer fit.
>
>