Загрузка звуков
 

Прошу помощи в разрешении спора.
Есть некий условный проект, который грузит в себя различные ресурсы, в т.ч. и звуки. Все загружаемые звуки должны проигрываться после того, как будут загружены по мере требования.
Собственно вопрос: каким образом лучше/правильнее грузить звуки - отдельным менеджером загрузок или звуковым менеджером (используя Sound.load)?
Заранее спасибо.

Если в приложении будет много звуков (>2 одновременно может воспроизводиться), я бы сделал SoundManager, который отвечал бы за загрузку и воспроизведение оных. И воспроизводил бы все звуки, через 1 единственный Sound, через SampleDataEvent

я бы звуки напихал в отдельную свф, грузил и дергал готовые саунды на базе звуковых файлов.

cleptoman, не подойдет, т.к. в других проектах такое может быть не приемлемым, а код необходимо использовать повторно.
Genzo, я вот считал, что загрузкой контента должен заниматься один класс/модуль, а воспроизведением другой. В отношении звуков допускаю что возможны загрузка и воспроизведение в одном классе/модуле в случае, когда нет необходимости дожидаться окончания загрузки файла для его воспроизведения.
Если я не прав, то в чем?

В принципе вы правы, т.к. частную логику загрузки нельзя мешать с логикой воспроизведения, ни кто не знает точно каким образом вы будете загружать файлы и т.п., может вы вообще их по сокетам передавать будете. В таком случае думаю хороша такая схема :
И такая иерархия :
В FileLoader может вставить механизм кеширования и т.п. вещей, а в IDataManager передавать уже загруженные данные и оперировать ими.

Genzo, спасибо за мнение. Я себе примерно так и представлял (2й вариант). Жаль только что мало альтернативных мнений. А то спор спором, но делать по уму хочется. Может в своем плане действий чего не доглядел/не учел...

Очень дельная мысль по поводу потокового/эвент контента. Первыми были гифки. Пока грузились остальные кадры, можно было смотреть первый. А по мере загрузки можно было показывать очередной. Моя мысль проста. Должна быть единственная точка запроса контента — загрузчик, инкапсулирующий разные способы получения любого контента. Воспроизведение — задача вьюх (представлений).

Вроде бы правильно, конечно. Но с другой стороны: если лоадер является ДО, то почему бы его не закинуть на сцену? И пусть грузит себе, если ему нужно, и по задаче от этого ДО ничего больше не требуется. Если Sound и загрузчик и звук, то почему это не использовать децентрализовано по отношению к приложению?
В чём вред, или скрытые грабли? Просто не по феншую?

fish_r, т.е. закинуть и будь что будет? Ни контроля, ни управления? А если таких объектов штук ..дцать? Тогда ко всему прочему мы дублируем функционал загрузки контента в каждом экземпляре класса, вместо того, чтоб поручить это одному классу/модулю, который будет управлять (помимо всего прочего) и количеством активных загрузок.

Вот кстати интересно (если говорить о звуках), если нет необходимости для начала воспроизведения дожидаться окончания загрузки, как лучше поступить в этом случае? Наверное все равно не оставлять все на волю случая и контролировать загрузчиком, если (что-то не нравится мне это "если") таких объектов гарантированно небольшое количество.

Ну и было бы интересно узнать кто как поступает на реальных проектах.