No subject
Hi, I am developing a Robotlegs application that uses the microphone (via a service). I'm having trouble deciding upon a way to design the service so that mediators can keep track of the microphone's status without the mediators or views accessing the service directly.
The user can allow/disallow access to the microphone at any time through the Security panel. Flash's microphone class dispatches an event when this happens -- I'm just trying to figure out the best approach to send that change out from the service (so a view that depends on the microphone can show a pop-up asking the user to re-enable the microphone or whatever).
One approach I thought of: the service has a "microphoneIsMuted" signal, accessible via a property, which is dispatched by the service when necessary. Then when a mediator wishes to create a view that depends on the microphone, it sends a request signal. A command is activated by that signal, it grabs the "microphoneIsMuted" signal and the current status of the microphone from the service, and dispatches another signal saying "go ahead and create the view, here's the signal to listen to later if you care about the microphone's status changing". Then the mediator listens to that signal and acts as necessary.
Does that sound like a reasonable suggestion? Or does anybody
have a better way of approaching it? Thanks in advance.
Thanks in advance.
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
1 Posted by Stu on 21 Jan, 2012 05:17 AM
After thinking a bit more, am I just over-engineering? I could just access the service directly from the mediator.
Support Staff 2 Posted by creynders on 21 Jan, 2012 11:11 AM
The disadvantage of accessing the service directly from the mediator is that if you decide you need to use a model which is updated by the service and want to access those values in your mediators instead you'll be rewriting your mediators.
Finding the right level of abstraction is always a bit of an exercise and it depends on a few factors:
Are the views conceptually tightly coupled to the service? For instance a view could be a visualisation of an async process, in that case it makes sense to let the view's mediator access the service directly (still using an interface obviously, in order to be able to swap the service implementation)
the scope of the application and the possible reuse of its various elements in the future. Can you imagine you'll be reusing the views and their mediators in a derivative of the current project? Or wholly new projects? If yes, then it makes sense to up the level of abstraction, if not you can get away with a tighter coupling.
will the view need more data than what the service provides? If it needs (or WILL be needing) data from a few models, services etc. it makes sense to have a request-response mechanism especially if it needs all of that data at approximately the same time (for instance on registration) since it will have fewer dependencies and therefore is more easily maintained if a command is doing the data collection work.
Is a polling mechanism necessary? Could the mediator be responding to messaging with the necessary data as a payload instead? For instance it could listen to the a MicrophoneMuteToggle signal that carries a MicrophoneMuteToggleVO instance with an isMuted property.
It's always a balancing exercise between not painting yourself into a corner and not doing too much unnecessary abstracting.
3 Posted by Stu on 25 Jan, 2012 04:47 AM
Thanks for your comprehensive response. I've decided to go for a payload system with the signal, and the mediators are using promises to asynchronously communicate with the microphone.
Ondina D.F. closed this discussion on 10 Feb, 2012 11:52 AM.