Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cordova.apache.org
Received-SPF: pass (nike.apache.org: domain of brian.leroux@gmail.com
 designates 209.85.216.42 as permitted sender)
MIME-Version: 1.0
Sender: brian.leroux@gmail.com
In-Reply-To: 
 <CAK_TSX+D=UOOH9vGSUkoLqqsUdPSxr5M66K2qHAaoGaW=UEzng@mail.gmail.com>
References: 
 <CAKP6k2vs9E291jcYcWs4GUXLCc9jbajBNS8AcM8aev+PDXDgFw@mail.gmail.com>
	<CABiQX1XebPyDgG2iLNTDpnc5XeVjMJyEhiCRpG5SCwuiFMa5og@mail.gmail.com>
	<CAK_TSX+D=UOOH9vGSUkoLqqsUdPSxr5M66K2qHAaoGaW=UEzng@mail.gmail.com>
Date: Tue, 9 Jun 2015 16:10:03 -0700
Message-ID: 
 <CADVgkyMEqa__tbG9E83Hx09cC4SBz0RDv+FZ3FaPiWwRP72Yjw@mail.gmail.com>
Subject: Re: Sticky Channels
From: Brian LeRoux <b@brian.io>
To: "dev@cordova.apache.org" <dev@cordova.apache.org>
Content-Type: multipart/alternative; boundary=20cf307f360cc2a4d805181ddbe3

--20cf307f360cc2a4d805181ddbe3
Content-Type: text/plain; charset=UTF-8

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 <iclelland@chromium.org> wrote:

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

--20cf307f360cc2a4d805181ddbe3--