Это первая часть моего рассказа про Data Binding во Flex, который живьем можно было послушать на 12-ого апреля 2008 года на питерской встрече Russian Adobe Flash Platform User Group.
Презентацию можно скачать здесь, либо посмотреть в отчете Константинера о встрече RAFPUG в Питере в День Космонавтики.

Презентация рассчитана на мой сопутствующий рассказ, поэтому некоторые слайды можно неправильно воспринять без объяснений. Отчасти поэтому я и пишу небольшой цикл постов по этой теме. Хотя главная причина в том, что тема эта очень интересная, и хочется говорить об этом снова и снова.

Data Binding (связывание данных) можно назвать одной из основ разработки на Flex. Поэтому каждый уважающий себя разработчик прямо таки обязан в совершенстве владеть этим интересным и полезны механизмом.

Если вы разрабатываете на Flex, то, скорее всего, регулярно используете data binding. Особенно органично его использование в mxml. Вообще говоря, надо сильно извратиться, чтобы, используя mxml, ни разу не использовать data binding или связывание данных.

Data binding во Flash
Интересно, что на Flash платформе data binding появился еще во Flash, и некоторые разработчики активно его использовали.
Flash 8 для этого предоставлял Bindings tab и классы пакета mx.data.binding.
Кстати, не могу сказать, что связывание данных во Flash, было удобным. Хотя, не могу сказать, что хоть что-то там было удобно.

Еще более интересен тот факт, что Flash CS3 уже не предоставляет возможностей связывания данных своим разработчикам. Видимо, это очередной намек Adobe на то, что программистам надо смотреть в сторону Flex.
В документации для Flash CS3 про Data binding classes недвусмысленно говорится о том, что можно использовать старые механизмы связывания, но тогда и компилить можно будет только под ActionScript 2.0.

Что же такое связывание данных или data binding?
Суть связывания в автоматической синхронизации. Слово “автоматическая” особенно приятно звучит, так как это освобождает нас от какой-то рутинной работы. А кто хочет заниматься рутинной работой?

Наиболее распространенный случай - это синхронизация model и view.
При нормальном адекватном развитии событий в приложении существуют такие слои, как view, model, controller. View отображает данные модели. В большинстве случаев при изменении данных в модели, необходимо обновлять view. Это можно осуществить вручную путем подписывания на события изменения модели и вызовом методов обновления view. Связывание данных позволяет делать это автоматически.

Вам выбирать, что синхронизировать. Это может быть синхронизация данных, различных элементов GUI и тд и тп.

В качестве примера синхронизации элементов GUI можно привести такой код:

Code:

Всего несколько строк кода позволяют определить сразу три синхронизации:

• dataProvider обоих списков синхронизируются с коллекцией listExample. Это значит, что при изменении listExample, оба списка сами обновят свой внешний вид.
• selectedIndex синхронизируется с соответствующим свойством первого списка. Таким образом, когда пользователь выделяет элементы первого списка, соотвествующие элементы автоматически выделяются во втором списке.
• аналогично синхронизируются значения verticalScrollPosition списков. Если пользователь скролит первый список, то автоматически скролится и второй список.

В эту субботу у Константина Ковалева aka Constantiner был день рождения!
Костя, желаем тебе творческих успехов, новых открытий и интересным тем для исследования.

В воскресенье мы посетили августовскую встречу RAFPUG почти полным составом riapriority. Причем доклады про flex-фреймворки читали опять же представители riapriority: Константин Ковалев aka Constantiner рассказывал про Mate и Павел Кожин aka Vertex про Cairngorm.
Еще один доклад был посвящен следующей (а значит четвертой) версии Flex - Gumbo, и его представлял Артемий Малков.

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

First of all шок дня - Иван Дембицкий признал существование Flex. Ура, товарищи!

Первый доклад про Gumbo порадовал богатыми перспективами Flex. Об этом уже многие писали, в том числе и Constantiner в посте Flex 4 “Gumbo” увидеть не хотите ли? И Gumbo, действительно, прекрасен.
Самые впечетляющие меня меня фичи:

• разделение в компонентах view и модели, до сих пор не верится, что мы этого дождемся
• новый подход к layout-ам
• то, что уж совсем похоже на сон или на сказку - новые Gumbo компоненты будут полностью совместимы со старыми Halo компонентами
• мы сможем более удобно работать с графическими примитивами посредством FXG

