Московский физико-технический институт
Опубликован: 23.12.2005 | Доступ: свободный | Студентов: 2868 / 252 | Оценка: 4.61 / 4.44 | Длительность: 27:18:00
ISBN: 978-5-9556-0051-2
Лекция 13:

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

Аннотация: Механизм author time sharing - для чего он нужен и как его применять. Механизм runtime sharing - его отличия от author time sharing, плюсы и минусы. Управление процессом загрузки клипов, подключенных при помощи runtime sharing. Совместная работа двух механизмов sharing. Шаблоны (шаблонные *.fla-файлы) для разработки. Публикация и использование html-шаблонов. Создание собственных библиотек компонентов (и других сущностей для совместного использования). Программа для массовой компиляции флэш-файлов. Использование специальных средств операционной системы: subst (псевдонимов логических дисков) и hardlink'ов. Удобные способы применения системы контроля версий.

Как мы уже не раз говорили, эта книга предназначена для программистов, участвующих в большом Флэш-проекте. Однако все большие проекты отличаются тем, что необходимо прикладывать много усилий для поддержания порядка в них. Обычно требуется заводить центральное хранилище исходных файлов, принимать меры к повторному использованию кода, грамотно применять статическую и динамическую линковку, иметь средства для автоматической сборки версий и т.д. Удастся ли навести подобный порядок во Флэш-проекте и может ли Flash МХ предоставить для этого необходимые средства? Этому вопросу и посвящена данная лекция. И начнем мы с возможностей повторного использования кода.

Механизм author time sharing

Повторное использование кода - это первое, зачем в большом Флэш-проекте нужен программист. То есть, ряд компонентов должен быть написан заранее и использоваться всеми участниками проекта. Здесь обычно не возникает вопросов до тех пор, пока в компонентах не возникает ошибок. А вот дальше начинаются мучения. Несчастный программист рассылает всем письмо: "Вот в таком-то файле лежит исправленный компонент (или просто клип), откройте его и перетащите в разрабатываемый вами модуль". А несчастный дизайнер, который по пять раз на дню проделывает эту операцию, кроет программиста последними словами. Или же забывает (забивает?) сию операцию проделывать. А потом через три дня снова кроет программиста, за то, что "ничего не работает". Знакомая ситуация? Совсем другое дело, когда в каком-нибудь Java или C++ проекте можно указать, где лежит библиотечный исходный файл. И когда разработчик библиотеки этот файл подменяет, никто ничего не замечает, просто после перекомпиляции все вдруг заработало (или наоборот, перестало, но тут уж не принцип повторного использования кода виноват). Итак, нам нужна возможность компилировать Флэш-анимацию из нескольких кусков, лежащих в разных файлах: один кусок правит дизайнер, делающий свой модуль, другой - разработчик библиотеки.

Что происходит при author time sharing

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

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

Если в символ вставлены экземпляры других символов, они тоже "высасываются" из внешнего файла (не зависимо от того, установлен ли непосредственно для них режим author time sharing ).

Обратите внимание: если у вас в каком-нибудь клипе, который вы хотите подменять с помощью author time sharing, используется attachMovie, помните, что те символы, которые вы создаете с помощью attachMovie, не будут заменены автоматически. Можно для каждого из них настроить author time sharing отдельно, но это не самый лучший способ, есть более изящный и безопасный. Сделайте в клипе, для которого вы настраиваете author time sharing, отдельный слой типа " guide " (чтобы это никак не повлияло на работу) и положите в него по одному экземпляру каждого клипа, которые вы создаете с помощью attachMovie в данном клипе. Тогда они всегда будут импортироваться вместе с главным клипом.

В каком-то смысле механизм author time sharing похож на использование уже упоминавшейся директивы #include, за исключением того, что #include позволяет загрузить только кусок кода ActionScript, а с помощью author time sharing можно заменить компонент целиком (см. также раздел "Использование #include " этой же лекции).

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

Сразу хочется заметить, что термин author time sharing не является достаточно стандартным (в отличие, например, от термина runtime sharing ). Вы не найдете его в среде разработки Флэш МХ. Последняя оперирует термином "источник" ( source ), соответствующие параметры настраиваются в одноименной области свойств символа библиотеки (если вы не видите этой области, нажмите кнопку Advanced ).

Итак, что можно сделать с помощью этой области source:

  1. заменить имеющийся в библиотеке символ на символ из другой библиотеки. Для этого нужно нажать на кнопку Browse, выбрать файл с роликом, после чего из его библиотеки выбрать символ, на который заменится символ из локальной библиотеки (этого же результата можно достигнуть, если открыть две библиотеки и перетащить символ из одной библиотеки в другую). Это одноразовая замена символа;
  2. собственно включить author time sharing. Для этого нужно включить флажок " Always update before publishing " (если соответствующий чекбокс disabled, это значит, что Флэш не знает никакого другого "источника" для данного символа, кроме его локальной библиотечной копии (нажав кнопку Browse, можно указать этот источник). Вот теперь замена символа будет производиться при каждой компиляции ролика.

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

В целом механизм author time sharing работает довольно хорошо и стабильно, но все же авторы нашли парочку проблем, которые могут проявиться.

Первая проблема связана с использованием "многозвенного" author time sharing, то есть когда символ А содержит в себе символ B, при этом символ А во всех флэш-роликах обновляется из файла А, а символ B во всех флэш-роликах (в том числе в файле А ) обновляется из файла B.

При наличии такой конфигурации author time sharing Flash MX не сможет нормально компилировать флэш-ролики, в которых используется символ A, он "падает" каждый раз с ошибкой "Pure virtual function call". Если вы непременно хотите использовать именно такой способ работы, то из этой ситуации есть выход, который, правда, носит немного "хакерский" характер: нужно отключить author time sharing либо для всего компонента, либо для группирующего символа во флэш-ролике, после чего скомпилировать его, а затем можно будет заново включить author time sharing. Но, в целом, авторы не рекомендуют такой способ работы (использование "двухуровневого" author time sharing1Если "двухуровневый" author-time sharing используется в комбинации с runtime sharing, то есть весь компонент обновляется как с помощью author-time sharing, так и с помощью runtime sharing (и то же самое происходит с группирующим символом элементов скинов в составе компонентов), то все, похоже, работает нормально. ).

Вторая проблема связана с тем, что при обновлении author time shared символов, которые лежат в подпапках библиотеки, зачастую создаются лишние подпапки в библиотеке "клиентского" ролика. Например, если правильная папка называется core, то возможно создание папок core copy, core copy (1), core copy (2) и т. п., причем при каждой следующей компиляции создается новая папка.

Это может вылиться в раздувание файлов, и, кроме того, привести к использованию неправильных версий символов. Как решить эту проблему нормальным способом - неизвестно. Единственное, что можно предложить - это не использовать папки в библиотечном файле, то есть рекомендуется складывать компоненты прямо в корневую папку библиотеки ролика. В клиентском же файле, например, в шаблоне (см. далее в этой лекции), можно класть эти компоненты в папки.