Рубрика: ActionScript 2.0
Жизнь после Flash CS3
Работая во Flash CS3
Путь Flash-разработчика чаще всего начинается со среды разработки Flash IDE. Однако со временем начинаешь понимать, что все должно бы быть лучше:
- Редактор кода без настоящей системы подсказок
- Вылавливание багов только процессе публикации
- А компилять средний проект надо секунд 10
- И дай Бог чтобы у Вас все было хорошо с датами сохранения документов (+ еще несколько других неприятных багов)
- Даже если Вы захотите разобраться с Data Binding в AS 3.0 - у вас он не заработает как во Flex
Если попытаться подключить классы из Flex, которые за это отвечают, то он не заработает все равно - компилятор в IDE не поспринимает аттрибуты [Bindable]
- И просто Flash IDE создана не для того - в ней неудобно писать код
Что сдерживает переход к какому-либо более совершенному способу разработки:
- Порог осноения недостаточно знакомой/новой среды (Flex Builder, FDT)
- Там нет таймлайна!

- Перспектива работать в более чем одной среде (анимацию все равно придется делать во Flash)
- Придется писать больше кода (?)
- И так сроки горят?
Как оказывается (проверено на себе), потери времени действительно имеют место (особенно в первый день работы). Однако очень быстро начинаешь делать все очень-очень быстро и получаешь от этого большое удовольствие. Flex 2 / Flex 3 Beta 2, конечно, тоже не безупречны, но по сравнению с Flash CS3 IDE - просто рай.
Разработка - Flex Builder 3 Beta 2
Эту среду Вы можете скачать бесплатно. Также понадобится установить Flash Component Kit - расширение для Flash. Вот как выглядит работа в общих чертах:
- Рисуем/анимируем в Illustrator, Photoshop. Импортируем во Flash (за исключением растровых картинок).
- Разделяем графику и анимацию на логические части - с мыслью испльзовать их как стандартные компоненты во Flex.
Автоматические подсказки не покажут Вам, что находится внутри такого “импортированного из Flash” компонента, однако это можно делать (надо знать, что где лежит). AS 3.0 код также работает - например, класс SelectedButton, прилинкованный к MovieClip и реализующий кнопку с нажатым состоянием.
- Выбираем в библиотеке Flash-документа MovieClip-ы, которые будут нужны во Flex. Используем появившуюся после установки Kit’a функцию Commands -> Make Flex Component
О том, что эта команда делает, можно почитать в доках.
- Для нас сейчас главное - это то, что теперь при публикации появляется .SWC файл. Соберем все такие файлы и положим в отдельную папку внутри Flex-проекта, а лучше - назначим путь публикации из всех Flash-документов в ту папку (я завел внутри проекта две папки - assetsSrc и assets)
Вот и все. Flex будет автоматически отслеживать изменения в той папке и пересобираться (что важно - при этом ему не нужно компилировать ваши многочисленные .fla). Если вы опубликовали символ MainBackground (это должно быть именем класса в Linkage во Flash), то автоматическая подсказка его покажет и вставит за Вас import …;. Вот, что мы получаем:
XML:
<local:MainBackground id="assets"></local> |
Обращение к assets в коде там же:
- // Подписываемся на нажатие на кнопку
- assets.myButton.addEventListener(MouseEvent.CLICK, clickHandler);
- // Например, подписываемся на событие,
- // которое раздает наш класс SelectedButton
- // который мы прилинковали ко
- // кнопке mySelectedButton во Flash
- assets.mySelectedButton.addEventListener(MouseEvent.CLICK, clickHandler);
В итоге мы отделили мух от котлет - рисуем в графическом редакторе, пишем код в настоящем редакторе кода. Примерно такой подход я сейчас использую. Доволен! ![]()
Конструктор, часть 1
Начиная с этого поста я попробую коротко и ясно рассказать про интересные аспекты flash-части проекта my.futbolka.ua. Flash 8, AS 2.0.
Сразу скажу, что не открою секретов или “tricks", но возможно мой опыт (и мои ошибки) будут Вам полезны.
Упрощение развертывания и отладки. Описание проблемы.
Для проекта такой длительности (от 100-150 часов) необходимо заранее уменьшить транзакционные расходы, чтобы было легче жить. Конкретно:
- Как организовать загрузчик (Preloader)
- Как быстро при рабочей локальной версии сделать рабочую серверную, напр. брать файлы с нужных адресов
- Как обеспечить комфортную отладку на сервере, в данном случае - отображение trace()
Решение: Local to Global.
Обычно вопросы конфигураций при компилировании решаются командами препроцессора. В AS 2.0 набор команд ограничивается #endinitclip, #include и #initclip, очевидно что они ничего в этом случае не дадут.
В конструкторе футболок в package model есть отвечающий за это класс LinkSet, большинство свойств и функций в нем поставляют адреса для остальных компонент:
- class model.LinkSet {
- //
- // properties
- //
- // local - флаг локальной версии, остальные относятся к отладке
- public static var local:Boolean = false;
- public static var viewDebugOrder:Boolean = false;
- public static var debugSaveImages:Boolean = false;
- //
- // functions
- //
- // Эту функцию использует прелоадер, т.к. адрес загрузки основного клипа тоже меняется
- public static function get constructorUrl():String
- {
- if (local)
- return "constructorBig.swf";
- else
- return "/constructor/constructorBig.swf";
- }
- // Адрес для отправки данных: локально не используется
- public static function get orderSendUrl():String
- {
- if (local)
- {
- throw new Error("LinkSet::orderSendUrl called local");
- return null;
- }
- else
- {
- return "/order.php";
- }
- }
- // Начало, как правило общее для многих путей как локально так и на сервере
- public static function get linkBase():String {
- if (local)
- return "serverXML/";
- else
- return "/engine.php?type=";
- }
- // Адрес для типичного запроса - xml с описанием
- // категорий основ (футболки, кепки и т.п.)
- public static function getBaseCategoryLink():String {
- if (local)
- return linkBase + "bases.xml";
- else
- return linkBase + "bases";
- }
- // ...
- }
Доступ ко флагам public - другие компоненты тоже могут их видеть (можно дописать еще кода и сделать эти их read-only).
Прелоадер при компиляции также работает с LinkSet.constructorUrl(), в итоге мы получаем настройку прелоадера и основного клипа одной переменной - LinkSet.local .
Есть способ лучше - сделать загружаемый конфигурационный xml-файл, в котором описать нужные параметры - тогда локальную .swf можно смело заливать на сервер, на котором лежит нужный xml-конфиг.
Об отладке и trace()
Есть разные способы отладки приложения на сервере, меня устроил один из самых простых: устанавливается плагин Flash Tracer для Mozilla Firefox (комментарии к установке от Роста) и окошечко Output из среды разработки фактически перемещается в сайдбар Firefox’а.
Коронарография. UI.
Пилотная версия
Была создана в момент выбора технологии для реализации данного элемента UI.

