incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michal Mocny <mmo...@chromium.org>
Subject Re: Notice: Notification of work on Notifications
Date Wed, 17 Oct 2012 18:22:43 GMT
On Wed, Oct 17, 2012 at 1:59 PM, Andrew Grieve <agrieve@chromium.org> wrote:
> 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.

I assumed permissions is checked only once, so I don't think the value
returned here should be changing outside of first prompt/app refresh.

>
> 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.

Fair enough.  I'm going to punt this problem for now, mostly because I
want to get the lower hanging fruit first.  Can evaluate the issue
later based on developer needs.

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

If it is in the background, this check could never execute.  There
*is* apparently some temporary time period where ios apps actually can
run in the background, I am not aware of all the rules, but I just
don't think that is sufficient to worry about (Perhaps this explains
it: http://developer.apple.com/library/ios/#DOCUMENTATION/UIKit/Reference/UIApplication_Class/Reference/Reference.html
-- beginBackgroundTaskWithExpirationHandler).

Perhaps we can allow notifications in response to having the app
closed? I'll look into that..

>
> 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
>> >>
>>

Mime
View raw message