incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Braden Shepherdson <>
Subject Re: [Android] Notifications and singletop
Date Fri, 24 Aug 2012 17:16:44 GMT
I don't know enough about those platforms to say. I can do that research
next week if people think it would be valuable.

I can say, personally, that I actually came to Cordova with a personal
webapp some months ago, hoping to do notifications and maybe even Google
Cloud Messaging push notifications, but found that it's not core and got
lost in all the plugins. Having at least local notifications would be good.

As an update, I've also done enough research to determine that there's no
way on Android to call onclose events properly, since Android doesn't
notify apps when the user dismisses their notifications. There's even a
feature request filed for that, but no word on it.[1]

I'm working on bringing the API in line with the spec. I will of course
document that Android quirk of no onclose. I'll also put the singleTop part
into the documentation, not the code.



On Fri, Aug 24, 2012 at 12:53 PM, Simon MacDonald <
> wrote:

> Hey Braden,
> I think fixing the notification plugin for Android is a good idea. I
> wouldn't change the default android:launchMode, I'd just modify the plugins
> readme to mention to the implement how they can do it themselves.
> As for implementing the W3C API we try to adhere as close as possible to
> the standard. Obviously there is an analogy to notifications on iOS as they
> stole it from Android but does it map to Windows and BB? Just wondering if
> this is something that could eventually end up in core.
> Simon Mac Donald
> On Fri, Aug 24, 2012 at 10:39 AM, Braden Shepherdson <
> >wrote:
> > Several related questions, here.
> >
> > First, I'm dusting off and fixing up the LocalNotification plugin for
> > Android. I've got it working to show a notification with sound/vibration
> > now.
> >
> > However, there are several problems. Tapping the resulting notification
> > doesn't load the app, which is a bad UX. Trying to change the handler so
> > that it does load the app is a problem, because Android by default loads
> > the Activity for a notification tap as a separate instance from any other
> > running copy of the app. That has obvious problems for a Cordova app.
> > There's an Android <activity> parameter 'android:launchMode' that changes
> > this behavior.[1]
> >
> > Setting launchMode to singleTop changes that behavior so that it won't
> > create a new instance if one already exists with the target Activity on
> top
> > of the stack. Since a Cordova app typically has only one Activity, this
> > should accomplish the goal. Are there any objections to my setting this
> as
> > the default? Or should I just add that to the plugin's instructions?
> >
> >
> > Somewhat related, there is a W3C spec for Notifications[2]. Its paradigm
> > fits well with Android notifications, and so using it for this seems
> > desirable. The current API (and the underlying Android code) provides the
> > ability to schedule the notification to occur at some future time, and to
> > recur.
> > The W3C API doesn't support that, but does support four events: click,
> > show, close, error. Android should be able to return all of these, with
> the
> > possible exception of close. Presumably that would fire when the user
> > dismisses the notification without looking at it, which I'm not sure if
> > apps are notified about.
> >
> > I see three options:
> > 1) Leave the nonstandard API in place.
> > 2) Port to the W3C spec API.
> > 3) Extend the W3C spec to allow extra options about scheduling and
> > recurrence.
> >
> > I'm leaning towards (3) but I'm wondering what others think. What is the
> > usual approach to the standard APIs here?
> >
> >
> > Braden Shepherdson
> >
> > [1]
> >
> > [2]
> >

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message