On Tue, Jun 9, 2015 at 7:10 PM, Brian LeRoux <[email protected]> wrote: > big -1 on promises from me; they've only been a pain for us thus far (ask > steve about the plugman debugging >
I certainly wasn't actually proposing that we revive that debate :) Just pointing out that I feel like the promises/futures/deferreds model is closer to what we're trying to accomplish with sticky channels than the DOM event model is. > > maybe when they're "native". maaaaybe. > And even then, we'd probably want to wait for dev tools catch up. I understand how much of a pain they can be to debug. > > On Tue, Jun 9, 2015 at 7:27 AM, Ian Clelland <[email protected]> > wrote: > > > On Tue, Jun 9, 2015 at 10:19 AM, Andrew Grieve <[email protected]> > > wrote: > > > > > 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. > > > > > > > This was an area that I was hoping to leverage to use promises instead, > > back when we were discussing baking those into cordova.js -- it would be > a > > major change from the existing way of doing things, but sticky channels > are > > closer in spirit to promises than they are to events, I think. > > > > It's very similar to the service worker `ready` attribute -- before the > > worker is active, it returns a promise that asynchronously waits for > > everything to be ready, and then fires. After the worker is already > active, > > the promise resolves immediately, just like deviceready does if you > attach > > a listener after Cordova has initialized. > > > > > > > > > > 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 <[email protected]> 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 > > > > > > > > > >
