Форум Flasher.ru

Форум Flasher.ru (http://www.flasher.ru/forum/index.php)
-   ActionScript 3.0 (http://www.flasher.ru/forum/forumdisplay.php?f=83)
-   -   Мысли о ResourceManager. Как сделать его удобным? (http://www.flasher.ru/forum/showthread.php?t=152832)

Psycho Tiger 23.03.2011 20:30

Мысли о ResourceManager. Как сделать его удобным?
 
Всем привет!
Озадачен созданием универсального ResourceManager`а.
В моём представлении, что я хочу: я хочу свободно создавать экземпляры интересующего меня класса, вне зависимости от положения этого класса в пространстве. Что я имею ввиду?
Я имею ввиду, что захотев создать класс "GFXMenu", содержащий графику из меню, я должен буду написать одну строчку. Например, такую:
Код AS3:

new resourceManager.getDefinition("GFXMenu")();

Причем это GFXMenu может находится в любом далеком swf-файле. Чтобы внести ясности, если GFXMenu вкомпиливался бы в текущую флешку, то я написал бы
Код AS3:

new (getDefinitionByName("GFXMenu") as Class)();

или вообще
Код AS3:

new GFXMenu();

Я вошел в третью стадию программиста (после abstraction freak), у меня появилась огромная любовь к конфигам в XML файлах :)

Вобщем, мои мысли: ResourceManager — это НЕ статичный класс, которых можно создать очень много экземпляров. (Каждому передается ApplicationDomain, или он создаёт новый). На вход подается XML подобного содержания:
Код:

<source name="mainMenu" type="swf" definitionName="GFXMainMenu" file="gfx/main.swf" preload="1" />
В будующем, в коде я могу написать
Код:

trace(new resourceManager.getDefinition("mainMenu")()); //GFXMainMenu
Если файл main.swf, содержащий GFXMainMenu ещё не загружен — он загрузится, а после пользователю выдадут ссылку на Class.
Суть в том, что тем самым я смогу обеспечивать достаточно серьезную модульность: можно будет разбивать приложение на 40 swf по 50 кб каждое, а можно будет сделать одну swf на 2 мб без вмешательств в сам код, будет правиться только входной XML файл.

Единственное нарушение этой идиллии, это необходимости перезагрузки данных. Я думаю сделать его похожим на что-то вроде этого:
Код AS3:

resourceManager.preloadResources(callback,"mainMenu","gameTable","button1","button2");

где callback вызовется в тот момент, когда все ресурсы, перечисленные далее, будут загружены и доступны. Я нарочно отказываюсь от события, т.к. одним resourceManager могут пользоваться 10 разных объектов, и придется ощущать дискомфорт, пытаясь понять, кому же адресовано это Event.COMPLETE.
Ещё в XML`е в конце стоит атрибут "preload". Если он равен 1, тогда этот ресурс должен быть загружен сразу же, после создания менеджера (это прелоадинг, по сути). Помимо этого этот менеджер будет способен грузить вообще любые ресурсы: звуки, XML, картинки и прочее, по той же схеме.
Что вы думаете об этом?

gloomyBrain 23.03.2011 20:43

Я думаю, что колбеки не тру, и надо писать свой евент (с полем alias или полями alias & type)
Насчет xml - не гибко, парсер xml должен висеть отдельно и формировать из него очередь
По поводу статичности и аппДоменов - выглядит неплохо.

Ну и плюс ко всему - я бы сделал несколько классов "потоков загрузки" с общим интерфейсом и работал бы через этот интерфейс

Psycho Tiger 23.03.2011 20:55

Цитата:

Я думаю, что колбеки не тру, и надо писать свой евент (с полем alias или полями alias & type)
Я об этом много думал. В конце концов понял вот что: каждому объекту будет нужно конечное число definitions, и когда-нибудь они точно закончатся, т.е. мне надо будет подписываться на событие раньше, чем я запрошу их (если они все загружены - событие стрельнет сразу же), что является потенциальным местом для ошибок; более того, для каждой вьюшки это будет уникальный набор графики, знать о том, что "утка" загружена, когда нам нужен "гусь" нам как-то совсем не надо. В общем, серьезно, при глубинном рассмотрении дерганье callback только в выйгрыше.

Цитата:

Насчет xml - не гибко, парсер xml должен висеть отдельно и формировать из него очередь
Да, конечно, у меня есть некий класс-контейнер-VO ResourceManagerDataProvider, от которого пляшет ResourceManager, а в него уже десериализуются данные от кого угодно; XML поставлен в качестве примера, чтобы было нагляднее.

Цитата:

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

expl 23.03.2011 21:00

Цитата:

Вобщем, мои мысли: ResourceManager — это НЕ статичный класс, которых можно создать очень много экземпляров. (Каждому передается ApplicationDomain, или он создаёт новый). На вход подается XML подобного содержания:
Код:
<source name="mainMenu" type="swf" definitionName="GFXMainMenu" file="gfx/main.swf" preload="1" />
Люк, не поддавайся соблазнам конфигурации! Почувствуй силу принципа "convention over configuration"
(просто можно затрахаться - проверял - записывая какая картинка откуда пришла вручную)

Цитата:

Ну и плюс ко всему - я бы сделал несколько классов "потоков загрузки" с общим интерфейсом и работал бы через этот интерфейс
Это же придется в приложении решать к какому "потоку загрузки" обратиться. Ради чего? Делаем общий менеджер - который раскидывает все на потоки (на сколько нужно потоков) согласно приоритетам ресурсов и всё.

gloomyBrain 23.03.2011 21:07

Цитата:

если они все загружены - событие стрельнет сразу же
Если получить ресурс не удалось, то добавим его в очередь и подпишемся на событие. Если он уже в очереди - ничего не делаем, ждем загрузки. Если получить удалось - ... profit

Цитата:

при глубинном рассмотрении дерганье callback только в выйгрыше
Ага. Особенно когда двум независимым view нужен один и тот же ресурс

Цитата:

Вот это объясни пожалуйста, что ты хочешь сказать =)
Мне лениво =) В кратце - так (это к внутренним механизмам загрузки относится):
xml -> URLLoader
swf, jpg, png -> Loader
something -> ILoader

Psycho Tiger 23.03.2011 21:20

Цитата:

Если получить ресурс не удалось, то добавим его в очередь и подпишемся на событие. Если он уже в очереди - ничего не делаем, ждем загрузки. Если получить удалось - ... profit
Ага, и в итоге вместо одной строчки "мне нужно вот это!", а после нормального человеческого использования мы будем делать под 40 листенеров, потому что это тру?)