В качестве переходного этапа к рассказам о Cairngorm и Mate был мини-доклад про то, зачем нужны фреймворки. Constantiner вкратце рассказал о проблематике командной разработки, о спагетти-коде, и о том, как перестать думать мучиться и начать программировать.

Кстати Constantiner придумал очень интересный проект - написать одно и тоже приложение с использованием разных фреймворков. Приложение не очень сложное - это поисковик книжек в Ozon, из функционала - собственно сам поиск и сохранение избранного в shared objects.
Код проекта хранится тут:
http://code.google.com/p/ozon-books-finder/.
А если у вас есть желание поучаствовать, то обязательно присоединяйтесь!

Далее Vertex очень подробно рассказал про Cairngorm. В результате сложилось впечатление, что полезно знать этот фреймворк, так как он очень распространен сейчас. С другой стороны кажется, что тяжеловесность и неповоротливость Cairngorm-а, может склонить разработчика к принятию решения о выборе другого фреймворка.

А какого другого фреймворка спросите вы? При принятии этого решения может оказать незаменимую помощь доклад Кости про Mate.
Сразу скажу, что если вы не видели и не слышали этот доклад, то пора в отчаянии убить себя апсену очень-очень-очень много потеряли.
Я еще ни разу не наблюдала в докладах Кости столько воодушевления и экспрессии. Трудно было не сорваться и не убежать изучать Mate прямо после встречи.
Constantiner поделился тем, что давно мечтал о таком фреймворке и даже втайне хотел написать нечто подобное.

Неформальная часть тоже порадовала темами для обсуждения и приятным общением. Сообщество интересуется и разработкой серверной части, и работой с системами контроля версий, и общей организацией разработки, и многим другим.
Приятно, что московские встречи посещают разработчики не только из Москвы и Питера. Кстати, пользуясь случаем, передаю привет гостям из Самары.

А если вы еще ни разу не посетили встречу, то обязательно это сделайте в ближайшее время. Все-таки не всем разработчикам на flash-платформе повезло работать в команде, а тут такая возможность обменяться опытом.

Как уже говорилось в предыдущей части, часто отрицание самой идеи применения ООП для flash имеет причиной то, что разработчик не до конца понимает идеологию ООП.

Как понять, что вы еще не готовы к осмысленному выбору - ООП или не ООП? Как выявить в себе “хитреца", якобы использующего ООП, но реально процедурно программирующего в классах?

Вот несколько отличительных признаков. Проверь себя!

1. Более 50 процентов ваших классов наследуются от MovieClip или UIObject. Хотя UIObject - это лишнее для вас, MovieClip как-то роднее.
2. Вы считаете, что приватные свойства и методы придумали трусы и не затрудняете себя использованием индикаторов видимости.
3. Причину, по которой вы бы использовали в своем проекте interface, даже трудно вообразить. Или вы вообще не знаете, что такое interface.
4. Событийную модель Flash (да, это конструкция addEventListener) вы используете только в крайних случаях.
5. Крайние случаи использования событийной модели у вас всегда связаны с использованием макромедийных компонент, впрочем, вы и так стараетесь их не использовать. Зачем? Ведь можно самому написать все эти компоненты, и они будут быстрее работать и меньше весить.
6. Слова _parent, _root и _global не являются для вас ругательными или сколько-нибудь постыдными. Почему бы и не вызвать что-нибудь в _parent в нужный момент? Да и конструкции типа _parent. _parent. _parent не смущают вовсе, вы свободный человек в свободной стране - что хотите, то и вызываете.
7. Вы не используете типизацию, а то и не знаете, что это такое.
8. Повторное использование кода - это копирование целых классов и методов в новый проект с внесением незначительных изменений. А может и значительных, это как получится.
9. Вы часто используете наследование. В ваших цепочках наследования порой насчитывается более 5 классов.
10. Вы не знаете, что такое высокое зацепление, низкая связанность, инкапсуляция. полиморфизм.
11. Вы не знаете, что такое шаблоны (паттерны) проектирования или просто их не используете.

Если, пробежавшись по этим признакам, обнаружили в себе и своем кода хотя бы один, то вы в весьма извращенной форме используете ООП или не используете его вовсе. Вы совершенно точно не имеете представления об ООП или имеете неправильные и далеко неполные представления. А значит можете открыть для себя очень много в мире программирования.