Посмотрев на это чудо, мы поняли, что:
- Т.к. придется добавлять/удалять части сосудов, то схематичное изображение сосудов гораздо лучше с точки зрения разработки и по многим параметрам выигрывает с точки зрения пользователя
- Не получится все сделать с помощью контекстного меню

- Нельзя показывать всю информацию сразу, т.к. даже в таком урезаном варианте на экране ее уже много
Первая версия
Ее я делал постепенно, не спроектировав изначально всю функциональность и не очень волнуясь по поводу масштабируемости. Результатом стала тупиковая версия, которую пришлось бросить вот почему:
- Классы были выделены не совсем верно и не были организованны в packages
- Не было разделения Представления и Логики
- Схема взаимодействий превратилась из дерева в граф и стала сильносвязной
- Поэтому код запутался и дальнейшая его разработка стала невозможной

Вторая версия
Она же финальная на данный момент. Создавалась она с “нуля", в ней я постарался учесть все предыдущие ошибки, но опять таки не додумал до конца, так что ближе к концу проект стал снова крениться набок. Вот, что получилось в итоге:
- Функции разделены между “режимами работы": Сосуды, Топология, Шунты и т.п.
- Часто используемая информация находится “ближе” к пользователю, чем остальная
- Все взаимодействия сделаны как можно более наглядными (напр. установка перетоков, ср. с первой версией)

Погнаться за двумя зайцами

Однажды мне предложили сделать диск-архив и в качестве бонуса - очень похожий по функциональности диск по соседней тематике. Первым был диск «Ускользающие шедевры», вторым - «Радиоискусство» (версии без картинок на free-lance.ru).
Из чего должен состоять диск:
- Заставка
- Два раздела с простым статическим контентом
- Один раздел - поиск по базе изображений. Поиск по одному из трех параметров, вывод результатов.

Подобный проект можно реализовать практически любым из известных науке способом программирования на ActionScript:
- Пользоваться фреймами и крепить код к ним
- Разделить все по символам-классам, в самих классах вести разработку как душе угодно
- Разделить все на символы-классы и с надеждой на повторное использование кода во второй части проекта («Радиоискусство») попытаться грамотно использовать наследование и события
Путь с фреймами в проекте такого размера ведет к очень плохим последствиям, жертвой которых я сам становился не раз: в каких-то местах код скапливается в огромных количествах и его уже не получается чинить/модернизировать - просто невозможно понять, где нужный кусок находится и зачем эта строчка тут.
Если попробовать полностью положиться на классы как панацею от всех бед без обдумывания структуры проекта то получиться может все что угодно ![]()

На самом деле достаточно воспользоваться очевидными особенностями задачи:
- Три раздела - для них можно сделать один базовый класс, в нем - вся общая функциональность (переключение между разделами, открытие, закрытие)
- Поскольку дизайн у двух дисков разный, а функцинальность одна - то нужно отделать внешний вид от кода полностью

В итоге второй диск получился из первого примерно за 5 часов, в то время как стоил столько же.
Конечно, не все было чудесно, при разработке были допущено довольно много стратегических ошибок во имя ускорения процесса и которые в итоге привели к потере времени
И тем не менее, код первого диска - 20 файлов (75 кб), код второго - 10 файлов (40 кб, все наследуют у файлов с такими же именами из кода первого проекта с внесением нужных изменений, порядочно copy-paste). Он (сopy-paste) появился из-за того, что я поленился хорошо разделить код на функции/обработчики событий и из-за мелкого изменения в функции приходилось перегружать ее полностью.
Это самый простой и действенный пример пользы от использования хотябы каких-то приемов ООП.





