I think the only place sticky channels are used is for startup events (deviceready, nativeready, pluginsready, etc). I think you could probably change them to fire multiple times without breaking too much, but the semantics of that seem really strange to me (fire the most recent event, or all events? upon registering, but only to the newly added listener(s))
They are not based on any standard, so it might be nice not to use them, and instead use standard events (e.g. cordova.fireWindowEvent). As long as we promise not to fire them until after deviceready, apps should be able to register listeners reliably. One other data point for this is that I dealt with the as-a-service vs. as-a-launch in https://github.com/MobileChromeApps/cordova-plugin-background-app. In this model, I set a property before each resume / deviceready that can be queried to find out the app's state. Could possibly do similar for intents (but would need an event as well since they can come at any time, not just on start-up) On Fri, Jun 5, 2015 at 7:18 PM, Jesse <purplecabb...@gmail.com> wrote: > I have been looking into unifying launchParameters across devices so that > all cordova apps can get some context of how they were launched/activated. > This includes everything from a url/protocol launch in another app, to a > touch on a notification (toast,local,push,... ) > > My intent was to add a channel for this, however I have had some issues > with channels + stickiness. > > I wanted a channel that would call new subscribers immediately if it had > already fired. In our channel implementation this is what we call a sticky > channel. However, this particular channel may fire more than once, ie. we > could be activated multiple times while running, or receive multiple > notifications. > The current implementation for sticky will only ever call subscribers once, > and if I call fire() more than once, it actually removes it's subscribers. > [1] So I cannot use this as is for my needs. > > So my questions are : > 1. Why is like this? Is there some standard or expectation that this is > based on? > 2. Can I change it? What would be the impact of changing the behavior to > have a sticky channel fire more than once, and keep its list of > subscribers? > 3. Are there historical reasons that things are the way they are? The code > has been through several major moves since it was written, so it is > difficult to pin the original commit (Fil, Andrew? some merged pr?) If > there are historical reasons, are they still relevant? > > Please keep in mind too that I am not asking for the solution to my > specific task, I can work around anything ... I am asking solely about the > current channel-sticky implementation and it we should change it. > > Cheers, > Jesse > > > The current implementation > [1] > https://github.com/apache/cordova-js/blob/master/src/common/channel.js#L216 > > > @purplecabbage > risingj.com >