Не так давно вышла публичная альфа версия нового Flex фреймворка Mate.

Разработчики говорят о том, что это скорее бета, и к финальному релизу они не планируют вносить существенные изменения.

Не секрет, что при использовании событийной модели во Flex, часто разобраться в хитросплетениях происходящих событий бывает не легко. Mate как раз поможет более наглядно организовать ваши события в приложении, причем предлагается использовать для этого mxml.

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

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

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

Если вы мечтаете стать сертифицированным flex-разработчиком, то безусловно порадуетесь тому, что программа для подготовки к тесту Attest стала бесплатной. Приятно, что это произошло несмотря на мировой финансовый кризис.
Кстати, это теперь AIR-приложение.

Будущие Adobe Flex 3 with AIR Certified Developer-ы дерзайте!

PS: А есть желающие стать сертифицированными?

Данное повествование будет интересно в первую очередь тем, кто не понимает, но хочет понять, зачем и как использовать интерфейсы или тем, кто пробовал использовать, но не получил никаких результатов. А результаты быть должны, так как интерфейсы - очень мощное средство.

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

1. Внешние модули.

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

Например, существует галерея картинок, которая использует модуль выбора картинок имеющихся на сервере. Этот модуль является отдельным swf файлом, в котором заключена вся необходимая ему логика. Приложению же от модуля нужны только методы showPicturesList (показать пользователю список картинок) и getSelectedPicture (вернуть выбранную пользователем картинку). Смело можно делать интерфейс IPicturesSelector с данными методами.

Какие получаем плюсы при данном подходе?

1. В случае неправильного обращения к модулю будет выдана ошибка на этапе компиляции, что приятно и удобно. При слепом общении с модулем можно потратить на поиск такой ошибки достаточно много времени. Конечно, стоит упомянуть об одном минусе, который существует в as2. Сама по себе подгружаемая swf не может имплементить интерфейс. Но можно пойти на разные хитрости, например, определить в главном таймлайне метод getPictureSelector, который будет возвращать объект класса с ожидаемым интерфейсом.
2. При компиляции главного приложения классы модуля не участвуют. Они были бы включены в компиляцию при обращении к модулю, через класс объектом которого он является. Это особенно важно, когда в приложении большое количество модулей.
3. Если необходимо будет что-то поменять в модуле или заменить весь модуль, то не будет необходимости переписывать что-то в главном приложении. Это, конечно, при условии сохранения интерфейса модуля. И более того, при изменении модуля нет необходимости перекомпилять само приложении, что является плюсом, если разработчик модуля не имеет исходников главного приложения.

Ранее я уже писала про рантайм локализацию в посте Легкая локализация во Flex. А будет ли runtime локализация? И с выходом третьей беты Flex 3 можно с уверенностью сказать, что рантайм локализация не только будет, но уже и есть.

И вообще, радуют изменения которые произойдут в третьей версии Adobe Flex в области локализации приложений.
На мой взгляд основными бонусами станут:

• компиляция приложения с несколькими locale одновременно
• возможность переключения locale в рантайме (причем соотвествующие resource bundles могут быть как вкомпилены в приложение, так и подгружены)
• возможность программного создания resources, например из XML файла
• возможность использования картинок, звуков, видео, стилей и т. д. при локализации

Мало того, что вы можете запросто сделать кнопочку переключения языков у себя в приложении, так еще и при этом переключении менять не только надписи GUI, но и картинки, звуки и например размер шрифта. Кстати, изменение размера шрифта для некоторых языков прямо таки жизненно необходимо, на мой взгляд.

Более того, locale, загружаемую по умолчанию, можно определить в параметрах HTML обертки. А это говорит о том, что вы можете доставлять один swf файл со всеми языками и только в html в параметрах определять, какой язык сейчас увидит пользователь.

А теперь о менее приятном - о том, что вам придется переписать в своих существующих приложениях для перевода их на Flex 3 SDK и использования выше обозначенных бонусов.

Установив третью бету 3-его Flex, сразу же бросились в глаза варнинги по поводу устаревшего применения ResourceBundle с помощью соответствующего метатега.

Примечательно, что использование директивы @Resource не изменилось. Однако в доках недвусмысленно намекается на то, что лучше не использовать этот способ, так как например, он не позволяет использовать переключение locale в рантайме.

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

