Junik

Как уже многие сообщили, вышел prerelease Flex Component Kit для Flash CS3.

И вот уже выложен пример создания такого компонента для Flex. Думаю особенно будет интересно тем, кто перешел на Flex, но очень скучает по Flash. Хм. Интересно, а такие есть?

Наверное еще со времен 7-ого и 8-ого flash, само слово item renderer мне неприятно. Если у вас таже проблема, то делюсь одной интересной статьей на эту тему. Надеюсь, что она поможет подружиться с этими милыми созданиями - item renderer-ми.
На простом английском языке там даются рекомендации по созданию рендереров. Автор предостерегает от создания рендереров на основе контейнеров (Canvas, HBox, VBox), так как это может привести к проблемам с производительностью приложения. Также не рекомендуется использовать “всплывающие"‘ из item renderer-ов события. В общем, есть что почитать. А главное - предоставлено много готовых примеров.
Есть и продолжение статьи.

Столкнулась с необходимостью максимально убрать встроенные пункты контекстного меню во всем приложении и обнаружила, что простой вызов hideBuiltInItems у контекстного меню Application-а проблему не решает: остается полное макромедийное меню на popup окнах.

Решение обнаружила во Flex cookbook beta и спешу им поделиться.

Адобовцы пишу, что проблема связаны с тем, что контекстное меню приложения не используется для контекстного меню окон (так как окна не являются чайлдами приложения) и предлагают использовать systemManager приложения.

Если после инициализации Application-а написать строку:
MovieClip(systemManager).contextMenu = this.contextMenu.clone();
то, это сделает контекстное меню SystemManager-а и у Application-а одинаковыми.

Если же вы хотите изменять контекстное меню приложения, и эти изменения должны отражаться на контекстном меню окон, то клонирование использовать не нужно - можно просто присвоить свойству MovieClip(systemManager).contextMenu необходимое контекстное меню.

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

Вчера открыла для себя плагин для Eclipse XMLBuddy, который помогает работе с XML. Позволяет настроить подсветку XML и DTD, генерит DTD для имеющегося XML и еще много всего. Есть бесплатная версия XMLBuddy и платная XMLBuddy Pro. Про все это подробнее на сайте http://www.xmlbuddy.com.
Устанавливается простым копированием в папку plugins.
Кстати, поделитесь, кто чем пользуется для работы с XML в Eclipse.

Farata Systems анонсировали сайт http://www.myflex.org. Пока это только alpha версия. Интересно то, что сделан сайт на flex. Пока еще не очень удобно им пользоваться, но надеемся на лучшее. Обещают, что там будут появляться компоненты для flex и плагины для flex builder, в том числе и бесплатные.

Если вы разрабатываете flex приложение, то локализация не должна отнять много времени, про что есть статьи и на русском языке (например, эта). Несколько минут и ваше приложение “заговорит” на разных языках, а если забудете что-то важное, то exception обеспечен.
Adobe предлагает использовать [ResourceBundle] metadata в ActionScript и @Resource директиву в MXML. Лично я отдаю все-таки предпочтение использованию метатега ResourceBundle с последующим общением с объектом типа ResourceBundle, хотя бы потому что Flex не поддерживает runtime локализацию и при необходимости придется ее добавлять. И проще будет вместо ResourceBundle подсунуть класс с таким же интерфейсом, чем исправлять строки типа “@Resource(key=’keyname’, bundle=’ResourceBundleName’)” во всех mxml файлах.
Кстати, судя по первому комменту этого поста стоит ожидать поддержки runtime локализации в первой половине 2008 года, так что ждать осталось совсем немного. Хочется верить, что для этого не прийдется создавать swf файл для каждого языка с последующей их подгрузкой, как сейчас предлагается создавать swf-оболочку для css.

Недавно наткнулась на проблему изменения цвета прелоадера flex приложения. Это, тот прелоадер, который flex автоматически показывает во время инициализации приложения. Сама не смогла догадаться, как это сделать, решение нашла тут. Для тех, кому лень переводить, вкратце перескажу.
Цвет фона прелоадера приложения задается в HTML в теге object embed в атрибуте bgcolor.
Предлагаются два варианта:

1. Отредактировать свойства компиляции проекта в Flex Builder
2. Прописать атрибут прямо в свой HTML файл

Чтобы задать цвет в Flex Builder необходимо выбрать свойства проекта и там на вкладке Flex Compiler дописать строку “-default-background-color #336699″ в Additional compiler arguments.

Начав более плотную работу с Flex, решила установить версию 2.0.1. Как всегда в папке Adobe\Flex Builder 2\Player\debug нашла плеер и установила его. Но не тут то было, так как ожидаемой работы afterthought я не обнаружила. Немного повпадав в панику и попытав Константинера, выяснила, что дебаг плеер 9.0.28.0, который идет по умолчанию с Flex Builder 2.0.1 действительно не работает. Подробнее об этом тут.
Вернуть trace() в afterthought и восстановить дебаг функции плеера удается следующим образом:

1. Удалить старый плеер с помощью специального uninstaller-a. Причем мне удалить по-другому его не удалось.
2. Установить плеер с сайта макромедии, релиз которого был 11/14/06.
3. У afterthought в меню Options/MM.CFG Configuration снимаем галочку Use Default Log File Location и прописываем путь C:\Documents and Settings\username\Application Data\Macromedia\Flash Player\Logs\flashlog.txt (это только для Windows, для остальных операционных систем смотрим тут) или прописываем путь прямо в файл Documents and Settings\username\mm.cfg.

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

Приведем пример ‘неправильного’ интерфейса, чтобы было понятно, о чем речь. Пусть у нас есть графический редактор. Будем использовать интерфейс IEditableObject для однообразного общения системы с элементами (линия, текст, картинка, видео и т. п).

Все, кто имеет дело с объектами типа IEditableObject, будут в курсе ‘личной жизни’ этих объектов - у них есть и цвет, и размер, и более того, они могут обновляться после каких-то изменений и даже производить своих клонов. Вряд ли все описанные методы могут быть использованы каким-то модулем одновременно. Использование интерфейса типа IEditableObject, говорит о растущей вероятности того, что принцип низкой связанности и высокого зацепления в приложении не сможет выполняться.

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

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

Как избежать выше описанных проблем и не разувериться в возможностях применения интерфейсов?

Можно ‘разделить’ интерфейс IEditableObject на несколько более удобных интерфейсов: IResizable, IСolorChangeable, IDataDependent, ICloneable. Теперь видно, какое поведение определяется каждым интерфейсом.

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

Рассмотрим метод addLine в классе EditorController. Видно, что несмотря на то, что мы получаем от ElementsFactory соврешенно конкретный элемент типа Line, класс CopiesArchive ‘знает’ объект только по интерфейсу ICloneable, то есть знает только то, что этот элемент имеет метод clone. Таким образом мы сможем помещать в архив любые элементы реализующие интерфейс ICloneable, даже если это вообще не элемент редактора, а какая-то другая сущность. А это было бы невозможно при использовании интерфейса IEditableObject.

Наверное самый распространенный случай использования интерфейсов следующий.

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

Рассмотрим пример.

Пусть существует графический редактор с различными панелями и модулями. Необходимо сохранять расположение и настройки этих панелей для следующего сеанса работы с пользователем. Система каждый раз при закрытии, опрашивает все панели на предмет сохраняемых данных, а при следующей загрузке раздает данные обратно. В этом случае можно реализовать интерфейс IRestoreable с методами getRestoreData и setRestoreData, которые служат для получения и установки данных в панель или модуль.

Пример интерфейса.

Теперь если реализовать данный интерфейс для панелей и модулей редактора, то можно будет общаться с ними единообразно. Например, пусть классы SizePanel и ColorMixerPanel реализуют данный интерфейс. Из следующего примера понятно, в каком русле можно организовать общение главного приложения с ними.

Какие здесь плюсы?

1. Можем общаться со всеми модулями одинаково.
2. Получаем ошибки на этапе компиляции, если обращаемся ‘неправильно’ или ‘не к тому’ методу.
3. Не ограничиваем модули одним предком.
4. Разрешение ситуации, когда модули и панели уже написаны, а функционал сохранения их состояния необходимо добавить только сейчас.

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

Стоит быть осторожными, так как это может в дальнейшем связать вам руки. Например, только нектором модулям необходимы методы getRestoreData и setRestoreData, но они включены в этот общий интерфейс, по которому происходит все общение системы с панелями. Тогда вы будете вынуждены определить эти методы во всех панелях, хоть и пустыми, что может привести к недоразумениям. А может случится так, что прийдется изменить сигнатуру какого-нибудь метода в интерфейсе, тогда вы будете вынуждены вносить изменения во все элементы, даже в те, где эти методы объявлены пустыми. Более гибким решением может быть использование нескольких интерфейсов, таких как IResizeable, IRelocatable и т. д.