Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[DRAFT] move enable sounds to the audio helper class and expose getter and setters to enable and disable toggeable sounds #115

Conversation

kamalbennani
Copy link
Contributor

The goal of this PR is to answer the "lack of implementation" described in this issue

Contributing to Twilio

All third party contributors acknowledge that any contributions they provide will be made under the same open source license that the open source project is provided under.

  • I acknowledge that all my contributions will be made under the project's license.

Pull Request Details

JIRA link(s):

Description

This PR introduces a couple of changes:

  • Remove enabledSounds responsibility from the Device class and move it close to the AudioHelper
  • Expose toggleable sounds getters/setters
  • Use this.audio.outgoing instead of relying on the enabledSounds private property

Burndown

Before review

  • Updated CHANGELOG.md if necessary
  • Added unit tests if necessary
  • Updated affected documentation
  • Verified locally with npm test
  • Manually sanity tested running locally
  • Ready for review

Before merge

  • Got one or more +1s
  • Squashed erroneous commits if necessary
  • Re-tested if necessary

@charliesantos
Copy link
Collaborator

@mhuynh5757 can you please do a quick pass?

@kamalbennani kamalbennani changed the title move enable sounds to the audio helper class and expose getter and setters to enable and disable toggeable sounds [DRAFT] move enable sounds to the audio helper class and expose getter and setters to enable and disable toggeable sounds Oct 4, 2022
…tters to enable and disable toggeable sounds
@kamalbennani kamalbennani force-pushed the task/PH-7239/expose-enable-sound-methods branch from c4cbec3 to 7fea676 Compare October 4, 2022 07:33
@@ -359,8 +387,8 @@ class AudioHelper extends EventEmitter {
return enabledSounds[key];
}

Object.keys(enabledSounds).forEach(key => {
(this as any)[key] = setValue.bind(null, key);
Object.keys(enabledSounds).forEach((key: Device.ToggleableSound) => {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

if (options.enabledSounds) {
this._addEnabledSounds(options.enabledSounds);
}
this._addEnabledSounds();
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems like we only call this once at instantiation, and therefore we only add sounds that are enabled at construction time. It's not immediately clear to me that we can enable sounds post-construction, perhaps we need some mechanism for that?

@@ -21,6 +21,12 @@ const kindAliases: Record<string, string> = {
audiooutput: 'Audio Output',
};

export const defaultEnabledSounds: Record<Device.ToggleableSound, boolean> = {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we can remove these defaults from device if we want the AudioHelper class to have more control over the enablement of sounds.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, didn't see the device changes, please ignore this comment! 😓

@@ -972,7 +963,7 @@ class Device extends EventEmitter {
maxAverageBitrate: this._options.maxAverageBitrate,
preflight: this._options.preflight,
rtcConstraints: this._options.rtcConstraints,
shouldPlayDisconnect: () => this._enabledSounds.disconnect,
shouldPlayDisconnect: () => this._audio ? this._audio.disconnect() : defaultEnabledSounds.disconnect,
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should check if these members are defined, i.e. this._audio.disconnect might be undefined depending on the state of the AudioHelper and we might try to invoke it.

@mhuynh5757
Copy link
Collaborator

mhuynh5757 commented Oct 26, 2022

@kamalbennani thanks for contributing to the SDK! All feedback is greatly appreciated. I left some comments on some more specific details.

One recommendation over the current implementation that I'd like to see change is moving away from setting EnableSoundFn members on the object and using something less anti-pattern, like indexing an internal map with the Sound enumeration we already have. So the API would look something like

audioHelper.shouldPlaySound(Device.SoundName.Incoming)

or maybe we relegate all "shouldPlay" logic to the AudioHelper entirely and in the Device we just ask the AudioHelper to play it, getting some sort of return value from the AudioHelper if necessary.

What do you think?

@charliesantos
Copy link
Collaborator

@kamalbennani I'm closing this now. See my comment here #14 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants