cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Clelland <iclell...@chromium.org>
Subject Re: Sticky Channels
Date Tue, 09 Jun 2015 14:27:26 GMT
On Tue, Jun 9, 2015 at 10:19 AM, Andrew Grieve <agrieve@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 <purplecabbage@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
> >
>

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