tag:robotlegs.tenderapp.com,2009-10-18:/discussions/problems/466-no-subjectRobotlegs: Discussion 2018-10-18T16:35:36Ztag:robotlegs.tenderapp.com,2009-10-18:Comment/130649442012-01-21T05:04:39Z2012-01-21T09:27:31ZNo subject<div><p>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.</p>
<p>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).</p>
<p>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.</p>
<p>Does that sound like a reasonable suggestion? Or does anybody
have a better way of approaching it? Thanks in advance.<br>
Thanks in advance.</p></div>Stutag:robotlegs.tenderapp.com,2009-10-18:Comment/130649442012-01-21T05:17:47Z2012-01-21T05:17:48ZNo subject<div><p>After thinking a bit more, am I just over-engineering? I could
just access the service directly from the mediator.</p></div>Stutag:robotlegs.tenderapp.com,2009-10-18:Comment/130649442012-01-21T11:11:49Z2012-01-21T11:17:39ZNo subject<div><p>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.</p>
<p>Finding the right level of abstraction is always a bit of an
exercise and it depends on a few factors:</p>
<ul>
<li>
<p>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)</p>
</li>
<li>
<p>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.</p>
</li>
<li>
<p>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.</p>
</li>
<li>
<p>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.</p>
</li>
</ul>
<p>It's always a balancing exercise between not painting yourself
into a corner and not doing too much unnecessary abstracting.</p></div>creynderstag:robotlegs.tenderapp.com,2009-10-18:Comment/130649442012-01-25T04:47:38Z2012-01-25T04:47:39ZNo subject<div><p>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.</p></div>Stu