Новый способ взаимодействия с resource bundle - это использование ResourceManager. А скорее всего, вы будете использовать свойство resourceManager, которое теперь есть у всех потомков от UIComponent, Formatter или Validator.

Еще одной приятной вещью станет то, что не обязательно теперь файлы ресурсов делать полностью копиями друг друга. Можно забыть при экспшены при обращении к ресурсу, так как в localeChain можно задать массив locale-ей. Тут и произойдет чудо. Например, ваш язык приложения русский, но недостающие строки могут автоматически цепляться из английских ресурсов.

Все эти радости можно увидеть уже на существующей Flex 3 SDK 3 beta 3.

Например, в дополнительных параметрах компиляции прописываете -locale=US,RU,GE.
Кстати, не забудьте, произвести операции описанные в статье Flex 3:Feature Introductions: Runtime Localization, а иначе не избежать вам ошибок компиляции вида Unable to resolve resource bundle “collections” for locale. Правда для чартингов мне все равно пришлось ручками копировать.
В результате получаете swf с тремя встроенными locale-ми: английская, русская, немецкая. Добавляем в html-оболочку во flashVars localeChain=RU,US. В результате наблюдаем русскоязычное приложение, недостающая часть перевода которого пока на английском.

В общем, поздравляю нас всех - локализация приложений станет удобнее!

Часто flex-разработчики работают в небольших командах, либо (о, ужас) в одиночку. А это может привести к тому, что утрачивается критическое отношение к своему коду. Но мы же не хотим деградации! =)

Некоторое время назад Adode выпустили инструмент, который покритикует, укажет на недоработки, ошибки и bad practices в коде – это FlexPMD.
Расшифровка PMD точно неизвестна, но мне нравится – Programming Mistake Detector. Эту технологию уже давно используют Java-разработчики.

Даже если вы пишете идеальный код (чего, конечно, не бывает), то будет полезно узнать про пару-тройку неиспользуемых методов или наличие пустых используемых методов. Или может в каком-то методе затесался неиспользуемый аргумент? =)

На пути к идеальному коду у вас три этапа:

1. определение правил, на соответствие которым будет проверен код (используем FlexPMD Ruleset Creator)
2. запуск FlexPMD и получение в результате файла с расширением pmd.xml
3. просмотр pmd-файла, например, с помощью PMD Violations Viewer

Набор правил

Прежде всего необходимо определиться с набором правил, по которым будет проверяться код. Адобе предоставил FlexPMD Ruleset Creator, который по умолчанию предлагает набор из 84 правил разного приоритета: Error, Warning, Info. Этот набор можно редактировать и сгенерить файл pmd.xml, который будет в дальнейшем использоваться при проверке кода.

Расскажу кратко про некоторые правила.

Error priority

Ошибками считается:

• использование BindingUtils и ChangeWatcher. Да и как тут не согласиться? Ведь на этапе компиляции вы не узнаете о том, что все плохо.
• использование callLater. А кто бы сомневался?
• использование dynamic классов, Dictionary, Object и *.
• создание или удаление чайлдов внутри updateDisplayList и вообще не внутри createChildren
• dispatch события внутри конструктора (а кому нужны такие события? =))
• некорректные метаданные [Event]. Вот это удобно.
• использование не статических констант. Константы обязаны быть статическими.
• наличие неиспользуемых, методов, параметров и тд. Это полезно. Часто в больших проектах повисают неиспользуемые методы, классы и даже пакеты. =)

Warning priority

• Предупреждают, что не надо инстанциировать переменную в цикле.
• Не рекомендуют использовать статические переменные. И правильно.
• Также не рекомендуют делать весь класс [Bindable]. Тоже правильно. Что тут скажешь?
• Находит слишком сложные методы и указывает на это. Если программе метод кажется слишком сложным, то что же делать вашим коллегам?
• Ну и конечно вложенные if else никуда не годятся.
• Много импортов наводят программку на размышления о том, что этот объект связан слишком со многими. А это не есть гуд.
• Слишком длинные методы, конструкторы и тп не нравятся никому.
• Кстати, на нравятся заглавные буквы в названии пакетов. Что ж. Может в этом что-то есть.
• Очень приятно, что даются рекомендации понижать уровень видимости методов. Ура-ура! =)
• Слишком много параметров у метода? Да я сама это терпеть не могу.
• Наблюдая переменные со странными именами (наличие цифр, tmp и тд), программа тоже дает об этом знать.

