On Wed, Oct 17, 2012 at 1:59 PM, Andrew Grieve <agri...@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 <mmo...@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 <f...@adobe.com> wrote: >> >> I can.. ? Not sure what your point is. >> >> >> >> On 10/16/12 5:56 PM, "Jesse" <purplecabb...@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 <f...@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 >> >> >>
