Differentiating between self call and external call

[infojunkie]

I am working on a media player that uses a TimingObject using your implementation here, and I have a question about the expected programming model. Consider the following cases:

• My player exposes its internal this._timingObject to let UI clients be notified of playback changes, and possibly control the playback.

• The UI client calls the exposed function player.play() to start playback.

• When the player starts playing, it calls this._timingObject.update({ velocity: 1 }); to alert any listeners that playback has started.

• The UI client calls this._timingObject.update({ velocity: 2 }); to change the playback speed. I would like the player to set up an event listener on this._timingObject to respond to the velocity update.

But how can the player differentiate between internal change events (as caused by play() invocations) versus external changes (such as update({ velocity }) ? Is the TimingObject programming model expecting both scenarios, or is it implied that ALL player changes should be done via TimingObject.update() calls?

PS. I've tried wrapping the player's calls to this._timingObject.update() within a function that unregisters its own change listener before the call, and re-registers it after the promise resolves, but it would seem that the change event is generated outside of the TimingObject.update() calls completely.

[chrisguttandin]

The 'change' event gets dispatched in a setTimeout() call.

https://github.com/chrisguttandin/timing-object/blob/5220f945ebaf64978bde6a5dfe79718dbe5dc738/src/factories/timing-object-constructor.ts#L296

I think the following should work:

timingObject.removeEventListener('change', yourChangeListener);
timingObject.update({ velocity: 2 });
setTimeout(() => timingObject.addEventListener('change', yourChangeListener));

But maybe it's a bit more robust to do something like this:

let invocationToSkip = 0;

timingObject.addEventListener('change', () => {
    if (invocationToSkip > 0) {
        invocationToSkip -= 1;
    } else {
        yourChangeListener();
    }
});

// ... and later on ...
skipNextInvocation += 1;
timingObject.update({ velocity: 2 });

Would that work for you?

[infojunkie]

Thanks @chrisguttandin for your reply. Regarding the more robust version: is it really the removeEventListener() call that does the processing that you mention? I would have expected addEventListener.

[chrisguttandin]

Oh, sorry for that. You're right. I fixed the typo in the comment above.

[infojunkie]

Thanks for your help here. I am not sure that counting the skippable invocations would work, for example in case there happens to be interleaving internal and external calls. In my opinion, allowing the timing vector update to carry an additional, arbitrary payload that the event listener interprets would solve the problem definitively and without concurrency issues.

But at a higher level, I still am not clear on whether the Timing Object programming model accounts for the difference between these 2 cases - or if I am misunderstanding something fundamental.