Mailing-List: contact callback-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: callback-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of agrieve@google.com designates
 209.85.214.175 as permitted sender)
MIME-Version: 1.0
Sender: agrieve@google.com
In-Reply-To: 
 <CADVgkyMj6wsZmLOq29JTMwrHcgpAdCOTKin_WDiJgB8twKaxKA@mail.gmail.com>
References: 
 <CAKP6k2vtGDHiZB8Ctv7hoBwHMt3tc+rJ406rE7AXj66CK2ZTsw@mail.gmail.com>
 <CCA35224.FD40%fil@adobe.com>
 <CAEeF2TcP9gZXNeAkE7tPccbzcDHmbnLSVKjb2dTOFzwtrnhp=w@mail.gmail.com>
 <CADVgkyMj6wsZmLOq29JTMwrHcgpAdCOTKin_WDiJgB8twKaxKA@mail.gmail.com>
From: Andrew Grieve <agrieve@chromium.org>
Date: Wed, 17 Oct 2012 13:59:58 -0400
Message-ID: 
 <CABiQX1WP8x_tkGCcKWp-3YHN1byGU2gCkByhphZ_0S8JWv49JA@mail.gmail.com>
Subject: Re: Notice: Notification of work on Notifications
To: callback-dev@incubator.apache.org
Content-Type: multipart/alternative; boundary=bcaec54d49a62b08fb04cc450b87

--bcaec54d49a62b08fb04cc450b87
Content-Type: text/plain; charset=ISO-8859-1

I think probably the best thing to do is to just always return false for
webkitNotifications.checkPermission() on iOS when the app is in the
foreground.

Any custom UI we attempt will likely not appease developers. Let them
implement their own in-app notification area if that's what they want.

If the app *is* in the background, then return true
for webkitNotifications.checkPermission().

On a related note, trying to implement a background app on iOS might be a
fun experiment. Maybe a music player?


On Wed, Oct 17, 2012 at 11:12 AM, Brian LeRoux <b@brian.io> wrote:

> Toasts are delicious but what would the iOS analog be? (Guess we could
> write a toasty impl for iOS which would be a cool feature.)
>
> On Wed, Oct 17, 2012 at 7:36 AM, Michal Mocny <mmocny@chromium.org> wrote:
> > Do we want to ignore notifications when app is in foreground (call
> > onerror), or use a different mechanism, like a custom growl/toast, or
> > something?
> >
> > Either way, since the w3c spec does not specify how to delay local
> > notifications or use push, there is nothing useful it can do on ios as
> > is.  I'll write some extension to schedule delayed notifications much
> > like the existing LocalNotification plugin, but use the w3c spec
> > wherever possible and with as much overlap with android as possible.
> >
> > Fun!
> >
> > On Tue, Oct 16, 2012 at 9:04 PM, Filip Maj <fil@adobe.com> wrote:
> >> I can.. ? Not sure what your point is.
> >>
> >> On 10/16/12 5:56 PM, "Jesse" <purplecabbage@gmail.com> wrote:
> >>
> >>>You can't ring your doorbell from inside the house either ...
> >>>
> >>>On Tue, Oct 16, 2012 at 5:50 PM, Filip Maj <fil@adobe.com> wrote:
> >>>>
> >>>>>>    - StatusBar Notifications: Intended for background services to
> >>>>>>notify a
> >>>>>>    user to start some action (instead of just doing the action
> without
> >>>>>>users'
> >>>>>>    explicit intent) -- so what does this mean for iOS without
> >>>>>>background
> >>>>>>    services?
> >>>>>
> >>>>>I *think* a fallback to local notification would be the way to handle
> >>>>>this. (But implementation will probably uncover better.)
> >>>>
> >>>> I think this is what tripped me up on iOS a few weeks ago when I
> >>>>attempted
> >>>> this myself :)
> >>>>
> >>>> On iOS, you _cannot_ dispatch a local notification (to the
> notification
> >>>> center / status bar area) if the app is in the foreground.
> >>>>
> >>>
> >>>
> >>>
> >>>--
> >>>@purplecabbage
> >>>risingj.com
> >>
>

--bcaec54d49a62b08fb04cc450b87--