Placing sound manager in MVC

vishwas.gagrani's Avatar

vishwas.gagrani

11 Dec, 2012 07:54 AM

hi!
There is a SoundManager class taking care of all the sounds in the project. I concluded putting it besides "views" folder . Inside a folder called sounds. To make use of Robotlegs structure, I created SoundManagerMediator for the SoundManager. That i mentioned in Context. The awkward thing now i am facing is that i have to extend SoundManager with sprite, and use addChild(SoundManager) to instantiate SoundManagerMediator.

I am doubtful, if i used SoundManager the wrong way, and it shouldnot be placed besides "view".. but somewhere else ?

Please guide.

Thanks
Vishwas

  1. Support Staff 1 Posted by Ondina D.F. on 11 Dec, 2012 11:28 AM

    Ondina D.F.'s Avatar

    Hi Vishwas,

    There are 2 questions you’re asking:
    1-How to mediate a non-visual element?
    2-What is a SoundManager? A View, a Model, or a Service?

    1-If your SoundManger is not a visual element and you want to mediate it, you can do this:

    mediatorMap.mapView(SomeSoundManager, SomeSoundManagerMediator);
    var someSoundManager:SomeSoundManager= new SomeSoundManager();
    or
    //var someSoundManager:SomeSound= injector.instantiate(SomeSoundManager); mediatorMap.createMediator(someSoundManager);

    But, in this case, if you wanted to dispatch events from SoundManger to SoundManagerMediator, you’d have to let SoundManger extend EventDispatcher. And, you’d have to remove the mediator manually, if need be.

    2-If we wanted to follow MVCS strictly, then the loading of sounds should be performed by a Service, and the controlling of sounds– play, pause, rewind, stop, etc – would be certainly View logic. But, maybe your application would not benefit too much from forcing this separation of concerns on a media player, so having a SoundManager loading and controlling the sounds in a View might be an acceptable compromise. In this case, where you also have components for controlling the sound, thus user interaction, you’d better have a SoundManger extending a display object container, and the mediator, as you well know, would be created/removed automatically.

    On the other hand, a SoundManger (or SoundController or whatever name you give it) isn’t always interactive, meaning the user has no control over the playing, stopping of sounds. Maybe the sound data is generated dynamically, and in this case having a View with a Mediator might not be the best solution, or just too complicated. Perhaps all you need is a class that can communicate with the rest of the application, thus have a shared event dispatcher injected, or extending Actor. Also, look at this discussion: http://knowledge.robotlegs.org/discussions/questions/664-mediating-...

    In my opinion, whether a SoundManager should be treated like a View or not, depends on the specific project, and in the end all that matters is that it is well encapsulated and reusable.

    Cheers,
    Ondina

  2. 2 Posted by vishwas.gagrani on 11 Dec, 2012 12:47 PM

    vishwas.gagrani's Avatar

    Thanks, for the quick response.
    Your post in reply is very helpful and informative. :)

  3. vishwas.gagrani closed this discussion on 11 Dec, 2012 12:47 PM.

Comments are currently closed for this discussion. You can start a new one.

Keyboard shortcuts

Generic

? Show this help
ESC Blurs the current field

Comment Form

r Focus the comment reply box
^ + ↩ Submit the comment

You can use Command ⌘ instead of Control ^ on Mac