Sticky Channels

[Jesse <pu...@gmail.com>]

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

Re: Sticky Channels

[Ian Clelland <ic...@chromium.org>]

On Tue, Jun 9, 2015 at 7:10 PM, Brian LeRoux <b...@brian.io> 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 <ic...@chromium.org>
> wrote:
>
> > On Tue, Jun 9, 2015 at 10:19 AM, Andrew Grieve <ag...@chromium.org>
> > 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 <pu...@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
> > > >
> > >
> >
>

Re: Sticky Channels

[Brian LeRoux <b...@brian.io>]

big -1 on promises from me; they've only been a pain for us thus far (ask
steve about the plugman debugging

maybe when they're "native". maaaaybe.

On Tue, Jun 9, 2015 at 7:27 AM, Ian Clelland <ic...@chromium.org> wrote:

> On Tue, Jun 9, 2015 at 10:19 AM, Andrew Grieve <ag...@chromium.org>
> 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 <pu...@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
> > >
> >
>

Re: Sticky Channels

[Ian Clelland <ic...@chromium.org>]

On Tue, Jun 9, 2015 at 10:19 AM, Andrew Grieve <ag...@chromium.org> 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 <pu...@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
> >
>

Re: Sticky Channels

[Andrew Grieve <ag...@chromium.org>]

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 <pu...@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
>