Методика организации командной работы над Flash-проектом

Механизм runtime sharing

Аналогов runtime sharing в традиционных средах разработки проектов (Java, C/C++) можно найти много (например, так работают библиотеки DLL, загрузчики классов Java и т. п.). Самым правильным определением runtime sharing во Flash MX будет, наверное, динамическая линковка. То есть, повторно используемые компоненты загружаются уже после запуска клиентского приложения (флэш-плеера).

Преимущества данного подхода очевидны: не нужно перекомпилировать ролик для того, чтобы обновить некоторые библиотечные компоненты, вы просто заменяете один или несколько библиотечных *.swf-файлов, и все работает. Данный подход обладает теми преимуществами перед альтернативными (например, использование loadMovie ), что всю работу по загрузке внешнего кода берет на себя флэш-плеер.

Иногда без этого даже нельзя обойтись, например, в тех случаях, если вы хотите, чтобы ваши флэш-ролики поддерживали сменные скины, и при этом используете разработанные не вами контролы пользовательского интерфейса, которые скины не поддерживают. В таком случае вы можете просто настроить для всех символов-элементов скинов runtime sharing из отдельного *.swf-файла, и подкладывать *.swf с нужным скином.

Что происходит при runtime sharing

Во Flash MX runtime sharing может быть настроен для любого символа библиотеки, причем должно быть жестко задано имя *.swf-файла (это может быть абсолютный или относительный путь, см. также раздел "возможные проблемы"), из которого данный символ будет загружаться. После установки этой галочки Флэш МХ берет на себя всю ответственность за загрузку символов из внешнего *.swf-файла, и вы уже почти никак (см. раздел "возможные проблемы") не можете повлиять на этот процесс. Вы не можете узнать, в каком порядке загружаются *.swf, какая часть *.swf загружена, сколько еще осталось и т. п. Это означает, что вы, например, не можете создать нормальный загрузчик своих флэш-роликов, который показывает "честные" проценты, если вы используете runtime sharing. Иногда это может также привести к неудобствам синхронизации выполнения кода (см. раздел "возможные проблемы").

Как включить и выключить runtime sharing

Управление параметрами runtime sharing производится в области Linkage свойств символа (можно просто выбрать Linkage из контекстного меню символа, это то же самое).

Итак, вам нужно задать идентификатор (тот же самый идентификатор, что нужен для использования символа из ActionScript), поставить одну из двух галочек ( Export for runtime sharing, Import for runtime sharing ) и заполнить поле URL именем *.swf-файла, из которого будет производиться импорт символа.

Удобно настроить эти параметры для экпорта, в том числе URL, в библиотечном файле, а из него просто перетаскивать библиотечные символы в клиентские флэш-ролики. Тогда в последних останется правильно заполненным поле URL, а галочка Export for runtime sharing автоматически превратится в галочку Import for runtime sharing.

Во Flash MX больше нигде (кроме вышеописанного места) нельзя настроить что-то, относящееся runtime sharing.

Из ActionScript тоже нет никакой возможности управлять настройками runtime sharing, и это очень неудобно.

Если совершенно необходимо держать под контролем то, что происходит при динамической загрузке повторно используемых компонентов, лучше отказаться от употребления runtime sharing и рассмотреть вариант с использованием loadMovie.

Возможные проблемы

Обсудим детальнее, какие неприятности могут вас ожидать при использовании runtime sharing.

1. URL файла, из которого подгружаются библиотечные символы, жестко прописывается в параметрах символов библиотеки для каждого экспортируемого/импортируемого символа. Это означает, что впоследствии изменить этот URL будет довольно сложно (см. раздел про замену путей runtime sharing с помощью author time sharing, а также раздел "Изменение текущей директории" (атрибут BASE ) из следующей лекции).
2. Забудьте о нормальном загрузчике с "честными" процентами, если вы используете runtime sharing. Вы просто ничего не сможете узнать о процессе загрузки.

3. Для каждой флэш-платформы (имеется в виду OS + Browser) существует один "стандартный" способ задания библиотечного файла в поле URL. К счастью, для большинства платформ эти способы одинаковы и выглядят так: <имя файла>.swf. Есть и исключения, например, для Internet Explorer на MacOS это file:///<полный путь к *.swf-файлу>.

   Если вы укажете URL к *.swf-файлу "нестандартным" для данной платформы способом, то при каждом использовании импортируемых символов флэш-плеер будет загружать их в память заново (по предположениям авторов, флэш-плеер сравнивает путь, прописанный в поле URL, c путем, возвращенным ему платформой, и загружает символ повторно, если пути не совпадают с точностью до символа)! Поэтому ничего не стоит написать флэш-ролик, который через 5 минут своей работы съест всю свободную оперативную память. С этим нужно быть очень аккуратным.

   Вы спросите: "А как же написать флэш-ролик, работающий корректно в ситуациях с разными флэш-платформами" (в том смысле, что у них разные "стандартные" способы записи URL)? Авторам известен только один способ: нужно полностью динамически сгенерировать все содержимое тегов <OBJECT> и <EMBED> с помощью JavaScript, в котором выясняется тип браузера и, в зависимости от типа браузера, подставить нужное значение атрибута BASE тегам <OBJECT> и <EMBED> (см. также раздел "Изменение текущей директории" (атрибут BASE ) из следующей лекции).
4. "Многозвенный" ( multi-tier ) runtime sharing. Это такой вид runtime sharing, когда клип А загружается из файла А.swf, а в клипе А лежит клип B, который загружается из файла B.swf и так далее. Во флэш-плеере до версии 6.0.65.0 была довольно условная поддержка этой функциональности, что выражалось в падениях флэш-плеера вместе с браузером (правда, Macromedia и не обещала, что это будет работать). Начиная с версии 6.0.65.0 во флэш-плеере официально добавлена поддержка "многозвенного" runtime sharing.