Цитата:

Ага. Особенно когда двум независимым view нужен один и тот же ресурс
Ну, кто обратиться вторым не начнет загрузку, а просто добавит callback. По загрузке ресурса callback сработает у обоих.
Цитата:

xml -> URLLoader
swf, jpg, png -> Loader
something -> ILoader
Да в целом у меня всё от ILoader будет имплементироваться. Но на каждый "свой" загрузчик полюбому придется создавать свой экземпляр, в итоге экземпляров-загрузчиков будет 3: для Sound, Loader, и URLLoader. Загрузчики все будут экземпляром одного класса, QueueLoader. Это понятно, это мелочи, но спасибо)
Цитата:

Люк, не поддавайся соблазнам конфигурации! Почувствуй силу принципа "convention over configuration"
(просто можно затрахаться - проверял - записывая какая картинка откуда пришла вручную)
Буду рад альтернативам =)

gloomyBrain 23.03.2011 21:27

Цитата:

в итоге экземпляров-загрузчиков будет 3
А почему не 6 или 9 или сколько угодно еще? Всяко быстрее грузить в несколько потоков.

Цитата:

Ага, и в итоге вместо одной строчки "мне нужно вот это!", а после нормального человеческого использования мы будем делать под 40 листенеров, потому что это тру?)
Ну а если нужен еще колбек на IOError? Или на ProgressEvent (а он точно бывает нужен)? Писать в каждом классе стандартный колбек? ИМО, если обсервер уже реализован на нативном уровне, зачем изобретать его еще раз.
Про 40 листенеров - не понял

Psycho Tiger 23.03.2011 21:33

Цитата:

Ну а если нужен еще колбек на IOError? Или на ProgressEvent (а он точно бывает нужен)?
Вот их уже событиями нужно, несомненно. Причем на каком-то глобальном уровне. Я подумаю, в общем )

Цитата:

Про 40 листенеров - не понял
Ну ты я так понял предлагаешь на каждый запрос вешать листенер, вроде скачали кнопку - Event.COMPLETE, скачали картинку лося - Event.COMPLETE. Код разрастется очень быстро и неоправданно. Но я обещаю подумать)

expl 23.03.2011 21:34

Цитата:

Буду рад альтернативам =)
Цитата:

resourceManager.preloadResources(callback,"mainMenu","gameTable","button1","button2");
Что здесь происходит? Здесь хардкодятся имена "mainMenu", "gameMenu" и т.д. и им в соответствие ставиться карта url(name) - а оно надо ее руками писать то?
Мы ведь обычно знаем, что:
- все начинающееся на UI лежит в ui.swf
- все начинающееся на Animation лежит в animation.swf

Делаем себе сугубо проектно-зависимый класс, в котором хардкодим наше соглашение
Код AS3:

ResourceLocation
{
    private var _mediaPath:String;
    public static init(mediaPath:String)
    {
          _mediaPath = mediaPath;
    }
    public static function getAnimationURL():String
    {
          return _mediaPath + "/" + "animation.swf";
    }
 
      public static function getUIURL():String
      {
            return _mediaPath + "/" + "ui.swf";
      }
}

можно суровее:
Код AS3:

    public static function getSwfURL(name:String):String
    {
          if (name.indexOf("Animation") == 0)
          {
                return _mediaPath + "/" + "animation.swf";
          }
          if (name.indexOf("UI") == 0)
          {
                return _mediaPath + "/" + "ui.swf";
          }
          return null;
    }

Но во втором подходе могут быть проблемы при одноименных классах.

При первом подходе можно возвращать не url, а сразу ресурс, типизированный соответственно загружаемым данным (у которого потом вызывать load() и на который подписывать колбеки)

gloomyBrain 23.03.2011 21:45

Цитата:

скачали кнопку - Event.COMPLETE, скачали картинку лося - Event.COMPLETE
Ну а кто мешает запросить пачку ресурсов и получить по всей пачке один Event.COMPLETE? Для этого как раз нужно сделать ILoader, который бы имплементился не только простыми загрузчиками (URLLoader, Loader, Sound ...), но сложными (кастомный BundleLoader)


Часовой пояс GMT +4, время: 01:55.

Copyright © 1999-2008 Flasher.ru. All rights reserved.
Работает на vBulletin®. Copyright ©2000 - 2024, Jelsoft Enterprises Ltd. Перевод: zCarot
Администрация сайта не несёт ответственности за любую предоставленную посетителями информацию. Подробнее см. Правила.