Some thoughts on this:
Uses:
1. Start-up / single-fire events
2. Multi-fire custom event types "menubutton", "searchbutton",
"backbutton", "pause", "resume"
3. Hooking document.addEventListener(foo)
Currently state:
channel.js does 1 well, but does 2 except for the fired state behaviour,
and 3 is done by cordova.js.
Thoughts:
- Channel does a good job at #1, although it could be simplified if that's
all we need it for.
- We would get truer (proper propagation) event behaviour if we just fired
custom events on actual DOM via createEvent & dispatchEvent
- Using DOM events is a bit harder to debug since it goes in & out of
native. It's also slower for this reason.
How to make Channel good at both 1 and 2:
- Add a mode to make a channel as sticky or not
- If Sticky, don't hold onto subscribers after initial fire (free up memory)
- If not sticky, don't fire upon subscription
I'm thinking that we don't need a dramatic change.
On Mon, Aug 27, 2012 at 9:50 AM, Filip Maj <f...@adobe.com> wrote:
> I think it's time for a review of this module and how it fits into
> cordova-js. Spell out exactly what we need from it, and then find a
> suitable replacement or do a rewrite. A few of the channels have specific
> firing needs e.g. deviceready. I think we can get something much
> smaller/simpler in there.
>
> If I remember correctly, I hacked this out of complete ui, a
> Nitobi-written UI library from like.. 2007. Pretty sure it's Dave
> Johnson's code too! It may have been too much for our purposes any ways.
>
> On 8/24/12 12:15 PM, "Andrew Grieve" <agri...@chromium.org> wrote:
>
> >I like that idea. Channel already has an opts param in its ctor, so I'll
> >just throw a boolean into it.
> >
> >channel.create('pause', { multi: true });
> >
> >Created a bug for this: https://issues.apache.org/jira/browse/CB-1274
> >
> >
> >
> >
> >On Fri, Aug 24, 2012 at 1:46 PM, Gord Tanner <g...@tinyhippos.com> wrote:
> >
> >> I know there was some talk on the mailing list awhile ago of replacing
> >>the
> >> channel module with something a little simpler.
> >>
> >> If we do want to patch this issue I would suggest having this done at
> >> construction time.
> >>
> >> var deviceready = channel.create('deviceready', channel.types.once);
> >> var pause = channel.create('pause', channel.types.refireable);
> >>
> >> (naming in example above is for discussion purposes only ;) )
> >>
> >> On Fri, Aug 24, 2012 at 11:37 AM, Andrew Grieve <agri...@chromium.org
> >> >wrote:
> >>
> >> > I was looking through the channel code and noticed that the fired
> >>state
> >> is
> >> > never assigned to false. This makes sense for channels like
> >> onDeviceReady,
> >> > when you'd want this to stay active. But...
> >> >
> >> > It's a bit strange for things like onPause and onResume. It means
> >>that if
> >> > the app has ever been paused or resumed, then every new listener going
> >> > forward is going to fire upon subscription even though the current
> >>state
> >> is
> >> > not paused/resumed. I tested this out locally, and it appears to be
> >>true.
> >> > So...
> >> >
> >> > How about we add a method called "fireOnce", which calls fire() and
> >>then
> >> > sets fired = false so that new subscribers will not be immediately
> >> > triggered.
> >> >
> >>
> >>
> >>
> >> --
> >> Gord Tanner
> >> Senior Developer / Code Poet
> >> tinyHippos Inc.
> >> @tinyhippos
> >>
>
>