Info priority

• Слишком короткое имя переменной.
• Слишком длинная строка кода.
• Конструктор какого-то фига имеет возвращаемое значение.
• Отсутствует copyright header.

В общем, лично я считаю эту программу крайне полезной. Если вы практикуете в команде ревью кода, то это может помочь на начальном этапе. Если команды нет, то полезно для самоорганизации.

Шаги к идеальному коду с помощью Ant

Приведу шаги, в результате которых, вы сможете узнать всю правду про свой код. =)
Это вариант с использованием Ant.

1. Скачиваем нужную версию http://opensource.adobe.com/wiki/display/flexpmd/Downloads из колонки “Ant Task”
2. Распаковываем архив в любое удобное место, например в C:\Program Files\flex-pmd
3. С помощью FlexPMD Ruleset Creator создаем файл pmd.xml и кладем в любое удобное место, например тоже в C:\Program Files\flex-pmd. Для начала можно правила не редактировать, а просто кликнуть “Export” и сохранить файл.
4. В файл свойств для build.xml добавляем переменные
   FLEXPMD=c:/Program Files/flex-pmd
   FLEXPMD_VERSION=1.0.RC4
   Пример файла local.properties:
   FLEXPMD=c:/Program Files/flex-pmd
   FLEXPMD_VERSION=1.0.RC4
   SRC_DIR =${basedir}/src
   DEPLOY_DIR = ${basedir}/DEPLOY

5. Пример build.xml:

   XML:

   	<project name="" default="pmd">
   	<!−− load previously defined configuration properties file −−>
   	<property file="local.properties" />
   	<!−− delete and create the DEPLOY dir again −−>
   	<target name="init">
   	<delete dir="${DEPLOY_DIR}" />
   	<mkdir dir="${DEPLOY_DIR}" />
   	</target>
   	<taskdef name="flexPmd"
   	classname="com.adobe.ac.pmd.ant.FlexPmdAntTask"
   	classpath="${FLEXPMD}/flex-pmd-ant-task-${FLEXPMD_VERSION}.jar">
   	<classpath>
   	<pathelement location="${FLEXPMD}/flex-pmd-ruleset-api-${FLEXPMD_VERSION}.jar"/>
   	<pathelement location="${FLEXPMD}/flex-pmd-ruleset-${FLEXPMD_VERSION}.jar"/>
   	<pathelement location="${FLEXPMD}/flex-pmd-core-${FLEXPMD_VERSION}.jar"/>
   	<pathelement location="${FLEXPMD}/as3-plugin-utils-${FLEXPMD_VERSION}.jar"/>
   	<pathelement location="${FLEXPMD}/as3-parser-${FLEXPMD_VERSION}.jar"/>
   	<pathelement location="${FLEXPMD}/pmd-4.2.2.jar"/>
   	<pathelement location="${FLEXPMD}/commons-lang-2.4.jar"/>
   	<pathelement location="${FLEXPMD}/flex-pmd-files-${FLEXPMD_VERSION}.jar"/>
   	<pathelement location="${FLEXPMD}/as3-parser-api-${FLEXPMD_VERSION}.jar"/>
   	<pathelement location="${FLEXPMD}/plexus-utils-1.0.2.jar"/>
   	</classpath>
   	</taskdef>
   	<target name="pmd" depends="init">
   	<flexPmd
   	sourceDirectory="${SRC_DIR}"
   	outputDirectory="${DEPLOY_DIR}"
   	ruleSet="${FLEXPMD}/pmd.xml"/>
   	</target>
   	</project>

6. Полученный pmd.xml анализируем с помощью PMD Violations Viewer

На Flex Doc Team появилась статья Migrating applications from Flex 2 to Flex 3, в которой описаны возможные проблемы при перехода на SDK 3.

Радует, что проблем будет не так много. Расстраивает, что такие проблемы все-таки будут, так как существует достаточно объемный список изменений.

Вообще говоря, основные изменения Adobe провели в области локализации (о чем я уже писала в посте Изменения локализации во Flex 3) и в области своих charting компонент.

Причем последние изменения достаточно глобальные, что, например, привело наш с Graann проект, построенный на основе этих компонент к тому, что потребуется достаточно серьезная работа для того, чтобы перейти на SDK 3.

А у вас как происходит переход на SDK 3?