Conceptual question: is a sound manager a model, a service, or simply another type of actor?
So I am wondering something here: what to do with a sound manager? What I usually do is I have one central class, a singleton, that receives requests to play sounds. At this point, the sound are already loaded, there is no need to load anything.
Then I wonder, is this a model? I don't feel so, because there is not data saved, just requests for an action.
Is that a service? Neither, because no data is requested from elsewhere.
What would be your opinion? Should I force it into one of these
categories, or simply create another package, like
com.project.media.SoundManager?
Just wondering, thanks!
Comments are currently closed for this discussion. You can start a new one.
Support Staff 2 Posted by Stray on 19 Apr, 2012 06:50 PM
Good question!
Till prompted a similar discussion among those of us at try{harder} recently.
It's possible to consider views and services as being "the same thing" - both are concerned with input / output. (Where models and controllers are concerned with state, logic and transitions).
Viewed in that light - a service in Robotlegs is usually actually a mediator for an external IO flow.
Of course packages in AS3 have only 2 purposes:
1) To allow us to restrict access between classes using the 'internal' modifier.
2) To help the developers to find code and conceptualise relationships between the objects in the system.
In practice we rarely make use of (1) - so, I'd go with whatever feels most in line with (2) - and in that situation your
mediapackage seems like a pretty good fit.hth,
Stray
Support Staff 3 Posted by creynders on 20 Apr, 2012 05:57 AM
2 cents:
IMO audio is part of the view tier: it's data presentation. If a background loop starts playing it represents the readiness of the application state. If a "click" sound plays, it's user feedback. All responsibilities of the view tier.
I handle it just as any other context-wide view (notification center, progress dialog, ...)
The name "manager" is simply misleading, because it sounds like a service.
4 Posted by Abel de Beer on 20 Apr, 2012 08:54 AM
I share creynders' opinion: sound is a representation of the state of the application, be it large (menu music) or small (button click sound), which makes it belong to the View tier.
I made a post about this some time ago and I think it's still relevant: http://knowledge.robotlegs.org/discussions/solutions/9-mediate-non-...
5 Posted by jansensan on 24 Apr, 2012 07:12 PM
At first I was hesitant about you guys's suggestion, but I looked into Abel's logic, and it is sound (no pun intended).
Technically, it would behave the same way as I had planned for the sound manager, however in this case the requests for sounds are handled by the mediator.
Personally, I would have only one sound view (erh, you know what I mean) and not many. I really want to avoid having many things that play one sound each.
Ondina D.F. closed this discussion on 05 May, 2012 01:26 PM.