W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2014

RE: Push API and Service Workers

From: Jake Archibald <jaffathecake@gmail.com>
Date: Tue, 21 Oct 2014 17:01:40 +0100
Message-ID: <CAJ5xic8mC=9MDLLf-uv+9R5yRgaXoom3iA7M4aLEqu2nK_e2Lw@mail.gmail.com>
To: Shijun Sun <shijuns@microsoft.com>
Cc: Webapps WG <public-webapps@w3.org>, Domenic Denicola <domenic@domenicdenicola.com>, Jonas Sicking <jonas@sicking.cc>
On 21 Oct 2014 16:53, "Shijun Sun" <shijuns@microsoft.com> wrote:
> On Monday, October 20, 2014 9:42 AM, Jake Archibald wrote:
> >Things I guess you'd do as a result of a push message:
> One of the most typical scenarios is
> * show a toast notification (e.g. for a new email)
> * user chooses to dismiss the notification, so not to read the email
right away
> That is it.  From the power efficiency perspective, the browser itself
doesn't have to always wake up to process the push message.  It should be a
decision by web developers whether the message should be handled explicitly
by the service worker every time it arrives.

To reiterate from my previous message:

Updating caches should be common, and it's something most native apps get
very wrong. Take Twitter for example, I can tap a notification that shows a
partial tweet, but I have poor/no connectivity so the full tweet doesn't
load. The notification is now gone, so I'm left with less information than
I had before I tapped the notification. Twitter should download and cache
the full tweet before showing the notification.

Taking the email example specifically, the gmail app does the right thing.
Not only do you get a notification, but the email is also cached for
offline viewing so tapping the notification works regardless of
connectivity at moment of tapping.

This is exactly the wrong time to guess what high-level things developers
want to do and build APIs to do those imagined things.
Received on Tuesday, 21 October 2014 16:07:48 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:31 UTC