incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon MacDonald <>
Subject Re: [Android] Notifications and singletop
Date Fri, 24 Aug 2012 16:53:24 GMT
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