incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Braden Shepherdson <>
Subject [Android] Notifications and singletop
Date Fri, 24 Aug 2012 14:39:27 GMT
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

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

I'm leaning towards (3) but I'm wondering what others think. What is the
usual approach to the standard APIs here?

Braden Shepherdson


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